OCS Create Pool Step Failure Drops Conference Directories

Something to keep in mind before you ever move an OCS database is that you'll want to grab backups of the user data and conference directories so that you can restore the data just in case anything goes wrong with your move operation. The conference directory objects map conference IDs and passcodes used by PSTN dial-in users to a specific Live Meeting instance. These objects are stored in Active Directory and not in the OCS back-end database like you might expect, but you can still back up all the data these objects hold.

You can export all user data and conference directories with the following command:

dbimpexp.exe /hrxmlfile:everything.xml /sqlserver:SQL.ptown.local\OCS

I usually also grab a separate backup of just the conference directories from the pool:

dbimpexp.exe /hrxmlfile:confdirs.xml /sqlserver:SQL.ptown.local\OCS /restype:confdir

After these run successfully you can copy these files off to a safe place and then proceed with your database operations.

As you are moving the databases around one of the steps on Technet will have you re-run the Create Pool wizard, but if this step fails for any reason the installer will kick into its rollback mode and remove any configuration changes it made. What's not terribly apparent is that part of this rollback process removes all conference directories on the pool without any warning.

So say this step fails on something silly like a file share permission you'll suddenly find you dropped all your conference directories. The end result of that is users calling in to meetings via PSTN will no longer be able to enter conference ID and passcode to join the meetings hosted on that pool.

I recently ran a DB move and the user account we used did not explicityly have Full Access rights to one of the OCS file shares (it had been removed at some point for an unknown reason), but the result was the Create Pool operation kicked into rollback mode and removed the pool's conference directories. We had a solid backup of these to restore from, but this customer had previously lost the directory the first time they tried this operation on their own because of the same problem.

If the directories are dropped and you don't have a backup via DBImpExp.exe you'll need to recreate the conference directories on the admin side, but the big pain point is that all users will need to reschedule their meetings (because the previous ID/Passcode mappings are no longer valid). It's a really ugly user experience and likely to not go over very well. If only you had backed these up in advance!

I would imagine you could restore the conference directory object stored in AD and possibly get that hooked back up to OCS, but your best bet is really to be using DbImpExp.exe instead. A general best practice for any OCS environment is to be taking regular backups of your OCS data and conference directories via DbImpExp.exe so that way you'll never find yourself in this situation.

If your Create Pool step does fail at least one time you'll need to restore the directories because they've been dumped. After you work out the Create Pool step issue and succeed in starting up your Front-End services you can proceed with the conference diretory restore.

The syntax to restore just the conference directories from the pool is:

dbimpexp.exe /import /hrxmlfile:confdirs.xml /sqlserver:SQL.ptown.local\OCS /restype:confdir

After running this you should be able to dial in via PSTN and enter a conference ID and passcode from a pre-existing meeting again.

Lync Dial-In Conferencing Static Route Configuration

Something I haven't seen documented with Lync Server 2010 so far is the dial-in conferencing configuration required to enable outbound dialing. This allows non-Enteprise Voice Lync, Lync Web App, or Lync Attendee users to join the conference by having the conferencing service call outbound to them as opposed to them manually dialing in to the conference and entering conference ID and passcodes.

In OCS 2007 R2 this was accomplished by adding a static route from the Front-End pool to a Mediation server for phone URI requests. The concept in Lync is the same, but there is a slight difference in ports used because the Mediation service in Lync now listens on Port 5070 for server-to-server traffic as opposed to 5061 in OCS 2007 R2. The route configuration also varies a bit. In the example below I have a Mediation server role collocated with my Front-End pool, fepool.confusedamused.com.

As Mike Stacy has already pointed out, the GUI for configuring static routes is now gone and must be done through the Lync Management Shell. To get started, we need to create the route statement and store it in a temporary variable. Replace the destination with your Mediation server pool FQDN and the matching URI with your own SIP domain:

$route = New-CsStaticRoute -Destination "fepool.ptown.local" -Port 5070 -MatchUri "confusedamused.com" -MatchOnlyPhoneUri $true -TLSRoute -UseDefaultCertificate $true -ReplaceHostInRequestUri $true

Then, we can assign the route to the global configuration:

Set-CsStaticRoutingConfiguration Global -Route @{Add=$route}

You should see the Front-End pick up this change within 5 minutes (another nice change over OCS 2007 R2) with an event log entry:

The observant folks here who have configured this in OCS 2007 R2 might have noticed the Replace host in request URI option wasn't necessary back then. What I've found is that not selecting this option in Lync causes the calls to fail for non-Enterprise voice users. The SIP invite that gets sent to a Mediation server will typically look like this for an outbound call when the Replace host in request URI option is not selected:

INVITE sip:+12223334444@confusedamused.com;user=phone SIP/2.0
FROM: <sip:eddie@confusedamused.com;gruu;opaque=app:conf:audio-video:id:GJ5CPPSK>;epid=C68D6F45DA;tag=7ee8ecfbea
TO: <sip:+12223334444@confusedamused.com;user=phone>

This request will actually fail and you'll see a SIP 488 Not acceptable here error message, followed by a SIP 503 Service unavailable error on the Mediation server. If you look at the trace you'll find the following detailed error:

ms-diagnostics-public: 10025;reason="Gateway peer in outbound call is not found in topology document";component="MediationServer"

What this boils down to is the call won't route because the host the INVITE is addressed to (@confusedamused.com) isn't actually part of the topology. If the Replace host in request URI option is selected, the SIP INVITE sent to the Mediation server replaces the @confusedamused.com with the actual destination in our route, @fepool.ptown.local, as seen below. Notice the difference in the first line, where the Mediation pool name has now replaced the previous host of just confusedamused.com. This call will be successful:

INVITE sip:+12223334444@fepool.ptown.local;user=phone SIP/2.0
FROM: <sip:eddie@confusedamused.com;gruu;opaque=app:conf:audio-video:id:F0GS16HB>;epid=BFDBD3B7B8;tag=42bd8c5b8
TO: <sip:+12223334444@confusedamused.com;user=phone>

I'll throw out a disclaimer that the officially documented process may be different and that I may have to update this later, but I wanted to at least share what I've got working so far.