After running Move-CsConferenceDirectory I could verify the move was in progress, but it never completed. The status would show it was trying to move, and OCS eventually started throwing errors that it no longer had a conference directory, but it never fully made it to Lync. The TargetServerIfMoving parameter stayed populated:

Get-CsConferenceDirectory -Identity 5
Identity: 5
ServiceId: UserServer:OCSPOOL.ptown.local
TargetServerIfMoving: UserServer:LYNCPOOL.ptown.local

Trying to run Move-CsConferenceDirectory again would consistently fail with the following errors:

WARNING: Move operation failed for conference directory with ID "5". Cannot perform a rollback because data migration might have already started. Retry the operation.
WARNING: Before using the -Force parameter, ensure that you have exported the conference directory data using DBImpExp.exe and imported the data on the target pool. Refer to the DBImpExp-Readme.htm file for more information.
Exception from HRESULT: 0xC3EE7950, Microsoft.Rtc.Management.ConferenceDirectoryCmdlets.MoveConferenceDirectoryCmdlet

In the end I needed to export the data from the OCS directory via DbImpExp, force the directory to move, and then import the data. Not the cleanest route, but it works. The order is important, so be patient.

On the OCS pool and database export the conference directory data:

DbImpExp.exe /hrxmlfile:C:\Temp\OCSDirectory5.xml /SQLServer:OCS-SQL.ptown.local /restype:confdir

Only once you're positive you have a good export (Read: opened the file and checked!), and made a copy of it you can force the Move-CsConferenceDirectory operation:

Move-CsConferenceDirectory 5 -TargetPool LYNCPOOL.ptown.local -Force

Congrats. You've moved the directory to Lync, but it's empty. Copy the .xml export file to a FE in the Lync pool. On the Lync pool and database import the directory data while specifying the conference directory ID to recover the old data:

DbImpExp.exe /import /hrxmlfile:C:\Temp\OCSDirectory5.xml /SQLServer:LYNC-SQL.ptown.local /restype:confdir /dirid:5

At this point I could see the directory was no longer moving because TargetServerIfMoving was empty, and the conference attendant was now recognizing PSTN IDs which had been created against this directory.

Get-CsConferenceDirectory -Identity 5
Identity: 5
ServiceId: UserServer:LYNCPOOL.ptown.local
TargetServerIfMoving: 

Again, this is a good reason to always do a DbImpExp.exe dump before moving directories or databases around. Those .XML files can save your skin!

In order to track this usage I’ve come up with a Powershell script which grabs these two counters, parses their values, adds them together, and dumps the output into a CSV file. At the end of the monitoring period you can take this CSV into Excel and easily find the peak total call count.

Here are some notes on the behavior:

The caveat with the Lync version is now that a Mediation server can use multiple gateways we can’t see which gateway is being used for each inbound or outbound call. But this still gives an idea of concurrent call capacity flowing through each Mediation role.

• OCS Version: OCSCallData.ps1
• Lync Version: LyncCallData.ps1

I hope to improve this in the future, but wanted to make it available for everyone sooner than later.

For starters, we followed the steps outlined on Technet. After we had successfully detached and attached all databases and ran the LCSCMD.exe step, we launched the Create Pool wizard and attempted to plug in the info for the new SQL cluster. We got this error back:

An error occurred during the pool backend detection:

Pool backend discovery failed.

Invalid database parameter.

I double-checked the server name, instance, and FQDN and all looked well. We verified the SQL server was accessible via TCP 1433 and no firewall rules were preventing access, so the error didn’t make a lot of sense. Obviously there was some kind of parameter that the wizard GUI was not cool with. I thought maybe this was the SQL allow updates issue, but that solution had no effect on this error. There was definitely some validation check the UI was failing on against our new DB.

Since I couldn’t locate anyone else with this issue I figured my options were to call PSS and extend this process by a few hours, or pull out the ol’ LCSCMD.exe again and try this operation via command line. The Create Pool wizard really is just collecting a bunch of information and then using it to execute the LCSCMD.exe commands in the background so while doing it manually is not fun, it works just as well.

The entire syntax for LCSCMD.exe can be found on Techet, but here is the command we ended up running. Please note, conferencing archiving was not implemented so that paramter is not present.

