Lync 2013 Migration from Lync 2010 UpaSeparator Issue

Recently working with a client on a Lync migration from 2010 to 2013.  The Lync 2010 environment had been working with no issues to note.  Replication was working fine, publishing the topology was working fine, adding/editing objects via the Lync Control Panel was working fine.

Since there were no signs of potential lurking issues, building the Lync 2013 topology was the next step; as the schema had been updated to the correct value in the CN=ms-RTC-SIP-SchemaVersion attribute per this article on schema verification.  The topology was defined with the new Lync 2013 pool and successfully published.  So far so good, until Step 1 of the Deployment Wizard was run.

Step 1 fails per the red text and error message in the GUI and spits out the following error:

LocalStoreThe element ‘TrunkConfiguration’ in namespace ‘urn:schema:Microsoft.Rtc.Management.Settings.TrunkConfiguration.2009’ has invalid child element ‘UpaSeparator’ in namespace ‘urn:schema:Microsoft.Rtc.Management.BaseTypes.2008’. List of possible elements expected: ‘OutboundCallingNumberTranslationRulesList’ in namespace ‘urn:schema:Microsoft.Rtc.Management.Settings.TrunkConfiguration.2009’ as well as ‘PstnUsages’ in namespace ‘urn:schema:Microsoft.Rtc.Management.Policy.Voice.2008’ as well as ‘UpaSeparator2’ in namespace ‘urn:schema:Microsoft.Rtc.Management.Settings.TrunkConfiguration.2009’

This error seems to come from the Import-CsConfiguration process, seeing the error is right after this command on the screen.

Now this error tells a bit of information in a general direction.  Since it first mentions ‘TrunkConfiguration’ that is a good place to start looking for an error.  So, moving thru all the trunk configuration rules in the Lync Control Panel, nothing appears to be a culprit of the error.  Maybe there is a rule that just needs to have an attitude adjustment made to it.  An innocuous change was made to each of the trunk configuration rules in hopes that would correct the offending object.

Unfortunately this didn’t have the desired effect that was anticipated.  Since the error didn’t help show which rule might be the offending one further analysis was needed.  Since the cmdlet was doing the importing, it must have a file to import.  After finding the file that the wizard created to use for the import process, the XML file needs to be searched.  Using the ‘urn:schema:Microsoft.Rtc.Management.Settings.TrunkConfiguration.2009‘ text from the error, more than 100 matches were found in the file.  This client has a large number of rules, so YMMV (your mileage may vary.)  Looking at each one of these and comparing them to others in the file, there was one that stood out as an oddity.  This one rule actually had two of these lines in it:
<UpaSeparator xmlns=”urn:schema:Microsoft.Rtc.Management.BaseTypes.2008″/>
<UpaSeparator xmlns=”urn:schema:Microsoft.Rtc.Management.BaseTypes.2008″/>
This was the only noticeable difference between this one rule and all the others.  This had a probability of being the offending object.  Not being an expert on XML syntax it looked proper, with a beginning tag and an ending tag, but still there were two of them and no other rules had two.

So thinking about the ways to fix this, there were a few options to think about.  One being edit the XML with removing one of these extra lines, another being adding a new gateway/trunk to the topology and moving the existing rules to the newly created trunk, and the last was just to delete and recreate the configuration rules for that trunk.  Not entirely sure if the error was on the rules or the actual trunk itself there was a plan in place to go from least impacting to most.  By this time editing the XML and importing it was taking a far back seat as far as an option.

So the plan was in place to change the trunk configuration for that trunk and a plan to create a new trunk if the first option did not provide success.  Fortunately, the trunk configuration rules was the process that fixed the issue.  After changing the trunk configuration rules and looking at a fresh XML file from an Export-CsConfiguration, the redundant offending line was no longer present.  The next step to be sure this was the actual root cause of the issue, Step 1 of the Deployment Wizard was run and success was seen by that all too friendly green check mark in the wizard.

The original cause of the redundant line in the XML is unknown.  Was it the Lync 2013 tools that put it there when the Export-CsConfiguration was run during that first step in the wizard or was it there and just not causing an issue with the Lync 2010 tools?  One might never know.


Copyright © 2014. Lync it! All rights reserved.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s