The last two days I had a lot of trouble with Microsoft Remote Desktop Services (RDP), or to use the older wording, terminal services. To be honest: Terminal servers are not really my specialty, and actually I was at the customer to help him with some vSphere related changes. But because I was there, I was asked to throw a closer look at some problems with their Microsoft W2K8R2 based terminal server farm. Some problems with removable media (USB sticks etc.) and audio on IGEL thin clients were hard to troubleshoot, but we were able to fix them. The biggest problem was none at first glance. The customer described, that remote users couldn’t login into a terminal server over VPN. But the login was successful, if the local administrator account of the terminal server was used. Some short tests confirmed the described behaviour. I checked the event logs and there it was: Event 4625.
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 23/5/2014 11:39:32 AM Event ID: 4625 Task Category: Logon Level: Information Keywords: Audit Failure User: N/A Computer: ts01.domain.tld Description: An account failed to log on. Subject: Security ID: NULL SID Account Name: – Account Domain: – Logon ID: 0×0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: DOMAIN\USERNAME Account Domain: DOMAIN Failure Information: Failure Reason: Domain sid inconsistent.Status: 0xc000006d Sub Status: 0xc000019b Process Information: Caller Process ID: 0×0 Caller Process Name: – Network Information: Workstation Name: COMPUTERNAME Source Network Address: – Source Port: – Failure Information: Failure Reason: Domain sid inconsistent. Status: 0xc000006d Sub Status: 0xc000019b
I checked the SID of the terminal servers with PsGetSid and they all had the same SID. I asked the customer how he had deployed the terminal servers and he explained, that he had deployed the first server from a VMware template with a customization specification. The following terminal server were cloned with VMware, but the customization specification wasn’t applied. Furthermore, sysprep wasn’t run. I can’t explain why this error was only logged when a user tried to connect over VPN, but it was reproducible.
It was clear that we had to change the SID. Unfortunately is NewSID not supported with Windows Server 2008 R2. So this wasn’t an option. The best way is to re-run sysprep. The customer and I developed an action plan to resolve the issue.
- Remove the server from the domain and add it into a workgroup
- Run Sysprep from C:\Windows\System32\Sysprep. Select “System Out-of-Box Experience (OOBE)”, “Generalize” and “Reboot”.
- After the reboot, rename the server with the old name. Activate Windows and do some tests.
This steps worked for us and resolved the issue. You need to test this in your environment before you apply the changes.
- Escaping special characters in proxy auth passwords in vCenter - October 8, 2021
- On the road to… nowhere? - July 26, 2021
- Configure VMware Horizon View client device certificate authentication - March 11, 2021