I’ve spent a lot of time in the past 12 months working with the <verb>-CsUserData commandlets in SfB, and it’s been an interesting time.
This is part 4 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.
Part 4 – You can’t trust Import-CsUserData to tell you if it fails
Having abandoned Update-CsUserData we moved to Import-CsUserData, but that wasn’t the bed of roses we were expecting either.
| TL;DR: DON’T run “Import-CsUserData” without the -Verbose switch, and make sure you pay attention to its output. If it has some objection to your XML or ZIP file it might silently fail. Only with the -Verbose switch will you know for sure*. |
(*) And even then I wouldn’t bank my career on it.
Here’s a screen-grab of Import-CsUserData in operation:
Here’s the same with the -verbose switch:
Import of User urn:lcd:greig@gisandbox.com is skipped due to Filter. Import of User urn:upc:greig@gisandbox.com is skipped due to Filter.
And yes, as per the second image, it failed. I had expected Greig to end up with a bunch of new contacts as a result of this import, however he did not.
The Fix
As I reported in Part 1, Update-CsUserData -TestMode only appears to test syntax, so it isn’t able to help us here.
The only way to tell for sure is to do “before” and “after” exports of each user and compare them.
Revision History
15th February 2020: This is the initial publication.
– G.
