On completion of a Skype for Business hybrid configuration (and all things being well), you should find yourself in the luxurious position of being able to move users from your on-premises servers to O365, and vice-versa. “Failed to Connect live ID Servers…” is an error you might receive if you’re attempting to perform this ‘move’ action through the Skype for Business control panel rather than using the management shell. If you experience this issue (as I did) then you’ll see an error generated within the Skype for Business control panel at the point of execution…
“Failed to connect live id server. Make sure the proxy is enabled or machine has network connection to live id servers”
…and an unhelpful windows event error logged in the application node in event viewer.
Error
Source MSOIDSVC.EXE
Event ID NULL
Task Category NONE
The description for the Event ID from source MSOIDSVC.EXE cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
As mentioned, utilising the management shell to move users worked fine. But if you’d prefer to use the GUI to complete the work then you’ll need to make a few permission changes. The following permissions were granted to the NETWORK SERVICE account for the respective folders on all Front End servers.
Read
%windir%System32configsystemprofileAppDataLocal
Full Control
%windir%System32configsystemprofileAppDataLocalMicrosoftMSOIdentityCRL
Unless you have further underlying problems, as soon as these changes are applied you’ll be able to move users to O365 and back through the control panel. There are numerous articles that reference similar problems across the bazaars, where the same permissions issues have caused a problem signing into O365 through the hybrid wizard. I should mention that this wasn’t the case for me at all, and that it was solely the ‘move user’ actions that I was having a problem with – hybrid configuration and O365 sign-in through the wizard worked fine. As I don’t envisage finding the will power to test this functionality across multiple versions, host operating systems, or patch levels, I can only speculate as to when this problem came about, and if it might only affects particular configurations. I did however take the time to see if I could be any more restrictive on the aforementioned folder permissions, and can confirm that it is not possible to be any more granular permissions-wise without breaking the functionality….again.