LCSCMD.exe /Forest /Action:CreatePool /PoolName:MyOCSPool /PoolBE:MySQLServer.ptown.local\OCSInstance /PoolFQDN:MyOCSPool.ptown.local /InternalWebFQDN:MyOCSPool.ptown.local /ExternalWebFQDN:PublicOCSWebComponents.confusedamused.com /RefDomain:ptown.local /ABOutputlocation:\\MyFileServer\AddressBook /MeetingContentPath:\\MyFileServer\MeetingContent /MeetingMetaPath:\\MyFileServer\MeetingMetadata /AppDataLocation:\\MyFileServer\AppData /ClientUpdateLocation:\\MyFilerServer\ClientUpdates /DBDataPath:"D:\Databases" /DBLogPath:"L:\Logs" /DynDataPath:"D:\Databases" /DynLogPath:"L:\Logs" /ABSDataPath:"D:\Databases" /ABSLogPath:"L:\Logs" /ACDDataPath:"D:\Databases" /ACDLogPath:"L:\Logs"

After running the command manually it succeeded with absolutely no issues. The new cluster has been running for over a week now without any issues so I think this is an problem specific to the UI. I’m not sure exactly what causes it, but our environment was running SQL 2008 with SP2 on top of a 2008 R2 SP1 operating system.

As a sidenote, this process seems to undo any changes made by the OCS2009-DBUpgrade.msi patches. You’ll need to re-run the patch version which lines up with your FE patch levels before the FE services will be able to start.

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.

If you accepted the default configuration and SIP URI (a random GUID), the SIP enabled contact representing this dial-in access number would be stored within Active Directory in the Configuration context. Specifically, it would be placed in CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=ptown,DC=local.

Or, if you pressed the Advanced button you could specify an existing contact object to associate with the dial-in number. This allowed you to create contacts in advance which would represent these numbers. This process worked just fine in OCS and really had no negative impact.

However, when you go to move these custom contact objects to Lync as part of your migration process you’ll find Lync doesn’t really “see” these objects. If you run Get-CsApplicationEndpoint you should notice that Lync will only return objects within the Application Contacts container mentioned previously. Any SIP-enabled contact objects outside of this location are not returned.

As an added bonus you can actually find (and move!) these objects by specifying their entire DN when running Get-CsApplicationEndpoint. But after successfully moving these endpoints you’ll notice they still do not appear as a dial-in number in Lync. So even though the contact is now homed to the Lync pool, the server still only considers objects in the Application Contacts container a valid dial-in access contact and these numbers don’t go out on meeting invites.

In order to get these numbers fully moved to Lync you’ll need to do the following:

1. Leave the contact object homed to the OCS pool
2. Disable the contact for OCS
3. Recreate the dial-in access number within Lync

Also, be sure to pay attention to the migration docs and only perform these steps after all users are moved to the Lync pool. If you disable the OCS contact before that point any new meeting invitations created by a user on the OCS pool won’t have the deleted dial-in number available.

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.

There was a problem connecting to Microsoft Office Outlook. Your Outlook profile is not configured correctly. Contact your system administrator with the information.

After double checking the lengthy KB 2373585 article discussing Outlook/Communicator errors and ruling out the usual suspects I was stumped. After some digging around on the workstation I found the user had the Exchange 2003 System Manager and tools installed on the machine. Since the System Manager uses a slightly different version of MAPI components Communicator would generate this error immediately upon signing in.

The solution is to open a command prompt and just run the command: fixmapi.

