Event ID 4625 – Failure Reason: Domain sid inconsistent

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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.

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.

The Solution

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.

  1. Remove the server from the domain and add it into a workgroup
  2. Run Sysprep from C:\Windows\System32\Sysprep. Select “System Out-of-Box Experience (OOBE)”, “Generalize” and “Reboot”.
  3. 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.

Follow me

Patrick Terlisten

vcloudnine.de is the personal blog of Patrick Terlisten. Patrick has a strong focus on virtualization & cloud solutions, but also storage, networking, and IT infrastructure in general. He is a fan of Lean Management and agile methods, and practices continuous improvement whereever it is possible.

Feel free to follow him on Twitter and/ or leave a comment.
Patrick Terlisten
Follow me

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept!