I recently came across an issue when one of my peers in the enterprise voice group helped integrate their existing on-premise Lync 2010 environment with hosted voicemail in the cloud. We followed the recommended steps outlined in these series of TechNet articles and other publications and everything seemed to work fine with a few test accounts. However, in a small pilot, we uncovered an issue when we discovered that our pilot users were getting fast busy signals when you would dial their extensions. Everything worked fine for the mail migration and we were using an Exchange 2010 hybrid server. After some searching we uncovered the root cause of our problem.
One of the two Lync commands we ran after someone’s UM-enabled mailbox was migrated to the cloud was this:
Set-CsUser -Identity “John Doe” -HostedVoiceMail $True
The AD attribute that gets updated is msExchUCVoiceMailSettings. When run from the Lync server the value for this is set to CsHostedVoiceMail=1. This was getting correctly set with our scripts but each time dirsync would run it would get wiped out. It turns out this is one of those write-back attributes that you can enable with dirsync when you configure dirsync for rich coexistence using a hybrid server. So the issue is that this attribute is a one-way sync from the cloud to on-premise and each time dirsync would run it would wipe out our value to null because that is what was in the Metaverse on the dirsync server. The other strange thing is that we saw our test accounts work but their value for this AD attribute was ExchangeHostedVoiceMail=1 since the cloud set this value after we migrated the UM-enabled mailbox. Both values work fine and allow voicemails to be forwarded to the cloud mailbox. The problem here is that there seems to be a significant delay as to when this attribute actually gets stamped on the cloud account. I timed it during our next migration and it took about 90 minutes for the cloud mailbox to have this attribute set. Needless to say, though, this was an unacceptable scenario with my client since they heavily used Lync and voicemail.
The workaround was actually simple. Since dirsync was the one overwriting the local AD attributes and was taking so long that we couldn’t rely on the provisioning process to immediately update it, I decided to take dirsync out of the mix for that particular attribute. To do this I edited the SourceAD Management Agent’s properties and removed the attribute from the Attribute Flow section as shown in the image. After that I was able to use Lync to set the local AD attribute and forward voicemail immediately to the cloud mailbox without waiting for dirsync to catch up.
The downside, however, is that does leave you technically in an unsupported dirsync scenario and if you were to reinstall dirsync you would need to reconfigure it if you wanted to have no delays in setting this attribute quickly. Doing this minor surgery on dirsync is probably good while you’re doing migrations but if you can normally wait the 90 minutes or so for newly created cloud accounts (i.e. new hires), then it’s probably best to leave dirsync alone and let it do its job.
Note: Use this solution at your own discretion.
Lync 2010 integration with Exchange Online Hosted Voicemail
by Erik Enger on March 26th, 2013 | ~ minute read