Event ID: 30968
Source: Live Communications User Services
Details: The component Live Communications User Services reported a critical error: code C3EE78F8 (Enterprise Edition Server successfully registered with the back-end, but a stored procedure version mismatch was detected. The service will not start until this problem is resolved. Cause: The database schema and the Enterprise Edition Server were updated by different installation packages. Resolution: Ensure both the Enterprise Edition Server and back-end were installed or modified by the same installation package. The service has to stop.

Obviously the error verbiage is a bit outdated with references to LCS, but the error is correct – there is a mismatch between the stored procedure versions which makes the Front-End service to fail to start.

To avoid the issue be sure to apply the latest OCS2009-DBUpgrade.msi package before updating any Front-End servers.

A few months back I was involved in a discussion about what the subject name of an OCS Edge Server’s A/V authentication certificate should be. Some folks were saying to use the Edge server’s internal FQDN and others were saying to use the external, public FQDN you define for A/V. I was in the camp using the external name, but the odd thing was both sides said their approach worked. There is definitely some confusion about what name you should use and Microsoft has actually published directly conflicting information which further confuses the issue. Some testing I’ve recently done clears up why so many documents and people contradict each other – the subject name doesn’t matter. Really. You could put whatever you want in that subject name, assign it to A/V authentication and it will work flawlessly. The purpose of this certificate per the Technet documentation:

The private key of the A/V authentication certificate is used to generate authentication credentials.

Specifically, it’s not used for encryption or MTLS even if that’s not made clear anywhere. Let’s take a step back and clarify a few things for some background:

• There are two services that run on the Edge server with "A/V" in the name. If you’re not familiar with the difference, Jeff Schertz’s More on OCS Edge Server Certificates article has a good explanation for some background on what the difference is between the A/V Authentication and A/V Edge services, but basically – the A/V Authentication service is internal facing and A/V Edge Service is external facing.
• There is no certificate assigned to the A/V Edge service because encryption for external A/V traffic is provided by SRTP.
• The certificate for A/V Authentication is only used by internal clients when trying to communicate with an external or federated client. This means you can (and should) use an internal certificate authority to issue this certificate. There is no benefit or need to use a public certificate for A/V authentication.

Let’s walk through a little example here as if I was trying to figure out what name to use for my A/V authentication certificate. I have the following environment:

• Public Domain: confusedamused.com
• Internal AD Domain: ptown.local
• SIP Domain: confusedamused.com
• Edge Server Internal FQDN: edge.ptown.local
• A/V Edge Service FQDN: av.confusedamused.com

So with that information what should I use as the certificate name for the A/V authentication certificate? If you consult the Technet documentation topic Set up Certificates for A/V Authentication you’ll find this note (emphasis is mine):

The subject name should match the fully qualified domain name (FQDN) of the A/V Edge Service published by the external firewall, or the FQDN of the VIP used by the A/V Edge Service array on the external load balancer (that is, if the Edge Servers are load balanced).

So based on that blurb, my A/V authentication certificate subject name should be av.confusedamused.com. Fair enough.

I ran through the OCS 2007 R2 Edge Planning Tool for a sanity check. You can see the result below, but the tool follows the Technet documentation and uses the external FQDN I defined for the A/V Edge Service when it asked.

A group of MVPs and Microsoft employees published a document called Deploying Certificates in Office Communications Server 2007 which says the following about the A/V authentication certificate (emphasis is mine again):

Must be the FQDN of Audio/Video authentication server in DNS.

Well that calls out the name of the authentication server, not the A/V Edge Service. I think this comes down to really just poor wording in the document which contributes to confusion, but what is the name of our A/V Authentication server? It would be the same name as the internal Edge interface, right? The A/V Authentication server is the Edge server, not the external FQDN. So now we’re being told to use the internal FQDN, edge.ptown.local as the subject name.

Also released by Microsoft was a document called OCS 2007 R2 Walkthrough – Scale to Load Balanced Edge Server which completely contradicts Technet and the Edge Planning Tool (emphasis mine):

• Access Edge Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.
• A/V Authentication Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.

This seems to match up with the certificates document and is somewhat backed by the exact same Technet article I referenced earlier which says:

As a security precaution, you should not use the same certificate for A/V authentication that you use for the internal interface of the Edge Server.

This begs the question "Why would I ever even try to use the same certificate?" The only logical reason would be perhaps because they use the same subject name. That jives with the Scale to a Load Balanced Edge Server documentation. If we’re thinking about this in terms of MTLS connections, you would have to think that this makes the most sense. In your OCS Forest properties if you added an A/V Edge server with the name edge.ptown.local for port 5062, it’s reasonable that you’d expect the A/V Authentication service operating on port 5062 of the internal interface to offer a certificate matching this name. If it presented something wrong, say maybe the external FQDN of the A/V Edge service it should fail, right?

Well, the truth is the name doesn’t matter. There isn’t MTLS validation happening on port 5062 the same way you’d expect MTLS between servers on 5061. I think the reason the certificate requirement issue hasn’t been pointed out yet is because it’s never caused a problem – it works either way. I can use a certificate with a subject name gobblygook.confusedamused.com and media relay authentication through the Edge server works just fine. It just needs a certificate to generate authentication credentials for the media relay process. Go ahead and try it out – put whatever name you want on the certificate and it will still work.

So while the subject name doesn’t really matter, if you’re still interested in adhering to best practices I would recommend using the external facing, public A/V Edge name. In the example earlier this would be av.confusedamused.com. Hopefully Microsoft will update the certificate and scaling documents with a clarification and make them more consistent with the rest of Technet.