Windows 2012 Essentials R2 Connector Stops Responding During Install

[Merlin Halteman]

I ran into a very frustrating issue the other day. My job was to join a brand new Windows 10 computer to a domain. The server was running Windows Server Essentials 2012 R2. I felt this would be a simple job- but it didn’t turn out that way.

Typically, I join the computer to the domain using the Windows Server Essentials connector tool. Here are the steps I use below.

Step One: I went //servername/connect and installed the connector software. I rebooted the computer when I was prompted to do so.

Step Two: The computer rebooted and started booting into a _clientsetup_$ profile. The computer took a minute or two but it logged into the _clientsetup_$ profile. I was then prompted to enter the user’s credential’s to connect the computer to the domain.

Step Three: I entered the credentials, and then I selected “Setup this PC for myself”. Instantly, the connector software froze and said: “Windows Server Essentials Connector” has stopped responding, end program. The Connector software closed but the computer kept me logged into the _clientsetup_$ profile until I rebooted the computer.

I then logged into the computer. The computer was joined to the domain but the Connector software was not installed.

I thought this may have been a one-off issue so I tried joining the computer again. Once again, I was greeted with “Windows Server Essentials Connector” has stopped responding. I will list below all the things I tried -none of them worked.

• I tried to join the computer to the domain with the admin credentials instead of the user’s credentials.
• During the Connector software setup, I selected “Setup this PC for myself and others” instead of “Setup this PC for myself.
• I checked Event Viewer. It said clientdeploy.exe has stopped working. Right before that error, I got a .Net framework error as well. I ran the Microsoft .Net Repair Tool. The .Net repair tool didn’t fix my problem, so I turned off .Net framework in “Turn Windows Features On or Off” in Windows. That didn’t work as well.
• Installed the Windows Server Essentials R2 Connector from Microsoft’s website.
• Right-clicked on the connector file and “Ran as an Administrator”
• Connected the laptop via an Ethernet connection (instead of wireless) and ran the wizard.
• I joined the domain manually and then tried to run the Connector software. It still failed.
• I created a new local admin profile and ran the Connector wizard from that profile.
• I rebooted the server.
• Disabled IPv6 on the laptop- we thought maybe there was a conflict
• Renamed the laptop multiple times
• I checked the server. The computer showed up under the devices tab in the dashboard as being on the domain. However, the computer showed offline and the server didn’t know what OS was installed or anything about the client.

I decided to check the Connector software’s log and see if I could learn anything. I browsed to C:\ProgramData\Microsoft\Windows Server\Logs folder. I opened the log and found something very interesting. This is what the log read:

[3704] 160419.115344.2661: ClientSetup: LookupAccountSid (computerName = [], sid = [S-1-5-32-555])
[3704] 160419.115344.5319: ClientSetup: !!!FATAL!!! Unhandled Exception: System.ComponentModel.Win32Exception (0x80004005): No mapping between account names and security IDs was done
at Microsoft.WindowsServerSolutions.ClientSetup.NativeMethods.LookupAccountSid(String computerName, SecurityIdentifier sid)
at Microsoft.WindowsServerSolutions.ClientSetup.User.AddRoles(UserRoles userRoles)
at Microsoft.WindowsServerSolutions.ClientSetup.ClientDeploy.ConnectorWizardForm.m_wizardPageSetupForMyselfOrOthers_

I found this error had to do with a user account issue. I found on Microsoft’s MSDN website that the S-1-5-32-555 SID is a remote desktop users local group. Apparently, the connector was running into some problem with the remote desktop user group.

After doing some searching, I found a forum thread that was detailing the exact same thing – except those computers were running Windows 8. The forum mentioned that the computers that were having issues were mostly computers that had been upgraded from Home to Pro. This stirred my thinking and I remembered that this laptop had been upgraded from Windows 10 Home to Windows 10 Pro.

I am quoting this from another forum thread on Technet.

Based on the ClientDeploy.log above, it looks like it successfully looks up the local [Administrators] group (SID [S-1-5-32-544]) and successfully adds the “Me” account (SID ending in -1116) to that group. It looks like it blows up when it tries to get the name for SID [S-1-5-32-555], which is the well-known SID for local group “Remote Desktop Users”.

Coincidentally, I noticed that in looking at the Computer Management console, the Windows 8 Pro computer (“moved up” from Windows 8) doesn’t have that local group for some reason. A second Windows 8 Pro computer that I have, which was Windows 8 Pro out of the box, does have that group. Thus, at this point, I’m still suspecting a bug in the process that “moves up” Windows 8 to Windows 8 Pro. While it may or may not be related to this specific problem, why would the “Remote Desktop Users” local group (as well as several others that should be present in Pro) be missing?

Microsoft later addressed the Windows 8 Home to Pro upgrade issue with this update rollup. I know the article I referenced is dealing with Windows 8, but I believe this is also an issue with Windows 10. Somewhere in the upgrade process from Windows 10 Home to Windows 10 Pro the “Remote Desktop User” local group got missed.

I ended up joining the domain manually and just skipping the Connector software for now. If anyone has run into this issue as well, please let me know in the comments below. Better yet, if someone knows a fix or a workaround for this issue that would be awesome! I hope Microsoft addresses this bug in an upcoming update like they did with Windows 8.

I found this article that may fix the missing user groups after a Windows 10 Home to Windows 10 Pro upgrade. I didn’t have time to test this solution but it may be worth a shot.

Just curious if anyone in this forum ran into the same problem or has an answer. Thanks

 

[Denis Yakhnovets]

Connect Windows 10 computers to a domain without connector tool.
On the Windows 10 PC go to Settings > System > About then click Join a domain.

 

[seedubya]

Connect Windows 10 computers to a domain without connector tool.
On the Windows 10 PC go to Settings > System > About then click Join a domain.

I ended up joining the domain manually and just skipping the Connector software for now.

@Denis Yakhnovets He did that already.
@Merlin Halteman Sorry can't help however you've shed some light on this problem for me. I've experienced it once or twice but had never managed to even get close to a root cause. Thanks for the pointer.

 

[jzukerman]

Try manually downloading the connector from MS?
https://blogs.technet.microsoft.com...ws-server-essentials-for-supported-client-os/

 

[YeOldeStonecat]

The 2x things I've had issues with the Connector with....

*Computers already joined to the domain...but you'll get a more specific error stating that, as you install it. There was a quick registry edit you could do to allow the Connector to complete running...but Microsoft released updates to the Connector so that is no longer an issue (assuming you have a recent install of WSE and all Microsoft updates). This probably is not your issue since you've stated you've downloaded the Connector from MS. And since Microsoft released that update for the Connector...I've had no issues running the Connector on workstations already joined to the domain....dozens upon dozens of times.

*IPv6. I've had issues more like your issue..where you'll see it do random things like fail to find the server, or start to install but stall partially through. When the customer has used an ISP provided combo modem/router (like Comcast does)...and you haven't put your own router in between them and disabled the ISP router feature (allowing your own router to pull the public IP). I disable DHCP for IPv6 on the ISP gateway itself. Bounce the gateway. And then bounce workstations...no need to disable local IPv6 on the clients....just bounce them after disabling it on the ISP provided gateway (or your own router if you have it set to pass IPv6 addresses from the ISP...but that probably works since you usually customize internal DNS on routers, instead of the default ISP settings of passing their own DNS servers via DHCP for IPv6).

 

[TAPtech]

Are you up to date with OS patches on the Server? If memory serves correct, originally 2012R2E connector did not work with Windows 10. I believe it was updated with a patch... also there is a stand alone version as previously mentioned.