Changing Call Handler owner to Distribution List generates Failsafe error instead of playing handler greeter. Changing the owner back to Example Administrator fixes the problem. The Distribution list contains Example Administrator and 1 other subscriber as users.
To use CUGA, I want to set a "Unity Admins" DL as the owner. Any ideas to fix this ?
What version of Unity is this?
what's the error that comes up in the application event log when you get failsafe? You should be able to do this provided the distribution list you are assigning is valid - you may want to try a different DL as a test (i.e. one created by setup) just to see if the same error pops up.
Unity 4.02 and I had the same symptom when testing CUGA at another site.
The same thing happens if I make Unaddressed Messages the owner. I think this behaviour is only tied to the new call handler and not the opening greeting
Unity event messages are: ConvpH 141 & 137 and ConvMsg 10007 & 10013
Unable to get information from the mailuser. A possible cause could be a corrupted database entry. The procedure call IAvDohPropertyManager::QueryInterface(IID_IAvDohMailUser) returned [0x80004002] on line 675 of file e:\views\Unity22.214.171.124\un_Conv2\AvConvPhoneHandler\AvConvPHAttemptForwardSvr\AvConvPHAttemptForward.cpp. For more information, click: http://www.CiscoUnitySupport.com/find.php
Unable to route the call to a subscriber. The procedure call RouteCallToSubscriber returned [0x80004002] on line 180 of file e:\views\Unity126.96.36.199\un_Conv2\AvConvPhoneHandler\AvConvPHAttemptForwardSvr\AvConvPHAttemptForward.cpp. For more information, click: http://www.CiscoUnitySupport.com/find.php
CAvCDEConvBase::Run() failure from RunStart (error=0x80004002) in conversation [AttemptForward] on Device ID  For more information, click: http://www.CiscoUnitySupport.com/find.php
Transferred to FailSafe conversation while running conversation AttemptForward on Port 1. See the following file for the contents of the Named Properties : d:\CommServer\Logs\\NPDump_20030618_163958.txt For more information, click: http://www.CiscoUnitySupport.com/find.php
Named Properties dump of conversation AttemptForward, Port 1 (null)
CallDeviceID STRING : 1
Logger OBJECT : 0x008e7a3c
I think there's a problem with how the CUGA conversation is handling distribution lists as owners here... There's a bug on this (CSCdy67907) but it was marked as resoved in 4.0(2) so there must be some additional issue here. I believe a TAC engineer was going to open a new bug on this late yesterday but I can't find the record now... I'll follow up out here if I find it.
Actually, chatting with the engineer for this it looks like the sites they looked at that had problems here were actually using an invalid distribution link - if you run dbWalker (be sure to snag the latest from here: http://www.ciscounitytools.com/App_DirectoryWalker3.htm) does it show any errors on the call handler you're working with?
There may still be a problem here, of course, but let's at least rule out this issue first.
The problem I had was resolved by setting up a Routing Rule in addition to setting the extension in the profile of the call handler.
The story I got from TAC is that this is designed behaviour and that if you want to route a call to a call handler you must use a routing rule and can not rely on the directory number associated with the call handler.
This may well be best practice, I must have just picked up some bad habits along the way.
After further discussion with the DEs, they suggested that the answer to you concerns:
"...The specific question is why when no call routing rule is set up to route to a call handler will a call handler work with an extension set up in the profile (on incoming calls), but will stop working and generate a failsafe greeting if the owner is changed to the DL ?..."
To add to that, when calling the call handler directly, a call routing rule must be used.
Just for the record...
Assigning an ID to a call handler and letting an extension with that Id forward to Unity _should_ work here - it shouldn't be necessary to create a routing rule. However it looks like there was a bug introduced with this logic along the way (a DDTS is being opened on it this morning).
You must have input over there :-)
TAC has now opened a DDTS on this issue for dialing the call handler. The bug ID is CSCeb59514. The DEs will be working on correcting this issue.
From my standpoint, e.g. TAC, there is nothing else I can do. I will be closing this case. I wanted to inform you that you are more than welcome to continue tracking this ddts and its developments on CCO: