Cisco Support Community
Community Member

Say goodbye not functional

Cannot save After Message Action: Say goodbye

We setup a Unity 3.1.5 server with off-box exchange 5.5. Imported the database.

Import log error for all 1067 subscribers.

(error) Bad after message action conversation name:

Setting action to hang up and pressing ahead.

Went into SAWeb admin / Subscriber / Subscribers / Messages / After Message Acton. Selected the “say goodbye” item. The save button defaults the selected item back to send caller to “hang up”.

Changed the owner of the goodbye call handler to the installer’s account.

Problem not resolved.

Then loaded defaults…


lindborg - CISCO SYSTEMS

Apr 18, 2003, 7:49am PST

You can rebuild the default objects (including the public DLs) by running the FixDefaultObjects.sql script - it was created for situations just like this (or where folks accidentally deleted the say goodbye handler or the like). You can run it using ConfigMgr.exe found under \commserver\. Select the "run database configuration script" option and then use the browse button to select the "FixDefaultObjects.sql" script then hit "run".

After you finish running the script you'll need to force Unity to sync with the directory to make sure that DL is in the directory properly again. You can do this by running "Setup /sync" from the \commserver\ConfigurationSetup directory. Just hit next and you'll see the fab pencil writing in a book for a while as it works.

That should put things back in a right state.


Problem not resolved.

Reloaded the Unity server

Problem not resolved.

Please help.

Cisco Employee

Re: Say goodbye not functional

My first thought would be that the SayGoodbye call handler is in a bad state - the FixDefaultObjects will not replace an object if it's there already (it's meant to replace objects that folks removed by accident) so that would not have fixed your problem.

But if you completely uninstalled and reinstalled Unity and it's still doing this you have something very odd going on indeed - do you mean you reinstalled AND then reimported the database? If so, that makes sense... if not, then I have no earthly clue what your problem would be.

The radio button for say goodbye is just a short hand way of selecting the say goodbye call handler - it's hard coded to go fish the call handler with an alias of "goodbyech" and map it to that ObjectId - if you manually set it to send the caller to a call handler then then select the say goodby call handler, does that work or does it also revert back to hangup? If it does revert back is there any error given either at the desktop or in the application event log?

Can you snag the latest dbWalker from and run it? I'd be interested to see if it notes any problems with the goodbye call handler in particular - this will kick out errors for all your after message actions if it's run against the system after you've imported your users so we'll have to wade through the output log a bit but it's worth doing anyway.

Community Member

Re: Say goodbye not functional

Installation: Installed - win2k server SP3, PC anywhere (with reg hack for 2 processors), SQL 2k SQL SP3, exchange 5.5 admin, Unity 3.1(5), imported 2.4(6.135) database.

Found - "(error) Bad after message action conversation name: " Found "say goodbye" problem. Ran fixdefaultobjects. Resynced. No switch configured. In the morning CCM 3.2(3)

Setting the Send caller to "Goodbye" call handler reverts back to call handler "hang up". No error message in SAWeb. Did not look in the event viewer application log.

Have not tried send caller to any other call handler. I'll let you know how that goes.

Have not ran DB walker. Will run DBWalker first AM. Will provide results then.

How about this?... ....might be worth a shot... ...remove the goodbye call handler.... fixdefaultobjects.... ....resync.

Will check forum tonight after my right-coast commute. Will test/provide results first AM.

Thank you for your prompt reply.

Cisco Employee

Re: Say goodbye not functional

removing the row in the CallHandler table for "goodbyech" and then rerunning the FixDefaultObjects script may work... although I'm keen to understand what state that call handler is in and, more to the point, how it got there. If you do go that route, be sure to check the table for duplicate handlers with that alias - which is one of the things on my list of possibilities here.

If you can, run dbWalker and send me the output. Also, if you still have the import log from running FullDBImport I'd like to see that. Bonus points if you have the MDB file you imported - we can FTP it over here and I can do an import onto a clean 3.1(5) system and see if I can repro the problem.

I'm sure the handler was in an odd state on the 2.x system and somehow during the export/import process it went all poopy-pants but I don't have any good theories on what state it's in or how to catch/fix it on the fly. If you've got the MDB file hanging around that would be ideal.

you can email the logs to

Community Member

Re: Say goodbye not functional

Yes, we have all the files you have requested. MDB, Export log, import log and, in the am, DBwalker log.

We will work on sending them in the AM.

Thanks again.

Community Member

Re: Say goodbye not functional

Say Goodbye not functional again.

Ran DBWalker on twice. Removed orphns on the second run. Exported the DB. Imported to a clean install of Unity 3.1.5.

After message action can not be changed using SA. After message action can be changed using Bulk Edit.

We have copies of the Import log and Exported DB. Please advise.

Cisco Employee

Re: Say goodbye not functional

Your 2.4.6 system definitely sounds like it has a botched up goodbye handler - dbWalker is not going to automatically fix the after message action, it can't possibly do that on the fly - this has nothing at all to do with orphaned handlers (this is the reason why I've removed that option in later versions of dbWalker - folks tend to whack on it in the abscence of anything else to do).

I'm pretty sure the export and import is doing what it's suppose to here but it's porting over the bad conversation name value living in your 2.4.6 system and faithfully reproducing it on your target 3.1(5) system.

I don't believe the older 2.x version of dbWalker made checks for everything along these lines - the only thing I can suggest is to try and patch up the 2.4.6 system manually in DOHPropTest prior to doing the export. If you have remote access via WTS or pcANYWHERE I can get in and poke around on the 2.x system or you can open a TAC case and get a TAC engineer to help you out. Beyond that there isn't much I can suggest here - I think you've demonstrated fairly clearly that there's an issue in your 2.4.6 system being caried forward.

CreatePlease to create content