The Windows SID – and an old problem

The Windows SID is created during the installation of Windows. This SID exists only on the computer. The computer object in the Active Director has its own SID. This local SID is used to uniquely identify each Windows. Among other things, it is used for the Microsoft Key Management Service (KMS). So 10 devices with one SID are only 1 device for the KMS. Before the smart budget hawks get excited, the activation does not always work in such a case and Microsoft does not rely on this in the case of a licence audit.
There are also other problems with duplicate SIDs. For example, the WSUS client takes over the SID as “SusClientId”. However, this is re-generated when the key is deleted.
Other Microsoft services also use the SID and more importantly, running multiple devices with the same SID is not supported by Microsoft. In the worst-case scenario, I get no support until I get this resolved.
If you want to know more about this problem, I recommend the article “The Machine SID Duplication Myth (and Why Sysprep Matters)” by Mark Russinovich.

The easiest way? Reinstall.
Technically, a sysprep /generalize can also help, but this is also a “new” machine. This must be added to the domain again, and…..
There is also always the question of whether everything still runs 100% after the sysprep. There is also a residual risk of side effects that are caused by this, but which cannot be traced back to it or can only be traced back to it with difficulty.
My recommendation from more than 20 years of Microsoft: Redo, but do it right. MDT could be used instead of cloning. With VMware, there is an extra checkbox for cloning that “generalises” the device and thus creates a new SID.

This is not possible via the Active Directory, even if there are some articles (here is an example) that like to think so. But maybe they mean a different SID, we don’t know.
Attributes that are often mentioned are:
SID: This is the SID of the computer object, i.e. the SID for the device in the domain.
ObjectGUID: This is the GUID of the computer object in AD.
objectSid: Usually corresponds to the SID
SIDHistory: Contains old SID if the object was migrated, for example to another domain.
Technically, except for the GUID, these are also SIDs, but not the Windows SID. Here you can see the domain SID, you can check this if you display it for several computers.

In the Windows Registry, the Windows Sid should be in the Hive HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account, but even as an administrator you have no access.
One possibility would be to change the authorisation via Sysinternals PSExec as a system account, but I strongly advise against this.

But another SysInternal tool can help, PSGetsid, which can read out the Windows SID. Simply start the programme, then the local Windows SID is read.
The advantage of PSGetsid is that it can read out the SID over the network. To do this, the computer name must be specified and the device must be accessible.

Now this is a bit more complicated to check individually, so it must be easier? Yes, I have integrated the whole thing into a PowerShell script. The basis was a project where we had problems with the process for cloning servers. The one-line variant is quite simple:
ForEach ($Computer in $(Get-ADComputer -Filter "Enabled -eq 'true'" -Properties name)) { Write-Host "$($Computer.name): $((& .\psgetsid64.exe \\$($Computer.name) -nobanner) | Select-String -Pattern "S-1-5-21-") "}