Backups failing with Event ID 904

One of our clients was having an issue with backing up Exchange 2007 using Ahsay Online Backup Manager.  The backups were failing nightly and Ahsay was returning the error CExBackup::backupService:HrESEBackupSetup: Error Number 0xc7fe1f45: Instance not found.  A search of this error revealed that this error originated in Exchange and passed through to Ahsay.  Checking the Application event log showed that for every failed backup there was an error with Event ID 904. The source is ESE Backup and the error text is Information Store (3396) Callback function call ErrESECBPrepareInstanceForBackup ended with error 0xC7FE1F45 Instance not found. Researching this error online mostly pointed to this Microsoft Knowledge Base article, http://support.microsoft.com/kb/924204.  However the article says this error occurs when the drive containing the transaction logs is full and I knew that this did not apply to the issue our client was having as they had nearly 245GB free on the drive where the transaction logs were stored. I continued to search for answers and came across this posting from 2006; http://forums.msexchange.org/m_1800413118/mpage_1/key_/tm.htm#1800413118.  In this forum thread the user Joseph Finnie reported that he observed this error when attempting to backup Exchange 2007 while a Recovery Storage Group was present on the server. I checked the Exchange server for the presence of a RSG by opening the Exchange Management Console, selecting Toolbox and then selecting Database Recovery Management.  This opens the Microsoft Exchange Troubleshooting Assistant.  After the TA connects to Active Directory you will come to a page that says “Select one of the following tasks” and the section you want to look under is “Manage Recovery Storage Group.”  If there is an RSG present, click the link...

Music On Hold Streaming from an FXO port on CME 8.8

Here’s another CME feature that did not work quite as expected when reading the documentation.  As with the conference bridge, I read along and followed the documentation from Cisco for “Configuring Music on Hold from a Live Feed” (the link is below) and the feature was still not working.  When placed on hold, all callers heard was the default Cisco MOH audio file.  This showed that the fall back portion of the config was working fine but overall something was missing. “http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmemoh.html#wp1010511 According to Cisco all that is required is a cable to connect to your live feed device, a fxo or e&m port, a dial-peer and an ephone-dn. The cable we made on our own out of a bit of cat5, a RJ11 head and male to mail 3.5mm audio cable. For those interested, the 3.5mm cable was the type with one wire running through the middle and another wrapped around like a sheath.  The blue pair of the cat5 was then connected to the two lines from the audio cable using a couple of butt splices.  These were then wrapped individually with electrical tape to prevent interference and then all wrapped together to make the finished product a little less rough (pictured below). A RJ11 head was then connected to the other end of the cat5 using the blue pair in the middle two pins. I initially thought the issue might be with my homemade cable as it does look a little kludgy but I wanted to continue researching to eliminate all configuration issue. Again, another user saved the day by providing portions of a working config...

Configuring a conference bridge in Cisco CME

I recently ran into an issue configuring a conference bridge for a client. What makes this particular problem worth sharing is that I found the documentation provided by Cisco on this issue to be a little confusing and a little unhelpful. The initial document I used to try to configure this issue can be found here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeconf.html#wp1021179. In particular what confused me were the differences in step 5 of “Configuring SCCP for Cisco Unified CME” and step 3 of “Associating Cisco Unified CME with a DSP Farm Profile.”  I have included the full configuration example of both of these sections below. As you can see, if you follow the configuration examples in this document, you end up with two separate groups, one which contains the binding of an interface and another which associates your configured CME router and the DSP farm profile with a group.  The problem with this is that all of these commands should take place in  the same group.  There is also nothing in the “Purpose” section to indicate that these groups should in fact be one and the same.  Additionally, step 5 in “Configuring SCCP for Cisco Unified CME” turns out to not be needed at all but this is probably due to the document being outdated. Additionally, most configuration documents I’ve read on Cisco’s site include at least some troubleshooting information.  This document lists commands you can issue to see if things are working but leaves many out and doesn’t include any advice on how to fix issues. Luckily, while researching this online in order to get the conference bridge working right I did find a much...

MWI with Exchange 2010 and Cisco Unified Communication Manager 7

An exciting feature of Exchange 2010 is its support for message waiting indicators (MWI).  While this doesn’t seem like that big of a deal, one of the biggest complaints about Exchange 2007 was its lack of MWI support.  Even though Exchange Unified Messaging is able to send voicemails to an email address, most users are accustomed to the phone notifying them when they have new voicemail. Even more exciting were the reports that MWI with Exchange 2010 and Cisco CallManager 7 just worked out of the box without extra configuration. Many articles I read spoke of the ease of configuration at getting this feature enabled. This, however, was not the case in our lab.  As it turns out, some of the default settings for SIP trunks in CCM 7 will cause problems with MWI. I began troubleshooting by using Microsoft Network Monitor 3.0 to track SIP traffic across the trunk.  I found that the Exchange server was sending a SIP Notify message to my softphone by way of CallManager but CallManager was returning a reply of SIP/2.0 403 Forbidden.  There were also corresponding errors in the Exchange Application Log with Event IDs of 1342 and 1344.  The error with Event ID 1342 read An error occurred while sending MWI notification ‘0/2 (unread/read)’ for mailbox ” associated with UM extension ”. The target selected was ‘CCM’. A different target will be attempted. Additional information: Microsoft.Exchange.UM.UMCommon.MwiTargetException: An error occurred while attempting to deliver an MWI message using target CCM. —> Microsoft.SpeechServer.SipPeerException: A SIP NOTIFY message has failed. —> ResponseCode=403 ResponseText=Forbidden Microsoft.Rtc.Signaling.FailureResponseException: The requested operation failed. at Microsoft.Rtc.Signaling.SipAsyncResult.ThrowIfFailed() at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult asyncResult) at Microsoft.Rtc.Signaling.RealTimeEndpoint.EndSendMessage(IAsyncResult asyncResult)...

Cisco Unified Communications Manager Handset Workaround

One of my favorite things about my job is working with Cisco’s Unified Communications Manager (CUCM). It’s so robust and complex that there always seems to be something new to learn.  Last week I ran into a couple of interesting issues that I thought I’d share with you. The first is an issue for which I’ve been trying to find a solution for several weeks.  One of our clients was experiencing issues with external auto-attendants recognizing the DTMF tones their phones were sending.  What made this issue particularly strange is that if the user was on speaker phone they were able to get the remote AA to respond to the DTMF tones without issue. I searched Google several times with various terms looking for this issue and was finally able to find a thread concerning DTMF working on speakerphone but not on the headset in CUCM.  Someone in the thread had opened a bug report, number CSCsv04751, and this led to a resolution. The following is an excerpt from the Bug Details on Cisco.com: Symptom: Duplicate DTMF is detected and users have problems entering DTMF mid-call.  The side tone from the phone appears to be introduced into the RTP stream in addition to the out-of-band signaling normally sent. Workaround: Both speaker phone and the headset use a different side tone than the handset and they should not experience the same DTMF problem.  Downgrading the firmware is the only other workaround. Basically what was happening is that CUCM was sending both the in-band, which would only be recognized by other Cisco equipment, and the out-of-band DTMF tones, which we have...