Adventures with Import- and Update-CsUserData Pt.1

I’ve spent a lot of time this year working with the <verb>-CsUserData commandlets in SfB, and it’s been an interesting time.

This is part 1 in a series where I document the traps I’ve fallen into with the Import-CsUserData and Update-CsUserData commands in particular.

Part 1 – Update-CsUserData fails on bad data.
Part 2 – Your Front-End won’t start after Import-CsUserData imports bad data.
Part 3 – Update-CsUserData throws false red and runs slow if your paired pool is offline.
Part 4 – You can’t trust Import-CsUserData to tell you if it fails.

Background

My customer is a LARGE deployment, and they’re moving from Lync 2010 in a user forest to SfB 2015 in a resource forest. In an effort to make this transition as seamless as possible for the users, the plan is to migrate all their contacts (their “buddies”) from the existing platform to the new.

The approach we’ve taken breaks the process into multiple steps:

Export-CsUserdata on Lync.
Use a bespoke PowerShell script to break down the single data export (all 10+ Gig of it) into a contact list XML file for each user.
Use Convert-CsUserData and the “-TargetVersion Current” switch to convert each user’s file from Lync’s XML to SfB’s ZIP format.
Sanity-check each user’s file with “Update-CsUserData -TestMode”.
Import the data. We initially chose “Update-CsUserData” and fell into a hole, so we changed to “Import-CsUserData” – and fell into a different one.

This series will document those bugs and hopefully prevent others from earning the same scars.

Part 1 – Update-CsUserData fails on bad data

TL;DR: It looks like “Update-CsUserData -TestMode” tests the syntax of the file, but not its content. If you have some nasties in the file that happen to be in well-formed XML, -TestMode will give it the thumbs-up, only to have the Update fail.

I hit this error recently trying to use Update-CsUserData to import a user’s contacts:

Update-CsUserData : Exception from HRESULT: 0xC3EE7950

This struck me as odd, as “Update-CsUserData -TestMode” had run fine just prior:

I was using the .ZIP version of the user’s contacts file, and I know SfB is OK importing the .XML, so I tried that as well. No dice – same error.

I chanced upon this in the event log(*):

Event 32209, LS User Services
Failed update user data in local database during move.
Execution Error: OxOOOOOOOO(ERROR_SUCCESS).
Native Error: 2627.
Error Details: [# [Microsoft][SQL Server Native Client 11.0][SQL Server]Violation of PRIMARY KEY constraint 'PK_#B9733B6_66842180E5F746AD'. Cannot insert duplicate key in object 'dbo.@Contact'. The duplicate key value is (User@sipdomain). #][# [Microsoft][SQL Server Native
Client 11.0][SQL Server]The statement has been terminated. #][# [Microsoft][SQL Server Native Client 11.0][SQL Server]###50001:UserMgmtSetHomedResourceDataXml:Propagation #].
Cause: This may indicate a problem with connectivity to local database or some unknown product issue.
Resolution:
Ensure that connectivity to local database is proper. If the error persists, please contact product support with server traces.

“Cannot insert duplicate key in object ‘dbo.@Contact'” and a SIP address was all the prompting I needed to go hunting in the user’s buddy list XML file, and what I saw struck me as odd:

Rocky’s not meant to be there twice! In his first appearance he’s a member of only group 1, and yet he reappears later as a member of Groups 1 and 2!

The fix was some hand-editing, removing the unwanted dupe (the first record). A quick repeat of the Update-CsUserData commandlet against the edited file completed OK.

Lesson learnt: you can’t rely on ~~Lync 2010 to only export ‘good’ data, nor~~ Update’s -TestMode to find it if it’s not.

Confession: this issue wasn’t caused by Lync 2010 exporting bad data – it was all of my own doing. I had scripted a SIP domain change of some buddies in the export/import process, and this resulted in the odd accidental dupe.

(*) In this Lab reproduction of the issue, the event was on the user’s home FE, a standard edition server, and not on the SE FE from which I was issuing the commands. In an Enterprise Edition deployment I can’t say for sure where the event will land. Will it be on a random FE in their pool, or will it be on the user’s Primary server?