Ran into an issue where user was not monitoring the drive space available on their SFTP server / DRS backup target and ultimately filled the drive. Unfortunately UCCX doesn't care when attempting scheduled backups how much space is available and ultimately backup will fail.
What's worse is checking the DRS backup status and finding a backup in progress from days or weeks ago. UCCX gives you a pleasant Cancel Backup button to press, but that may result in a infinite Cancelling Backup status loop, refreshing every 5 seconds.
Fix?
SSH to the UCCX, Primary first if you have HA. then run:
utils service restart Cisco DRF Master
wait for that to complete and then run
utils service restart Cisco DRF Local
If you have a second HA server, repeat the process there.
The good news is this is not business impacting.
Normally.
Friday, June 27, 2014
Thursday, June 26, 2014
Cisco WFO QM / Quality Manager maximum call duration
Running WFO QM 9.0.1.57, found users complaining that audio recordings stop at the 15 minute mark. Examining the recordings verses the contact records in QM, I confirmed that the audio recorded is indeed 15 minutes long, while the call duration can be significantly longer.
If you are running 9.0 with Service Release 4, found in Control Panel | Programs and Features in the name column, you can may be able to adjust the CUCM SIP Session Expires Timer to lengthen the available recording duration.
The default is 1800 seconds, meaning CUCM sends a keep-alive to QM at 900 seconds or 15 minutes, and QM responds, but with an invalid codec in the SDP message. The SIP call is dropped at that point and the recording stops.
Supposedly this is fixed in QM 10.0(1).
If you are running 9.0 with Service Release 4, found in Control Panel | Programs and Features in the name column, you can may be able to adjust the CUCM SIP Session Expires Timer to lengthen the available recording duration.
The default is 1800 seconds, meaning CUCM sends a keep-alive to QM at 900 seconds or 15 minutes, and QM responds, but with an invalid codec in the SDP message. The SIP call is dropped at that point and the recording stops.
Supposedly this is fixed in QM 10.0(1).
Tuesday, June 03, 2014
Cisco Unity Connection Single Inbox 401 Authentication Errors - User Name Limitation
This is another variation of things that cause 401 Authentication Errors when setting up Unity Connection Single Inbox. Another example is here: http://webmaxtor.blogspot.com/2013/11/cisco-unity-connection-single-inbox-401.html
After setting up a new Unity Connection 9 cluster to integrate with Exchange 2010, I ran into an issue with the authentication failures when running the test on individual Unified Messaging Accounts. Running the test against the Unified Messaging Service passed, but this typically only verifies basic network access, domain name resolution and access to the Exchange EWS interface. The Single Inbox feature will fail if the users' Unified Messaging Accounts can't authenticate to Exchange.
The "Unified Messaging Guide for Cisco Unity Connection Release 9.x" integration guide is quite good and covers about all the scenarios I've ever run into. Follow the guide, and all of the guide, and you should be in good shape.
Following that , I had an issue where testing the Unified Messaging Accounts failed with a "Failed accessing xxx@ayz.com Diagnostic=[] Verb =[] url=[] request=[] response[]" message. It is a 401 error, pointing to basic authentication against Exchange issues.
Basic troubleshooting steps, found in just about every Unity Connection guide are:
Check the authentication method on both sides. Check settings in Internet Information Services (IIS) for both AutoDiscover and EWS.
- This was confirmed to be NTLM and HTTPS, under both EWS and Autodiscovery
Try different UM messaging account name formats (i.e. NAME, DOMAIN\NAME, NAME@DOMAIN).
- Tried every combination of names
Reset the UM messaging account password, and enter the password again on Unity Connection.
- Verified name and password via OWA
The UM account should not have a mailbox.
- Verified no Exchange mailbox with admin.
- Another nice method to confirm this again using OWA to check the username and password above. You should be returned an error indicating there is no mailbox for the user.
This technique provided the clue I overlooked a dozen times. There was indeed no mailbox for the user ConnectionUMServices.
Ultimately the issue was that when the UM user account name was created, to keep it obvious and consistent over time, we used a reference straight out the Cisco Unified Messaging Guide. The username for the account we created was ConnectionUMServicesAcct, an example name from the integration guide. The problem here is that when Unity Connection attempts to authenticate against Exchange to synchronize mailboxes, it uses the pre-Windows 2000 logon name format. That format has a 20 character limitation, so the appropritate name entry in Unity Connection is then ConnectionUMServices, not ConnectionUMServicesAcct.
Change the UM Messaging account name in Unity Connection to the pre-Windows 2000 (shorter) name and bingo, you are good.
After setting up a new Unity Connection 9 cluster to integrate with Exchange 2010, I ran into an issue with the authentication failures when running the test on individual Unified Messaging Accounts. Running the test against the Unified Messaging Service passed, but this typically only verifies basic network access, domain name resolution and access to the Exchange EWS interface. The Single Inbox feature will fail if the users' Unified Messaging Accounts can't authenticate to Exchange.
The "Unified Messaging Guide for Cisco Unity Connection Release 9.x" integration guide is quite good and covers about all the scenarios I've ever run into. Follow the guide, and all of the guide, and you should be in good shape.
Following that , I had an issue where testing the Unified Messaging Accounts failed with a "Failed accessing xxx@ayz.com Diagnostic=[] Verb =[] url=[] request=[] response[]" message. It is a 401 error, pointing to basic authentication against Exchange issues.
Basic troubleshooting steps, found in just about every Unity Connection guide are:
Check the authentication method on both sides. Check settings in Internet Information Services (IIS) for both AutoDiscover and EWS.
- This was confirmed to be NTLM and HTTPS, under both EWS and Autodiscovery
Try different UM messaging account name formats (i.e. NAME, DOMAIN\NAME, NAME@DOMAIN).
- Tried every combination of names
Reset the UM messaging account password, and enter the password again on Unity Connection.
- Verified name and password via OWA
The UM account should not have a mailbox.
- Verified no Exchange mailbox with admin.
- Another nice method to confirm this again using OWA to check the username and password above. You should be returned an error indicating there is no mailbox for the user.
This technique provided the clue I overlooked a dozen times. There was indeed no mailbox for the user ConnectionUMServices.
Ultimately the issue was that when the UM user account name was created, to keep it obvious and consistent over time, we used a reference straight out the Cisco Unified Messaging Guide. The username for the account we created was ConnectionUMServicesAcct, an example name from the integration guide. The problem here is that when Unity Connection attempts to authenticate against Exchange to synchronize mailboxes, it uses the pre-Windows 2000 logon name format. That format has a 20 character limitation, so the appropritate name entry in Unity Connection is then ConnectionUMServices, not ConnectionUMServicesAcct.
Change the UM Messaging account name in Unity Connection to the pre-Windows 2000 (shorter) name and bingo, you are good.