We setup a Unity 3.1.5 server with off-box exchange 5.5. Imported the 188.8.131.52 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 installers 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.
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 www.CiscoUnitytools.com 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.
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.
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.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.