The Machine SID Duplication Myth (and Why Sysprep Matters)

On November 3 2009, Sysinternals retired NewSID, a utility that changes a computers machine Security Identifier (machine SID). I wrote NewSID in 1997 (its original name was NTSID) because the only tool available at the time for changing machine SIDs was the Microsoft Sysprep tool, and Sysprep doesn’t support changing the SIDs of computers that have applications installed. A machine SID is a unique identifier generated by Windows Setup that Windows uses as the basis for the SIDs for administrator-defined local accounts and groups. After a user logs on to a system, they are represented by their account and group SIDs with respect to object authorization (permissions checks). If two machines have the same machine SID, then accounts or groups on those systems might have the same SID. It’s therefore obvious that having multiple computers with the same machine SID on a network poses a security risk, right? At least that’s been the conventional wisdom.

The reason that I began considering NewSID for retirement is that, although people generally reported success with it on Windows Vista, I hadn’t fully tested it myself and I got occasional reports that some Windows component would fail after NewSID was used. When I set out to look into the reports I took a step back to understand how duplicate SIDs could cause problems, a belief that I had taken on faith like everyone else. The more I thought about it, the more I became convinced that machine SID duplication – having multiple computers with the same machine SID – doesn’t pose any problem, security or otherwise. I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue. At that point the decision to retire NewSID became obvious.

I realize that the news that it’s okay to have duplicate machine SIDs comes as a surprise to many, especially since changing SIDs on imaged systems has been a fundamental principle of image deployment since Windows NT’s inception. This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that – with one exception – Windows never exposes a machine SID outside its computer, proving that it’s okay to have systems with the same machine SID. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so MIcrosoft’s support policy will still require cloned systems to be made unique with Sysprep.



Windows uses SIDs to represent not just machines, but all security principals. Security principals include machines, domain computer accounts, users and security groups. Names are simply user-friendly representations for SIDs, allowing you to rename an account and not have to update access control lists (ACLs) that reference the account to reflect the change. A SID is a variable-length numeric value that consists of a structure revision number, a 48-bit identifier authority value, and a variable number of 32-bit subauthority or relative identifier (RID) values. The authority value identifies the agent that issued the SID, and this agent is typically a Windows local system or a domain. Subauthority values identify trustees relative to the issuing authority, and RIDs are simply a way for Windows to create unique SIDs based on a common base SID.

You can use the Sysinternals PsGetSid tool to view a machine’s SID by running it with no command-line arguments:


Here, the revision number is 1, the authority is 5, and there are four subauthority values. At one point during the design of Windows NT, the machine SID might have been used for network identification, so in order to assure uniqueness, the SID that Setup generates has one fixed subauthority value (21) and three randomly-generated subauthority values (the numbers following “S-1-5-21” in the output). 

Even before you create the first user account on a system, Windows defines several built-in users and groups, including the Administrator and Guest accounts. Instead of generating new random SIDs for these accounts, Windows ensures their uniqueness by simply appending a per-account unique number, called a Relative Identifier (RID), to the machine SID. The RIDs for these initial accounts are predefined, so the Administrator user always has a RID of 500:


After installation, Windows assigns new local user and group accounts with RIDs starting at 1000. You can use PsGetSid to view the name of the account for a specified SID, and here you can see that the local SID that has a RID of 1000 is for the Abby account, the name of the administrator account Windows prompted me to name during setup:


In addition to these dynamically created SIDs, Windows defines a number of accounts that always have predefined SIDs, not just RIDs. One example is the Everyone group, which has the SID S-1-1-0 on every Windows system:


Another example, is the Local System account (System), which is the account in which several system processes like Session Manager (Smss.exe), the Service Control Manager (Services.exe) and Winlogon (Winlogon.exe) run:


SIDs and Access Control Lists

When an account logs on to a Windows system, the Local Security Authority Subsystem (LSASS -Lsass.exe) creates a logon session and a token for the session. A token is a data structure the Windows kernel defines to represent the account and it contains the account’s SID, the SIDs of the groups that the account belongs to at the time it authenticated, and the security privileges assigned to the account and the groups. When the last token that references a logon session is deleted, LSASS deletes the logon session and the user is considered logged off. Here you can see my interactive logon session, displayed with the Sysinternals LogonSessions utility:


And here you can see a token Lsass has created for the session in Process Explorer’s handle view. Note that number following the account name, 7fdee, matches the logon session ID shown by LogonSessions:


By default, processes inherit a copy of their parent process’s token. Every process running in my interactive session, for example, has a copy of the token that they inherited originally from the Userinit.exe process, the process Winlogon creates as the first of any interactive logon. You can view the contents of a process’s token by double-clicking on the process in Process Explorer and switching to the Security page of the process properties dialog:


When one of my processes opens an operating system object, like a file or registry key, the security subsystem executes a permission check that evaluates entries in the object’s access control list (ACL) that reference a SID included in the process’s token.

A similar check happens for remote logon sessions, which are the kind created by a “net use” of a remote computer’s share. To successfully connect to a share you must authenticate to the remote system with an account known to that system. If the computer is part of a Workgroup, then the credentials you specify must be for a local account on the remote system; for a Domain-joined system, the credentials can be for a remote system’s local account or a Domain account. When you access a file on the share, the file server driver on that system uses the token from the logon session for the permission check, leveraging a mechanism called impersonation.

SID Duplication

The Microsoft-supported way to create a Windows installation that’s ready for deployment to a group of computers is to install Windows on a reference computer and prepare the system for cloning by running the Sysprep tool. This is called generalizing the image, because when you boot an image created using this process, Sysprep specializes the installation by generating a new machine SID, triggering plug-and-play hardware detection, resetting the product activation clock, and setting other configuration data like the new computer name.

However, some IT administrators install Windows on one of their systems, install and configure applications, then use deployment tools that don’t reset the SIDs of the copies of the Windows installations. The best practice up to now has been to run a SID-resetting utility like NewSID to change SIDs. These utilities generate a new machine SID, try to find all the locations on a system, including all the file system and registry ACLs, that contain copies of the machine SID, and update them to the new SID. The reason that Microsoft doesn’t support systems modified in this way is that, unlike Sysprep, these tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. The reliability and security of a system that has a mix of the old and new machine SID can’t be guaranteed.

So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.

In other words, it’s not the SID that ultimately gates access to a computer, but an account’s user name and password: simply knowing the SID of an account on a remote system doesn’t allow you access to the computer or any resources on it.  As further evidence that a SID isn’t sufficient, remember that built-in accounts like the Local System account have the same SID on every computer, something that would be a major security hole if it was.

As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.

Some articles on SID duplication, including this KB article, warn that if multiple computers have the same SID, that resources on removable media like an NTFS-formatted firewire disk can’t be secured to a local account. What they fail to mention is that permissions on removable media provide no security regardless, because a user can connect them to computers running operating systems that don’t honor NTFS permissions. Moreover, removable media tend to have default permissions that grant access to well-known SIDs, such as to the Administrators group, which are the same on all systems. That’s the fundamental rule of physical security and why Windows 7 introduced Bitlocker-to-Go, which enables you to encrypt removable storage.

The final case where SID duplication would be an issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID. Software that relies on unique computer identities either uses computer names or computer Domain SIDs (the SID of the computer accounts in the Domain).

The New Best Practice

It’s a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else knew exactly why it was a problem. To my chagrin, NewSID has never really done anything useful and there’s no reason to miss it now that it’s retired. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep

Comments (258)

  1. @David Peel:

    You make this statement:

    "he/she can use pass-through authentication [if passwords match]"

    Which to be true requires the user name and the password to match, and skip over that to talk about access control lists being a security problem.

    How in the world do you not consider the security hole to be in your premise that someone knows the password for an account they shouldn’t have access to?

  2. An attempt to explain the distinction between the machine SID and the computer account SID in a domain:

  3. Drac346 says:

    Sorry for the second post, but I don’t like posting information without proper references.  It seems that some of my information was incorrect and I have supporting data today…

    MSDTC uses a CID (not a UUID) which is stored in the registry located at HKEY_CLASSES_ROOTCID as well as registry data located: HKLM/Software/Microsoft/Software/MSDTC and HKLM/System/CurrentControlSet/Services/MSDTC.

    If you Google "msdtc CID" you will come across several people who have had issues with SysPrep not replacing the CID value of services during the process (including myself).  I do not know if this is normal functionality but it would explain the issue with communications issues.  The solution is very similar to what I posted in my previous post.  Uninstall MSDTC, delete the registry key’s (please make backups first), reinstall MSDTC and verify your configuration settings.


    User Community procedures for updating the MSDTC CID:

    Microsoft Support Procedures for reinstalling MSDTC on Server 2000 (very similar in 2003):

    Microsoft MSDTC Troubleshooting tools (which would have correctly identified your problem as a CID issue):

    I also need to correct my statement about not needing a Unique Machine SID for MSDTC to work correctly.  While I have machines with the same machine SID and unique MSDTC CID’s talking together, I found a BizTalk 2006 Server reference from the Microsoft MSDN site which states the following:

    "Computers running the Windows operating system use security identifiers, or SIDs, to identify themselves. MSDTC functionality requires that the host operating system is assigned a unique SID. Disk duplicate images of Windows installations must be configured with the System Preparation tool (Sysprep) or the SID of the deployed operating system may not be unique and MSDTC functionality may be impaired. This can occur when using virtual hard disks to deploy an operating system to a virtual machine." Ref- Ensure that the operating system is assigned a unique security identifier (SID) ,

    @Mark: Is it possible to get clarification on the SID requirement based on the MSDN article?  Does MSDTC use the domain SID (when in a domain) or the machine SID?  Is the statement still accurate with the current operating systems (my reference is a BizTalk Server 2006 article)?  Should SysPrep change the CID values in the registry?

  4. @Darragh O’Shaughnessy

    Yes, the article is incorrect: Kevin would not be able to access John’s share and the files on it unless he authenticated with John’s user name and password, which he presumably doesn’t know.

  5. @Kiran

    You obviously didn’t read the post, at least not the entire thing. As I stated, the first DC in a domain must have a SID unique from the member systems.

  6. @alex

    I’m not sure what you’re looking for: WSUS has it’s own per-machine ID that’s independent of the SID and that is reset by Sysprep. The same goes for the other state that many have confused with the SID, including NLB GUIDs and SMS IDs.

    Again, please do not comment unless you’ve read the entire post AND all the existing comments. I will not publish your comment if it has nothing new to add to the discussion.

  7. @Megan: what software have you seen that depends on unique machine SIDs and how does it deal with Domain Controllers, which have the same machine SID for a given domain?

  8. @Nick:

    "If I understand Mark’s notes correctly, if you clone a machine a new (read:unique) Machine SID is not required (by Windows).  I think what may not be clear (and I am just guessing here) is that if the original machine is already joined to a domain, and then cloned, both orginal and clone will have the same Domain SID – this would no doubt cause issues and require a new Domain SID to be generated."

    That’s absolutely correct.

  9. Anonymous says:

    I believe Windows does consider the machine SID when joining a computer to a domain.  If you try to join a computer to a domain, and an account already exists with the same name, you should get an error message, unless it’s the same computer in which case the account should be reset and the computer should be able to "re-join" the domain.

    I experienced a problem with a customer who had tons of computers running XP that had been cloned BEFORE joining the domain, without using Sysprep or NewSID.  Whenever by some mistake a computer A was given a name that had already been given to another computer B that was already a member of the domain, joining A to the domain would succeed instead of giving an error message, but B would inmediatly start having logon problems because it’s domain account had been reset.


  10. Anonymous says:

    @Dean: If it were me (and it is as I am part of a large company that does this for many companies) I would use MDT and completely automate my deployment process.  Doing this removes any possibility of duplicate anything except processes and you never have to even think of this battle.

    When we clone virtual machines in the lab, we don’t run any kind of NewSID process.  Again, we let the VMware tool handle that for us, so a sysprepmini Setup process occurs.  Since it handles the process via a MS supported mechanism (Sysprep) there is no issue.

    All that being the case, I personally believe that as long as you leave the domain out of the equation until AFTER cloning, there should be no issue with a duplicate SIDs given the information in Mark’s article and my own experience with OS’s post Windows 2000.

  11. Note that in order to prevent further noise in the comments, I will no longer be publishing those that clearly show the author did not read the article or the existing comments.

  12. @Aaron: You’re granting access to the computer’s Domain SID, not it’s machine SID. Like user’s computer accounts in a Domain have passwords, but the passwords are managed by the Domain.

  13. Anonymous says:

    Is there a way to specify a sid in Vista at install-time? I would want to migrate from x86 to x64, but with retaining user profile and all.

  14. @Chuck: because AD uses the machine SID of the first Domain Controller as the SID for the Domain, and all systems subsequently promoted to DCs on that Domain adopt the same machine SID, member systems cannot also have that machine SID.

    For the DC you want to create from a clone, create a unique installation or run Sysprep.

  15. Martyn James says:

    The answer to any machine identification for an application seems to often be "the application puts its own identifier onto the system".

    Computers get dropped, hard drives crash, or otherwise corrupted, applications get removed, something else (by design or accident) removes the local system identifier. At that point, the SID would be the only hope to identify whether this is the same machine – there is not much else (perhaps one can use the MAC address of the ethernet card(s)). If one is trying to recover data (or specifically recover your application whose custom identifier has been removed) to a machine that does not have the custom identifier; having a system identifier is pretty useful.

    Even if we ignore the above argument, does it not seem wasteful to have every software vendor create their own identifier on every machine – wouldn't you want an operating system to provide such an identifier (especially if the OS used to, and decided to no longer support it).

  16. @Martin Zugec: I’ve updated the text to make the distinction between machine SIDs and computer Domain SIDs more clear.

  17. @lyle: Again, this is a case of other unique per-machine state, not the machine SID, causing a problem – state that Sysprep resets:

  18. @Itsme

    Sorry, but you're incorrect.

  19. @Timothy: yes, with the exception that machine SIDs are used as the basis for Domain SIDs, machine SIDs could have been a constant.

  20. @Martyn James

    Like all the applications we’ve been talking about, including WSUS, SMS, etc, you can create your own system identifier and place that on user’s systems.

  21. @prb, @FillDee – Thanks for taking the time to read the article and the comments and thanks for the feedback.

  22. @Chris: the article talks about network adapter GUIDs, not machine SIDs.

    @Timothy: you’re correct, I’m not suggesting not sysprepping, because there is other machine-specific state that it resets, just that the SID changing step would be optional – the only reason you might want it is to reset the machine SID on a system you plan on using to as the first DC in a new Domain.

  23. @jared barneck

    Sysprep has always included a provider model for third-party applications:

  24. @Ed: You of course are free to continue to believe that SID duplication is an issue, but I wouldn’t want my systems managed by an IT staff that makes decisions based on superstition. And it’s surprising to me that you’re so concerned over SID duplication while at the same time ignoring all the other duplicated state that is addressed by Sysprep.

  25. It appears many readers are confusing machine-specific state, computer Domain SIDs, and machine SIDs. This article is only about machine SIDs. Having multiple computers with the same computer Domain SID will definitely cause problems. Further, some applications create per-machine state that they expect to be unique across systems and cloning a computer with that state will cause problems for those applications. As many have pointed out, Windows Server Update Services is one example.

    For those reasons, Microsoft’s official support policy will still require Sysprep to have been run on a cloned system.

  26. bahbar says:

    I may have missed something, but aren’t you essentially saying that machine SIDs are useless ?

    I mean, if all machines out there can have the same SID to no ill effect, why not just remove it altogether ?

  27. Steve Johnson says:

    When I grant a machine account access to network resources, what mechanism is used to identify the machine?  eg. if I grant MyMachine1 administrative access to MyMachine2.

  28. adam says:

    So, what does AD use to uniquely identify machines when you join them to a domain? Is it literally just the hostname and post-join the machine account password?

  29. Steven Brown says:

    WOW!  I would have NEVER believed this if I hadn’t heard it from Mark!  Once again awesome job Mark on finding what others could not!

  30. Anders says:

    I tentatively agree with bahbar here.. if it’s not useless then I don’t see how newsid or the sid-replacement part of sysprep can be useless.

    It does (or should) uniquely identify an operating system installation. For most of us the motherboard UUID works fine but there are cases where it won’t. And if you can use it to uniquely identify an installation, betcha people are. I wouldn’t take any action until you’ve spoken to lots of ISV’s.

  31. Timothy says:

    I’m with bahbar!  Why have them at all if they serve no purpose?  Just support for legacy systems, I guess?

    Man I could have sworn I did imaging in the past where I renamed all the computers and so on, ghosted them, joined each seperately to the domain, and then when they went online, everyhing went to hell (as in, each computer thought it was the same computer) until I used NewSID…  Maybe it was an entirely different issue and NewSID was just snake oil after the real problem was something else I did along the way.

    Yes, Mark.  I am shocked that SID duplication is not an actual issue!  I never thought it was much of a security issue (due to the well known SID suffices, like -500), but I could have sworn there was some sort of domain/networking confusion!  Thanks for clearing it up!

  32. Cameron Brice says:

    Better check with the KMS guys. We’ve had a problem with non-syspreped imaged computers and KMS.

  33. cornasdf says:

    I haven’t done it in a while, but I seem to remember having issues in AD when i rolled out images and didn’t update the SID.  I always assumed that the machine SID was used in the conversation w/ AD.

  34. miro says:

    @Steve: I assume that both MyMachine 1 and MyMachine 2 are in domain. As far as i understand, computer accounts in domain have also passwords like user accounts (sometimes you need to reset it via "reset computer account" in dsa.msc). If MyMachine2 would be in a workgroup, you would not find account for MyMachine1 on MyMachine2.

  35. Longmorn18 says:

    I do have 1 reason why they should be unique. Migrating from one AD domain to another using a tool like Quest Migration manager, might fail when working with machines with duplicate SID’s.

    It’s not the case all the time, just have seen it happening that a wrong machine was migrated although the correct computer name was given. Seemed that it had picked a machine with the same SID to migrate, and not the one with the computer name given.

    Migrating from one AD domain to another does not happen very often, but it can in very large companies ( or small ones that get acquired by a larger one )

  36. Aaron Silber says:

    What about when you grant logon access to users specific machines? Isn’t the local machine SID whaat is being used to verify that you can log in?

    Otherwise if someone were able to change the machine name (I know this would mean that there are other security issues to be concerned with) they would (in theory) be able to access everything on that machine so what good would that setting be?


  37. Jakub Anderwald says:

    Great Mark! "Obvious" things are abvious because nobody ever asked "why?" strong enough. Now you did!

  38. Roy says:

    I have to share this: on one project I was asked to setup a lab environment. All servers were 2008.  All of the images were created by the client and they did not run new-sid or sysprep on them. Even after joining the servers to the domain, I had random issues. Any account added to the administrators group including domain admins could be added, but they were not recognized. Meaning, i did not have permissions with any of those accounts. I double checked the local administrators group and the accounts (including domain admins) did not show. I could try to add them, but of course it would show it was already there.

    I ran newsid on those servers then everything worked as normal..



  39. Gabriel Maciel says:

    Hi Mark,

    I thought that applications like WSUS and Symantec AV rely on the machine SID to properly identify the clients. If that is the case, wouldn’t it be needed?

    Thank you,


  40. Anthony Zoko says:

    From a security perspective may not be an issue, but from a management perpective it causes many headaches.

    Tools such as Altiris and even System Center use the SID to uniquely identify a computer.  

    If you follow the steps Mark lists for Syspreping a machine, your fine. However, there is always a junior admin out there that screws up occasionally and newSID was a great tool to save the day when you couldn’t simply reimage machines.

  41. Phileosophos says:

    I had never heard of the SID problem until I started using Virtual PC to deploy multiple images in a testing lab back in 2005. But I know this: if we didn’t use sysprep, we had networking issues between the machines. I don’t know why, and I don’t have any way to refute or rebut anything you’re saying, but I know unique SIDs used to be required to avoid nasty issues. Maybe that’s not the case anymore, but it certainly was.

  42. vijay says:

    Xcellent post Mark !! Really impressed with your article.



  43. Chuck says:

    I can’t remember the exact behavior, but I’ve definitely seen issues before in a test environment when promoting a cloned image to a DC and then trying to add another machine cloned from the same image to that domain as a member server.

  44. Martin Zugec says:

    Hi Mark,

    maybe you should update that article a little bit and explain how domain computer SID related to machine SID – I think this will be definitely FAQ for this topic.


  45. Mike V says:

    Wouldn’t duplicate SID’s affect the machines secure channel password? And the possibility of resetting it remotely when needed? I’ve always assumed the host name is given, but the SID is what is actually used to do a reset with the netdom utility. Am I wrong in thinking that?

    Also in dynamic DNS a dynamically created record by the host shows it’s HostName$ on the security tab of that record verses a manually created record my me, would list my account in the ACL list instead of the HostName$. Isn’t that entry a representation of the owners account SID? I would think duplicate SID’s would cause a problem here.

    I’ve always been under the impression that a host name doesn’t really matter and that the SID is what is actually used to verify one computer over another in the case of a rouge computer showing up on your network wanting to impersonate another.


  46. Mathieu Chateau says:

    @Cameron Brice: KMS use the CMID, not the SID. Issue raise when you do not use the /generalize of the sysprep, because the CMID is not changed. This KB explains it:

  47. Sarah Mocke says:

    This is interesting and I wonder if WINS is affected at all by SIDs?  We have been trying to escape the WINS legacy for ages to no avail…

    Second question- We get errors on our DCs for machines that were reimaged but not sysprepped- the computer account cannot be found in AD, nevertheless I daily recieve events 5723 referencing this former member of the DC- and I was told it was because AD had the SID for that machine saved off somehwere…

  48. Alain Cote says:

    Then why is there a clean up method with ntdsutil for duplicate SID?

  49. Ramon Smits says:

    If this is true.. then boy what have I been doing al those years?

    Although it has been a while I remember a scenario where I had cloned a domain machine (non DC) and only changed the hostname. Somehow certain domain group policies for machine A where assigned to machine B while.

    I remember that removing machine B from the domain would also invalidate machine A or vice versa.

    So you are saying that when I have an XP machine (A), clone it (B) and add A to the domain followed by adding B to the domain that I definitely have no domain group policy issues??

  50. Robert says:

    I think the problem concerning NTFS-formatted removable media still applies on a cosmetic level: If user A’s files appear as user B’s files on another machine, this can lead to confusion and, in the worst case, unintended modifications of files. "Access denied" messages and SIDs with question marks might give the user a hint on what is going on.

  51. alan says:

    Mark, I do trust your insights and knowledge, but in this matter my personal experience outweighs your conclusions.

    There will be issues on AD if you have two computers with the same SID. The computer object uses that SID and will be corrupted for one machine or the other if you do not assign unique SIDs, resulting in the need to remove both machines from the domain, re-setting their SIDs and deletion and re-creation of the computer object.

    Again, from personal experience I know this to be true.

  52. syseyes says:

    I have a doubt, supose you have multiple domain controlers in a domain, all of them with duplicade sids. One of them is the master of all the roles of the domain. Supose the master break down and you decide to transfer all roles into another (seize instruction). There will be some problem?.

    I have been twice in the situation to transfer the roles of the domain to another server in catastrofic circunstancies, and remember it as one the most excruciating situations in my career. I would like to be sure that whith duplicate sids all will be working smoothly.

  53. terry says:

    I guess it was only a matter of time.  

    *Any* method of changing the SID, other than the Microsoft way, was NEVER supported.  

    Now that Microsoft owns SysInternals, NewSID is not supported.  Imagine that 🙂

    Until Microsoft completely replaces the use of SIDs with GUIDs and stops generating computer SIDs, I will still consider it best practice to keep the SID unique.  

    The Industry expects SIDs to be unique and you never know how 3rd party vendors are going to use it.

  54. wr says:

    Yes. What about WSUS? In the past we had problems like new cloned machines not showing up in the list until you change the SID. And i dont really get the point of using WDS/Sysprep, all this bulky crappy stuff and spend hours capturing/applying images/syspreping etc., if i can spend only 40 mins and have a perfectly identical clone. I would be happy not to use NewSID and cut another 10-15 mins, but i need confirmation about WSUS and i also dont like all these comments about weird stuff happening with identical SIDs. Too many of them.

  55. Megan says:

    @Anthony – thank you for your response. I just responded to an email on a list about this. We have huge nightmares deploying other software vendor clients that have their own unique GUID to machines with duplicate SIDs. Any mention on this? I don’t think it’s a good idea to discourage other IT peeps from ensuring their systems have unique SIDs if indeed it will cause issues.

  56. J says:

    I’ve seen DRM software that uses the SID to lock software to a particular installation.

    Duplicate SID’s make bypassing such DRM as simple as copying over the keyfile.

  57. Kamrate says:

    "I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue. At that point the decision to retire NewSID became obvious."

    Just because you are not able to envision a problem does not mean that there is not one. If your basis for the decision was what you stated above, rather than thorough testing, I feel that you have not done your due diligence.

  58. Dean says:

    Hi Mark.

    We have had a problem in a Domain when we have imaged a machine for use in a test Virtual Enviroment.

    i.e. We would take a copy of a computer and image it to a VM. Then we would rename that machine so they could both be available at the same time. (1 for production, 1 for testing)

    The problem has always been that when we update the name on the testing VM, it updates AD with the new name.

    How would we get around this without newSSID?

  59. nick says:

    I agree with other commentors in that issues have occurred in the past with other software when not generating new SID’s for cloned machines when these machines have been joined to a network.

    If I understand Mark’s notes correctly, if you clone a machine a new (read:unique) Machine SID is not required (by Windows).  I think what may not be clear (and I am just guessing here) is that if the original machine is already joined to a domain, and then cloned, both orginal and clone will have the same Domain SID – this would no doubt cause issues and require a new Domain SID to be generated.  

    Software that I have personally experienced issues with in the past due to duplicate SID’s is MSMQ and DCOM (I was going to say SQL Server 7, but underlying problem was DCOM).  No doubt this has been due to have duplicate Domain SID’s.

  60. FrostyPants says:

    Two computerrs in the same domain having the same computer sid would cause a *huge* problem for any application which uses SIDs from multiple computers.  A client application which knows of only one system is all well and good, but when you’re dealing with something that has to determine, from a central location, what type of object a SID represents, this can make computers virtually indistinguishable.  All local accounts on a windows box have a SID made up of the systems SID + a locally unique RID (just like a domain SID.)  If you have two computers with the same sid, then if you have maintained these SIDs in a central location, you would have accounts that can no longer be distinguished from one another; their sids would match, even though their hosting systems did not.

  61. Erik Pitti says:


    That’s because the original computer wasn’t removed from the domain before it was cloned.  They both referenced the same domain computer account.  For instance if you had removed computerA from the domain and then cloned it to  computerB, renamed it to computerB and joined them both back to the domain, they’d have unique computer accounts (and unique domain account SIDs, but identical machine SIDs).

    Just for reference I’ve been personally superstitious about having unique machine SIDs. I’m quite interested in where this discussion is headed.

  62. Chris says:

    There still is a problem with duplicate SIDs.

    I’m trying to create a NLB of two cloned server and Windows will not let you create it because the servers have the same SID.

  63. BigHaig says:

    People, there is a difference between MACHINE SID (which Mark is talking about) and DOMAIN SID.  You cannot have the same domain SID if you are part of a domain.

  64. Timothy says:

    Re: WSUS for those who have asked.

    I think WSUS uses it’s own ID. (Mark might know better the guts of how this works.)  In test labs if I didn’t sysprep, the same computer object in WSUS was always updated instead of creating new one.  To resolve this, I stopped the update service on the client machine, deleted the SoftwareDistribution folder, started the service, then ran "wuauclt.exe /resetauthorization /detectnow" at the command line.  This would generate a new ID (or whatever) apparently because it would show up as a new server in WSUS.

    If you think about it, WSUS can’t use the machine SID since it would be the same on all DCs (as Mark stated above).

    Just one more thought.  I think there may be some confusion about what Mark is saying. Mark isn’t saying "don’t sysprep" when you clone.  He’s just saying the SID step is unnecessary, so the NewSID app doesn’t do anything useful (rare oddball 3rd party apps that use machine SIDs excluded).  Machine images used for deployment should always be SysPrepped!  SysPrep does a lot more than just changing the machine SID.

  65. Jeremy Redmond says:


    I didn’t see you respond to the WSUS issue. If machines have the same SID sometimes they will not show up in the WSUS console.  Thoughts?  Thanks.

  66. Lyle says:

    WSUS is definitely confused when machines have duplicate Sids. We had a large number of pc’s that were imaged without sysprep being run on the reference machine. PC1 would register with WSUS, when PC2 came up it would register it’s name replacing PC1… PC3 would take the place of PC2 etc…

    Running Newsid against all of the machines involved enabled them to all uniquely register and recieve updates. It sure came in handy that time.

  67. stephen says:

    Excellent post, Mark.  Your research has answered some questions I didn’t even realize I had.

  68. Devil's Advocate says:

    Here’s an (admittedly esoteric and hypothetical) scenario I’d like you to consider:

    Say I create cluster with a shared storage device.  I create accounts on each cluster’s local SAM with access to the shared storage.

    I make a couple of admin-level accounts:



    ….with full access to the shared storage.

    Then I go and make a few service accounts with limited access to a few directories:



    To set the file-permissions, I briefly activate each node and run CACLs, or whatever.

    Now assume the two nodes have identical machine SIDs.  Further assume that the SID for NODE1diskadmin matches NODE2limitedaccount.

    One day, while NODE1 is active, something maps a share as CLUSTERlimiteduser.  Does it get all of NODE1adminaccess’s file permissions?  If so, would MS consider this a vulnerability?

  69. Rob B. says:

    Crap.  MS so well sold my employer on the duplicate SID "problem," that it became company policy — punishable if violated — that machines will not be imaged.  All the concern was supposedly based on duplicate machine SIDs causing SMS or SCCM issues.  

    MS, please get this word out.  Maybe some of us can get part of our lives back and begin imaging systems again.

  70. Adam K-F says:


    A very interesting and also very inflammatory piece of research.  Whilst I agree with your premise, I think you should pause and reflect on the comments being made here.  There are a lot of very intelligent and experienced people who have had different experiences based around the requirement of a unique machine SID and issues caused when unique SIDs are not used.  I think Microsoft should be very careful about changing such a deeply ingrained best practice that has essentially become an industry wide best practice over the years.

    Judging by what others are saying, while Windows does not seem to require a unique SID, other software depends on this uniqueness, and what is Windows without other vendor software.

    I personally have not come across issues with Windows failing without needing a unique SID, but many of the Engineers I work with have and whilst your article may (and should!) potentially reign in a new era of thinking about machine SIDs, for now I would be cautious about making arbitrary changes to such deeply entrenched best practices.

    Cheers, and thanks for the interesting read!


  71. Scott says:

    I also have to question this.

    I’ve commonly seen an issue with a scenario where hundreds of vmware images are created from a template, this means the SID replicates with the images.

    We commonly receive errors that the the computer can’t communicate with the DC, the only way to fix this is to drop the computer from the domain and rejoin the image to the domain. I can’t see what else would cause this aside from a SID duplication issue.

  72. Denobin says:

    Is any regression testing going to be done and reported? Thanks for the informative article!

  73. Mike Cramer says:


    This is a very interesting read, thank you for the note. However, my question to you is this:

    If it doesn’t hurt anything to have the SID regenerated via sysprep; and from what others are saying it might pose problems with other software; is it best to recommend not doing so?

    I’m working on a huge deployment and this particular piece of information will be vital in my cause to push for using sysprep. The biggest case I’ve been making so far has been sid generation since others in my company feel application install and everything else can be handled manually by hand (nevermind the benefits of sysprepping, nobody in the organization has ever sysprepped because A) it takes too much time, B) it requires actually knowing how Windows, drivers, and applications work and where they stand in the installation process, and C) the utilities and tools that MS provides for deployment are extremely draconian, and the documentation spotty at best).

    I’m currently wading through the metric ton of information on deployment with Windows 7, MDT 2010, and AIK 2.0.

  74. james says:

    I have found if I don’t sysprep or newsid to generate new SIDS for computers when imaging them, once I join these computers to the domain, after logging into the second one the first is no longer able to be logged in, then I join the first back to domain again, the second has issues logging in, not until I had ran newsid where they both usable.

    I think I’ll continue using sysprep and newsid.

  75. Burt says:

    I do not agree that is it not an issue. Years ago when I worked at Compaq, I had to work the cases that came in regarding security issues on Commercial Desktops that had been cloned without having the SIDs regenerated..

    Granted I have not tested again in many years, but here is the test I used to give customers to show the security vulnerability. (The results of which may have changed over the years.)

    1. Build a machine from standard OS media.

    2. Set the password for the Administrator account to something simple like “123”. (On newer Operating Systems you will have to enable the account.)

    3. You will need to make sure that you have network share access set to “classic authentication” and not “guest only” for network test later on.

    4. Clone (image) the system without using any SID regeneration tools such as Sysprep. Load the image onto another machine to create an effective duplicate. (You should change the machine name so there will not be a name duplicate error in the workgroup.)

    5. Set up both machines on a network common to both machines.

    6. You should now be able to log onto each machine with the Administrator account using the password “123”. You can also test network access by browsing to the other machine’s administrative shares such as \machinec$.

    7. Now change the password for Administrator on one of the machines so something like “abc”.

    8. Test to see if you can now access the other machines administrative shares without providing a password. This can be done even after a reboot of both machines.

    Back in the day – time after time – the test would show that even after the password on one of the accounts (or both) had been reset, you would still be able to get to the other machines administrative shares without typing in the remote Administrator account password.

    Again it has been a while since I have run this test and things do change with subsequent operating systems but I don’t know of any significant changes to the SID mechanism since the old NT and 2000 days.

    The effect of the above – if it still is an issue – is that if these clones are released to production and if a user has the ability to log into one machine as an Administrator then the user has access to all other clones via administrative shares unless other mitigating factors are in place.


  76. Rich says:


    With 100% certainty, I know of 3 different software that would not work properly if SID’s were not unique across machines on the same LAN:

    1. a licensing server that uses SID to uniquely identify windows desktops at a large manufacturing company. It will invalidate certain software if it detects two machines reporting the same hash of a SID.

    2. an enterprise security software that will deny access to machines having the same SID with another machine.

    3. a help desk related software that requires supported desktops to have unique SID.

    There are probably many dozens, if not many hundreds of third party software that will malfunction if Microsoft suddenly promoted having duplicate SIDs.

    If Microsoft has patents regarding uniquely identifying machines, whereby it allows minor hardware changes, then other software companies are going to get hurt by not being able to rely on SID anymore.  Was this the plan?

  77. Rex says:

    If you take a machine and clone it then promote both to be domain controllers in different domains, you cannot create a trust relationship between the two domains. If you run newsid after the clone process, but prior to promotion, all works well. While this may be just another case of machine SID vs. domain SID, when you promote the first domain controller in a domain, the domain SID gets based of the machine SID,  so it does matter. Please consider keeping the tool around for this (and other scenarios as posted in this thread.)

    Yes, you could use sysprep to accomplish the same thing, but sysprep does not create a "clone", it creates a potentially different version of your original installation. The sysprep process makes changes other then just the machine name and SID (or is at least perceived to). Culture and the history of change management for many people hold a strong preference to use a true clone or image of a known configuration. Sysprep doesn’t "feel" like an image copy, it feels like a (potentially different) independent install.

  78. Jamis Eichenauer says:

    Sophos Enterprise Console and Small Business Control Centre products identify computers by their SIDs as well. (In fact, even the local factory.xml file in C:Documents and SettingsAll UsersApplication DataSophosSophos Anti-Virusconfig contains the local SID) [C:ProgramDataSophosSophos Anti-Virusconfig in Vista and post Vista systems)

  79. Travis Green says:

    I commend your ability to turn your scrutiny upon your own assumptions and then broadcast the results.

  80. Andrew Doull says:

    @Scott: That’s a domain SID issue, not a machine SID issue. Different problem.

  81. /kj says:

    WSUS generates and uses SUSClientID to uniqly identifiy WSUS clients. Machine SIDS are not.

  82. Rex says:

    If you take a machine and clone it then promote both to be domain controllers in different domains, you cannot create a trust relationship between the two domains. If you run newsid after the clone process, but prior to promotion, all works well. While this may be just another case of machine SID vs. domain SID, when you promote the first domain controller in a domain, the domain SID gets based of the machine SID,  so it does matter. Please consider keeping the tool around for this (and other scenarios as posted in this thread.)

    Yes, you could use sysprep to accomplish the same thing, but sysprep does not create a "clone", it creates a potentially different version of your original installation. The sysprep process makes changes other then just the machine name and SID (or is at least perceived to). Culture and the history of change management for many people hold a strong preference to use a true clone or image of a known configuration. Sysprep doesn’t "feel" like an image copy, it feels like a (potentially different) independent install.

  83. Anonymous says:

    "I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue."

    That’s not the same as there not being any issues.

    Furthermore, SID regeneration has been the norm for a long time and it wouldn’t surprise me if the people on those teams who *knew* about the issues are no longer there.

  84. shannon says:

    Scott: Disjoining and rejoining the domain doesn’t change the machine’s SID.  It only changes the the SID of the machine’s account on the domain (the domain-SID of the machine.)

    Changing the machine SID changes the SID of all local accounts (as the full SID of all local accounts contains the machine’s SID.)

    If you read the description at of what NewSID did, Mark says that it had to walk though every single file and change the SID from the old to the new – which means it takes a *while*.  Disjoining-and-rejoining a domain does not take anywhere near long enough to change all the ACLs on every file on the disk – but ACLs with local users still work fine.  

    I’m guessing that Sysprep doesn’t even address this issue – if you use a local account on an ACL and sysprep, old ACL entires no longer resolve to computer accounts.  Non issue usually as on a fresh machine, you’re usually using well-known SIDs for permissions, like "NT AUTHORITYSYSTEM".  

    My take overall is that I’d be nevous reusing SIDs on servers, mainly because if media gets recycled between them it can be confusing to the admin.  (Who would remember to do a take-ownership and clear all the SIDs off a hard drive they just moved from server A to server B?  And what if they really wanted to keep domain and well-known SID based ACL entries too?)  Workstations, not such a problem because media is less likely to be recycled.

    Maybe there’s a need for a tool to hunt down ACL entires to local accounts for those situations when people move media and machines have duplicate SIDs?

  85. Yozwar says:

    Once again people:

    Domain-related problems with cloning are because the machines were cloned WHILE THEY WERE JOINED TO A DOMAIN which causes a duplicate link to their DomainSID.

    Remove them from the domain before imaging them and everything works fine.

    @mark: this should probably put somewhere in your article since it is definitely a FAQ


  86. Marc Lognoul MVP says:

    @Scott: the issue you mention is certainly related to the duplicated GUID of network adapters like reported by Chris and MarkR.

    Try uninstalling the NIC, rebooting, then letting the system detect it and generate a fresh GUID. Note: you can automate using devcon.exe.

    I’ve noticed a lot of issues supposedly related to duplicated SID while they were actually caused by NIC’s GUID. In the case of virtual machines, it’s getting more obvious because the destination hardware is scrupulously identical (no deep detection required).

  87. Geert says:

    What about network inventory software that relies on the SID to identify machines? (I’m not saying that this is the best approach, but there are a couple of programs that use this technique)

  88. Erik says:

    What about the MS DTC, it uses (a copy of) the SID to uniquely identify a computer. When doing distributed transactions, DTCPing will also report a duplicate id.

    I’ve seen this to, and the only solutions seemed to run newsid AND reinstall the DTC.

  89. Anonymous Coward says:

    1) I’ve had file access problems in the past that went away when generating a new SID. Clearly, something in Windows is using machine SIDs for something file-related.

    2) It is a clear case of broken design if you have to hunt for the local machine SID all over the place. They should have just used a special identifier for the local machine, much like . refers to the local folder. Would have saved millions of people trouble in the imaging and backups arena.

  90. zzz says:

    "Software that relies on unique computer identities either uses computer names or computer Domain SIDs (the SIDs of the computer accounts in the Domain)."

    I’m not terribly good at english but that sounds like an assumption or jumping to a conclusion. Or both.

    Do computers not in a domain have these unique domain sids? What is a "computer name" here – is it that one which one can manually set at startup to anything?

    While I would love the idea of being able to make an image of an installation to new hdd and have it work from the new hdd just like it did from the old one, in practise this results in some apps behaving differently as their protection may have locked into the system hdd model string or other harder to spoof identifier.

    The way I’m reading this article is that the "new best practise" can lead to assumptions that are fine for some apps but fail for a percentage.

  91. Roger Gammans says:

    What about this sceanrio – relatively common in small (ish) businesses.

    Two computers in DOMAIN. Say Machine1, and Machine2 , normally used by users DOMAINAlfred  and DOMAINBetty respectively.

    DOMAINAlfred is a member of Machine1Adminstrators, and

    likewise DOMAINBetty is a member of Machine2Administrators.

    But wouldn’t  Machine1 and Machine2 having the same sid effectively make them a member of both Machine1 and Machine2’s administrator groups?

    Allowing them to take contorl of the other PC via remote WMI etc,

    Or have I missed something subtle?

  92. BS says:

    I can only report on my experiences: Back in NT4 days, if you did NOT change the SID, something funny would happen. Install e.g. WORD on machine A. Clone it without changing the SID. Now start machine B, the clone. Start WORD.exe. Do you know what happened? It started WORD *from* machine A if this machine was on the network and reachable. It was a MAJOR headache until we investigated it. NewSid solved the problem.

    Now, even with newer Windows versions, there are major authentiaction issues if you have machines with identical SID’s. I solved many, many problems like these by simply running NewSid. If there will be now new version of NewSid for Vista and 7, the only way will be to use Sysprep or third party tools.

  93. v-juan says:

    I just would like to refer my own experience that offer problems in virtual machines, no tested on real one.

    w2k3 Clean Install in a workgroup, use new sid to generate a new machines,

    the new were joined to the domain, install sql, and a moss farm, in a distributed architecture,

    I got problems with the security authentication,

    May be the problem is related to virtual machines,  may be is a virtual pc, virtual server, vmware bug, but… for save I never use newsid on production machines due to already explained fact,

  94. Berny Stapleton says:

    My understanding from NT 4.0 days was that the machine SID was generated, and this was used with the domain UID to generate the domain SID. So if two machines had the same machine SID, when they were prepended with the domain UID that they would conflict.

    User accounts on the domain were different, in that they used the domain UID and a RID to create a SID.

    Or is my understanding flawed, with the advent of Windows 2000 and Active Directory, and the different revisions up to 2008, I haven’t heard that this has changed at all.

    Anyone feel like correcting me?

  95. JuanCa says:

    I would ask the SMS guys inside Microsoft… We have had incidents with SMS and duplicate SIDs.

  96. Darren Stewart says:

    If this is so, then seriously, why do I and many others see multiple and sometimes significant issues with machines that get cloned and where we forget to gen new SIDs? And beyond this, I don’t know if anyone out there uses the machine SIDs from a third party standpoint, but_if they do, changes like this are like a wrecking ball.

    This seems to me to be a blas’e change, taken on a spur and only with a check from a first and second vector, and not from the 3rd, 4th, 5th.

    Changes to Sysprep need serious and meaningful rtegression testing.

    Mark, I hope you reconsider, as I presonally found your tool to have a purpose, even if you now think this is not so :/


  97. Ed says:

    @Scott That’s because you have a duplicate *Domain SID*.  Domain SIDs are completely different to *Machine SIDs*.

  98. JF says:

    I’m not sure, but I believe DPAPI uses the computer’s SID as extra salt in a hash which is used as the seed for creating the key which encrypts the computer’s private keys for its certificates, such as for IPSec or SSL certificates (not user certificates).  Other salt data I think comes from the LSA Secrets and a 512-bit blob for this purpose in the registry.  So if you somehow crack this particular layer of private key encryption on one stand-alone system, could you then more easily crack it on its other stand-alone clones?  This issue would not apply after joining to a domain.

  99. KingFlathead says:

    I don’t buy it –

    1: Given that that Windows 7 / Server 2008 don’t have any issues with duplicate SIDs.

    2: Windows NT / Windows 2000 / Windows 2003 sure did. Windows NT especially.

    3: It’s still possible for a Windows NT box to join a Server 2008 R2 domain, under certain circumstances.

    4: Therefore, there’s still legacy code kicking around and this is still a problem.

    I’ve also *never* had trouble with NewSID, no matter how unsupported the OS supposedly is. Without, every once in a while a random network boojum will pop up, always fixed by NewSID.

    I’m not going to believe you until you come out with another article that explains what the real problems are, but why they are not a big deal in modern installs meeting conditions X, Y, and Z.

    Homework for Microsoft: Make a Windows NT 4.0 domain, 2-3 DCs, and 4-5 clients running Workstation. Give them all the same SID with NewSID before they are ever networked together. See what happens when you try to join them to each other. You could do this in Hyper-V in a few hours, assuming everything works 🙂

  100. Stoinov says:

    @ #1 – They are not useless, they are just used for local ACLs and permissions. When you talk about network access then the uniqueness of the SID is not relevant.

    @ #2 – you are using the username and the password to authenticate. for instance when you access restricted resource over the network you are asked for username and pass that have permissions and then the remote machine is initiating session for you with the provided account matched either at its local users list or at a domain accounts.

    Both machines may have two accounts with different SIDs but if they have the same username and password they will be able to access each other.

    And if they have the same SID but different username and pass they will NOT be able to access each other.

  101. Rob Engstrom says:

    This is a shame.  I understand the implications and reasons, but I have found (actually at VMWare supports suggestion) that when cloning an image (assuming we’re not using Vcenter or Vmotion, or one of the other high priced tools) that NewSID is perfect for changing the SID and machine name quickly and letting us fire up the new machines with relative haste.  So while I am sure there may be better ways and even more proper ways, this was by far the easiest!

  102. Pete Downing says:


    Great article!  I am the PM for Citrix Provisioning Services (formally Ardence) and arguing this fact since I started with the company.  It is refreshing to see our thinking is in alignment!


    Pete Downing

  103. Ben says:


    I think as time goes on we will discover more and more things like this "hidden out in the open!"  Great work!  I still plan on using newsid just because it’s fun.

  104. Phil Lewis says:

    As much as I want to believe this, I can relate an experience we had here in our test lab about 6 weeks ago where we had 2 sets of SQL Server Application environments that were deleting each others databases as we were testing. We traced the problem to duplicate SIDs on the SQL 2005 machines. When the SIDs were changed to all unique IDs, the problem went away. You cannot begin to imagine the horror of watching a user deleting databases on Server A and having the delete occur on Server B. The ONLY change we made to fix this problem was to run NEWSID.

    For WinSvr 2003 NEWSID will remain a part of our toolset. I respect Marks word on this and god knows he has vastly more deep technical knowledge than I do, but my in trenches experiences continue to show that there was a reason this tool was created, and its need is still valid in SOME CASES. When someone comes to me and provides better than the current anecdotal evidence that NEWSID is not required and there is a better weapon for addressing the issue of Duplicate Machine SIDS, I’ll be all ears.  

  105. Matthew McDonald says:

    "WSUS generates and uses SUSClientID to uniqly identifiy WSUS clients. Machine SIDS are not."

    Correct.  The SusClientID is generated upon connecting to the WSUS server and this ID is stored at:  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate

    I noticed this issue with WSUS.  Simple fix is to Delete the SusClientID and reboot.  Upon nect connect to WSUS a new ID will be generated and stored.

  106. Futurepower(R) says:

    Mark, I think you have made some mistakes. Many people on Slashdot disagree:

    In my opinion there should have been a chance for public comment before you decided to remove NewSID. Also, if the SID is not important for any version of Windows, several Microsoft web pages need to be changed. See this Slashdot comment:

  107. Nyamej says:

    I feel like a kid who was just told Santa Claus doesn’t exist.

    I too have seen apps (Microsoft and non-) that use the machine SID for identification, but because we have a small industry built up around a myth doesn’t justify its existence.  Nonetheless I will still tell our IT team to leave the cookies out just in case: The best practice is to follow best practices and use sysprep /generalize.

    Kudos, Mark, for stirring this up, validating some of us, and triggering a review of KBs.

    RIP, NewSID!  You served us well.

  108. jobinp says:

    For more information about the problem of duplicated SusClientID:

    Machine’s SID definitly has nothing to do with WSUS.

  109. Troy says:

    "The reason that Microsoft doesn’t support systems modified in this way is that, unlike Sysprep, these tools don’t necessarily know about all the places where Windows stashes away references to the machine SID."

    This seems a failure to standardize. Are you going to change that?

  110. jesse says:

    @WSUS problem: WSUS doesn’t use the SID it generates a unique ID when you first contact the WSUS server with the machine in question. What happens is people then clone the image but don’t delete that unique ID WSUS generates so that when the first clone connects it contacts WSUS with the same ID and WSUS then goes "Hey you’ve changed names!" and changes the entry name making it appear as though you lose machines from the listing.

    The solution is before you create your clone image to track down the WSUS registry entries on the machine in question and delete them. After that create your image and when you deploy the image the first time each machine contacts WSUS it won’t have an ID in registry and will generate a unique ID, problem solved. We used to do that with WSUS before we moved to SYSPREP and ran for years without changing machine SIDs without issue (XP and beyond).

    Do some google searches for solutions to the WSUS problem. Sysprep doesn’t just NewSID for you it also resets the WSUS registry entries thus making it seem like that is the issue with WSUS when it isn’t.

  111. Mark says:

    So why do all domain controllers have the same SID? What’s the purpose for that?

  112. Berny Stapleton says:

    @Mark – Domain controllers don’t have the same SID any longer, they used to under NT4.0 that’s why you had to build a server as a domain controller and you couldn’t promote to a domain controller.

    A domain controller is a member server with Active Directory on it and it’s SAM hidden. The local SAM is actually used for the directory services recovery console.

  113. Luigi Rosa says:

    IMHO it’s a bas idea to retire a long standing utility like NewSID.

    Many people will put it online on their website and there will be trojans claiming to be a new version of NewSID.

    Immagine what can do a trojan in a situation like the tipical use of newSID. Think about it.

  114. Andrew S. Baker (ASB) says:

    Thanks a lot for clearing this up, Mark.

    I’ve always wanted to know how the machine SID was used outside of a given machine. I guess I can finally fix the following:


    Providing Competitive Advantage through Effective IT Leadership

  115. Phillip Lyle says:

    While it is true that not running NewSID on workstatiosn will probably not have any adverse affects, there are several server-based applications that WILL run into issues (outside of Domain Controllers, as mentioned).  All servers will still need to have unique SIDs, less you run into an issue two years down the road and bang your head against a wall.

    Case in point: Network Load Balancing.  Take two identical computers that contain the same SIDs and try and add them to a cluster.  End result – you’ll be unable to add the second (duplicate SID) node, and not understand why.  Run NewSID and the issue is fixed.

  116. Phillip Lyle says:

    NLB might be an example of a distributed Microsoft application that uses the Machine SIDs.  Either way, it has problems in Win2003 when not running Sysprep/NewSID.

  117. David Peel says:

    Danger Will Robinson, Danger!

    Thinking about this for a second:

    The problem is not with identical machine SIDs per se, but with local User Accounts with the same name/password combinations on cloned machines, or the "potential" for local user accounts to be created with the same username/password/SID combinations!

    So on the surface machine SIDs seem irrelevant.

    BUT, If UserA exists on two machines with the same SID, he/she can use pass-through authentication [if passwords match]to access any clone machine as the LogonUser API only requires User/Domain/Password to return a Token. If UserA decides to create or modify a DACL on a remote cloned machine, by default the local UserA on that remote machine will also ‘inherit’ the same permissions as the UserA that created to DACL on the resource; as they have the same SID and therefore Access Token, even if they are two different people in practice.

    A pretty big security risk in my opinion!

    If MACHINEAUserA wants to protect his resources on MACHINEB, then pray there is no MACHINEBUserA account with the same SID!

    The only way to protect against this is to change the machine SID, so there is no "potential" for duplicated SIDs.

    This could also fall foul of compliance i.e. SOX/PCI. You couldn’t really allow a scenario to exist, could you?

    This should be very simple to test on cloned VM’s?

  118. MrHappyGoLucky says:

    Once again Russinovich schools us all.

  119. steveb says:

    Interesting read, thanks to Mark for the post.  I used to image systems but I only ran newsid on workgroup servers thinking there must be some issue if the SIDs matched some other host.  I can’t say I ever heard of what would happen, just went on what was the popular thinking.  For Domain servers I never used newsid as they get a unique domain SID anyway.  Never had an issue from that.

  120. pm says:

    i know I have had something complain at me that this is a duplicate SID. Possibly trying to build a complex AD forest out of a load of cloned VMs.

  121. Jeff25 says:

    AD only adds the RID to the SID and doesn’t replace the SID. the RID master is in charge of keeping track of the RID’s. When a token is generated the token contains the SID of user account (in this case the computer account) and other DATA about the account. RID’s don’t replace a SID in any way. If you create a new DC then create a workstation and clone the workstation before the workstation is joined each time a computer that was cloned joins the new computer will reset the RID in AD. This creates an issue because each computer that was joined at an earlier time would have to know to update the RID. You could see this by looking at the RID in ADSI and looking at the computer its self.Rids are never deleted from the RID master, it will just create new RIDs and store it for later.

  122. JaredCEG says:


    So you are saying that for a very long time the industry has been performing much unnecessary work and absorbing a nearly unquantifiable and truly staggering level of costs that, in all likelihood, outweighs the cost that would have been created by not performing the work, and that this is largely due to information provided directly by or publicized by you?  

    Just kidding.  Thanks for stepping up and bringing the truth into the light.  That is the most important thing.  When the issue first became known (when cloning became a widespread practice), there would have not been any easy way to really know what the ramifications of duplicate machine SIDs might be at that time or in the future.  The wise approach was to ensure uniqueness.  

    As they say, hindsight is very accurate, but foresight is much more valuable.

  123. AndyC says:

    Interesting. I recall having a similar discussion with colleagues a few years back and we came to much the same conclusion. Except we obviously didn’t have the Windows team on hand to go over it with! It was all a bit academic anyway, since sysprepping was still a good idea.

    I have to admit being unnerved by the idea of removing SID regeneration from sysprep though, especially given that 3rd party apps might be dependent upon it. Is regenerating SIDs really that time intensive on modern machines? If so, isn’t that something that could be engineered out of Windows (perhaps by replacing the machine SID use in other SID generation with a Well Known SID) rather than stripped out of sysprep where nobody is entirely sure of the consequences?

  124. alan says:

    Recently we had some machines ghosted without using sysprep.  Applicaitons installed with group policy failed to when a user logged on.  Remotely accessing the computers was very hit and miss.  I did not try generating new sids, but simply reinstalled the entire OS from scratch.  This was all Win XP sp3.

  125. Steve Turnbull says:

    I had two machines with the same SID running Windows 2008 server.  One a child domain controller and another a machine in the root domain.  When i tried to add child domain administrator accounts to a share on the machine in the root domain it resolved the accounts to itself as local admin.  Also remote connections via WCF fail to the machine in the root domain from a workstation in the child domain.  After running newsid on the computer account machine in the root domain it all works as it should  Also if you have duplicate SIDs Microsoft NLB does not work.  

  126. Steve Turnbull says:

    Microsoft SQL replication also does not work when machines have the same SIDs

  127. DaLi says:

    For all other networks like NetWare en Linux we never changed the SID’s on workstations and we never had any issue. So for non-Windows networks it seems no problem. And since the domain-machine-SID will be set when joining a Windows-domain there’s no further need for NewSID.  

  128. mike says:

    OMG! Mark!  Please clarify your stance on Machine SIDs and duplicate computer SIDs in AD!

    Because unless I’ve been living in some time altered "Twilight Zone" since 1999 (which would explain alot), Active Directory spews horrid errors continuously if it discovers foolishness like duplicate SIDS!

    Please help!

  129. Joe Shonk says:

    Hmm.. Not sure I agree.  If I newsid/sysprep, I do not not have problems.  if I don’t,  I have issues and I get this error message:

    Logon Message

    The system cannon log you on due to the following error:

    The name or security ID (SID) of the domain specified is inconsistent with the trust information for that domain.

    Please try again or consult your system administrator.

    (This is a w2k3 sp2 terminal server)


  130. Ray Avila says:

    Been a few years, but I ran into an XP lab, that had been imaged, but with out new SIDs being generated (ghost or sysprep) I know we ran into huge issues with it, most of them related around how the machines handled shortcuts copied between machines.  I ended up with an entire lab running a "local" program from a single lab machine.  Hopefully Vista and 7 cleared up some of these issues.

  131. David Peel says:

    Hi Mark,

    I am merely thinking back 10+ years ago when I started automating builds to what I remember the duplicate SID issue (or non-issue) to be.

    But, I think what I said is correct?

    I agree with your rebut, there must be other mitigating circumstances for this to be an issue.

    I have always understood this to be an issue for local accounts only, and the unlikely scenario I put forward. i.e. Users either knowingly or otherwise creating identical account/passwords combinations that share the same SID on multiple machines, however unlikely to happen in the real world.

    In the cloning scenario (without sysprep) there is however potential for accounts to have identical passwords. If they become known; either through poor security practice as you  rightly suggest or malicious behaviour, then there is a small but real potential to exploit duplicated SIDs and ACLs to access data.

    It may be a one in a million hole created by doing something utterly balmy, but it’s closed with unique machine SIDs. Which I still see as a good security practice, however remote the potential to exploit it may be?

    People do do some bizarre things:-)

    If anything I think Sysprep should give admins the choice.

    I think people will need time to absorb this u-turn in thinking, and test the heck out of it 🙂

    Chagrin is not a word you should use for any tool you have created, they bring joy to the world 🙂

    Greatest respect,


    PS: Absolutely love Windows Internals 5th Ed, everyone should own it! 🙂

  132. Bill Clinton says:

    Hey Mark..  Did you open a can of worms or what???

  133. mikec says:

    IF it’s an INDUSTRY best practice then Microsoft should now follow the INDUSTRY.

    The industry have adopted and used the MSID for it’s own purposes.

    If the reasoning behind MSID is right or wrong is of course another question :>

  134. GG says:

    Perhaps you should offer $1000 to the first person to publicly report a verifiable problem with a machine with a duplicate SID?


  135. Brian Zaugg says:

    Hey Mark,

    Your article was well-written and the use of examples was terrific. Clearly, there is a lot of confusion about the roles of the various identifiers that Microsoft uses. Also, the article and discussion clearly shows the power and importance of challenging assumptions.



  136. James Hess says:

    "The final case where SID duplication would be an issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID."

    What about distributed applications that have an explicit requirement that they cannot be run on domain controllers?

    Not all distributed applications are necessarily domain-aware or use domain-related identifiers.

  137. I used newsid just 1 month ago to solve a problem on our network. WSUS was not detecting four machines. They were all built from the same image and shared an SID. WSUS would only see one of the machines at any one time.

    I ran newsid on all four machines and it solved the problem. Handy tool, Then again so are all sysinternal tools.

  138. Todd says:

    WSUS uses it’s own ID number that is generated the first time it connects to your domain’s WSUS server or uses the windows automatic updates.  I have had WSUS problems even on machines where the SSID has been changed.

    The best practice I have found is to not connect the template computer to the Domain and not to configure Automatic Updates service until after the drive image has been captured.

  139. James R. Day says:

    I would imagine if you are using machine accounts as security principles on other systems it may cause an issue.  Say you have a scheduled taks that runs under the System account (not best practice) and transfers files to another machine.  The NTFS share on the other machine is machineaccount FC.  This translates into that SID having full control.  In that case, the other cloned systems with the same SID also have full control so anybody using those accounts could enumerate the share by running command prompt as System on their machines.  Of course, that is all not best practice so it may be a moot point.

  140. David says:

    I sometimes clone test VMs and run DCPromo on some of them. So basically I still need this tool.

  141. Mario Acevedo says:

    I have run into situations where duplicate SIDS are an issue.  I have two clients with a large number of computers that were all cloned without doing running a SID changer.  The result was that every once in a while a computer would fail to authenticate to the domain and the computer would have to be "re-joined" to the domain.  I was able to fix the problem by running NewSID on every computer (it tooks us more than a week) and changing the company’s deployment methods to use Automated installation (such as the ones nlite can help produce) instead of imaging.

    This company has been running for more than 2 years without the problem re-surfacing.

    In another company they were having problems with Microsoft SMS.  Hardware and Software invetories would get all mixed up in the database and software installations would run on the wrong machines.

    This last problem was a long time ago nd it was SMS 2.0, so I don’t know if it no longer applies, but the fact remaining is that the duplicate SIDs can indeed cause real life issues in complex networks.  At least up to Windows XP.

    I no longer use Image based deployments with any of my customers since deployment tools for Vista and 7 are much more polished.  I vote for this functionality not be removed from sysprep.

  142. Peder Olsen says:

    We have an unusual situation in which newsid proves useful.

    When we take identical W2K3 base images, and dcpromo them in isolated network environments, the Domain SIDs ("Every Domain has a unique Domain SID that’s taken from the machine SID of the first Domain Controller of the Domain") are also identical. This means that domain members, as they join, are assigned identical AD SIDs (on different unrelated controllers) because both domain controllers start counting their RIDs at the same place.

    So far so good, because of the network isolation, but unfortunately we have a product which stores the AD SIDs in hypervisor (Xen) metadata, outside the network isolation, and these AD SIDs can now clash when the product tries to work out which VM corresponds to which AD machine account.

    The only solution was to newsid the controllers _before_ promoting them.

  143. shane says:

    I have seen duplicate SID’s be an issue with WSUS.  WSUS would report a machine as being updated then not updated…changed as I watched go back and forth.  Reviewing the update logs on the machine revealed errors that led to me needing to change the SID on one of the machines.  Then all was good with WSUS.

    At the time WSUS was just SUS.  Things might have changed with the most recent version of WSUS.

  144. Matt says:

    I wonder if duplicate machine SIDS impact any forensic considerations?

  145. David Peel says:

    Well, I re-read Mark’s blog above, dusted off Windows Internals 4th Ed. , re-read Chapter 8:Security, got two clone VMs in a workgroup, windbg, process explorer and had a good play!

    And a good hard think about myself to boot 🙂

    You know what? Mark’s right! (of course he is, I hear you think!)

    Local Machine or User SIDs don’t play a part in authentication and resource access over a network; only the user name and password matter!

    My previous memory of this being a local account/workgroup issue has been well and truly laid to rest.

    I have been imaging using sysprep forever and never really paid attention to duplicate SIDs, never needed to. The last time I used NewSID to solve a problem was for NT4 and Proxy 2.0 in a training environment.

    Making this optional in Sysprep to be enabled when building new Domains is therefore a logical and welcome addition.

    Farewell NewSID, hello PsGetSID 🙂

    Thanks Mark, another great blog that made me think; what the hell do I really know?

  146. Mattg says:

    What… Is this a Joke. When I have copied a Virtual image of a windows 2003 server I cant join the domain until I change the SID. Also SCCM and SMS Both have issues with machines with multi sids. The server will add the harware inventory record to the resourceid based on SID, Computer Name and IP address. So you would end up with a different discovery recorded matched up to a different inventory record. I have had servers that had this issue before. Just a couple of months ago that I needed to run Sid Changer on them to fix the issue.

  147. Chris Lowde says:

    There seems to be a lot of confusion between the machine local SID and the Domain SID of the computer account in this thread.  Most of the problems reported are due to duplicate domain SIDS and not duplicate machine SIDs.

    There are however problems when you clone a computer and then make that computer a domain controller, in promoting a Clone to be a DC is a REALLY bad idea for a number of reasons.

    All local security principals are converted to domain security principals during the DCPromo process, this means that if you clone a standalone server with machine local accounts and groups and then promote the clone to a DC, both the domain and the original member server have security principals with the same SID.  It is even worse if you generate multiple domains from clones of the original server.

    If you have a really sloppy system integrator that is building machines and domains from a single image, either for a single company or more disastrously for multiple companies, these are sorts of problems that you are going to see.

    The following test steps were performed using Windows2003 SE, RTM – because it was what I had to hand and the majority of installations are still using W2K3.

    Test Steps:

    1. Build a brand new server, WG1, as a workgroup machine, set administrator password to Password00

    2. Create three user accounts acct1, acct1, acct3, with passwords Password01, Password02 and Password03

    3. Create three groups grp1, grp2, grp3

    4. Make acct1 a member of Administrators, and grp1

    5. Make acct2 a member grp2

    6. Make acct3 a member of grp3

    7. Shutdown WG1

    8. Clone the machine twice to DC1 and DC2

    9. Power up DC1 and change the IP address of the adaptor and rename the machine to DC1, restarting as necessary.

    10. DCPromo the machine to the new domain dom1.corp1.vnet

    11. Change the administrator account password to Password10

    12. Rename the user accounts acct1, acct2, acct3 to dom1-acct1, dom1-acct2, dom1-acct3 with passwords of Password11, Password12 and Password13.  This ensured that there are no matching account names and passwords between Dom1 and WG1.

    13. Raise the domain and forest functional levels to w2k3

    14. Power up DC2 and change the IP address of the adaptor and rename the machine to DC2, restarting as necessary.

    15. DCPromo the machine to the new domain dom2.corp2.vnet

    16. Change the administrator account password to Password20

    17. Rename the user accounts acct1, acct2, acct3 to dom2-acct1, dom2-acct2, dom2-acct3 with passwords of Password21, Password22 and Password23.  This ensured that there are no matching account names and passwords between Dom1, Dom2 and WG1.

    18. Raise the domain and forest functional levels to w2k3

    19. Clone WG1 twice to MS1 and MS2

    20. Power up MS1 and rename the machine to MS1, change the IP address and point its DNS to DC1.

    21. Add MS1 to the domain DC1

    22. Power up MS2 and rename the machine to MS2, change the IP address and point its DNS to DC2.

    23. Add MS2 to the domain DC2

    24. Logon to MS1 with local machine acct1, and DC1 as domin1-acct1 and run logonsessions  on both machines.  The SIDs are identical.

    25. Configure DNS on both domains so that they resolve entries in the other domain.

    26. Try to create a trust between Dom1 and Dom2, it fails because the trust creation process believes that the trust is being created with the current domain.

    27. Create a share on MS1 and permission with DOM1DOM1-ACCT2

    From DC1 attempt to net use to the share using /user:dom1-acct2.  It will fail with an error “The name or security ID (SID) of the domain specified is inconsistent with the trust information for that domain.” If you attempt to net use with /user:ms1acct2 it will work

    The failure is because the Member Server is attempting to resolve security accounts against its own SAM database and not that of the domain.

    Attempting to move accounts between DOM1 and DOM2 will fail because the attempt to add the SID from DOM1 to SIDHistory in DOM2 will fail with duplicate SID error.  Since you can’t put a trust in place the process has to be run with matching username and password on both domains.

    In general cloning machines without changing the SID is not a good idea, especially if they are promoted to domain controllers.

    A better idea would be if the domain SID was based on a new sid and not the machine SID of the first machine in the domain.

  148. Fully support Chris Lowde!!!

    In addition just imagine if you are set MS1 as member server and use acct2 to setup some security ACL on files or other object. Logon under dom1-acct2 on MS1 (acct2 and dom1-acct2 looks like a different account) but dom1-acct2 will provide access to objects because of identical local SID and Domain SID. It is like SID History works.  

  149. Steven French says:

    Interesting that Microsoft own Core Team just posted a blog entry contradicting this:

  150. nick says:

    Steven French should read links before posting them.

    "The Client Machine ID (CMID) is how we uniquely identify a KMS client.  When sysprep is run one of its jobs is to generalize this GUID so when the image is deployed every machine has a unique CMID."

    CMID != SID and as Mark said, Microsoft STILL recommends running sysprep on cloned images to prevent problems.

  151. dcaudill says:

    I worked for a school district last year that had hundreds of machines that they had bought as refurbs.  Each of these machines was imaged and had the same SID.  

    Group Policy did not apply correctly on any of these machines.  Students were randomly granted rights that they shouldn’t have been, etc.  Sophos Antivirus was completely screwed up from the enterprise view(updates applied incorrectly, status reported wrong), and WSUS threw constant errors on the machines that were duped- if they got any updates at all. Machines couldn’t properly join the domain at times, and sharing was a nightmare.

    Then I ran newsid on every one of the over 300 machines affected.  Newsid fixed every single one of these problems.

    I find this article difficult to understand because this tool has fixed so much for that institution.  

    What did I miss here?

  152. Phil says:

    While very interesting, I think this thread shows that there are a whole host of Microsoft products that potentially will have issues with this new "best practice".

    The article needs to remove the "No Microsoft software does so" bit towards the final paragraphs – SQL, NLB, SMS, etc. have all been listed in thsi thread as potentially having issues, along with a plethora of third party software.

    Do you really want to take the chance of something not running on your box a few years down the line?  Does Sysprep take too long?

  153. Megan says:

    @Mark – Please ignore my comment from 11/3/09. I was getting my machine GUID and SID mixed up 😀

  154. Rodolfo Giovanninetti says:

    Some years ago, I setup TrendMicro OfficeScan client on a test pc that was in a workgroup. After that, the pc was ghosted, without sysprep, and then cloned pcs were joined to the domain. The OfficeScan server could not distinguish between two pcs. On the management console I could see only one pc, the one that had been booted latest. I had to remove OfficeScan client from the pcs, and then setup it again, after they had been joined to the domain and so they had been given each a new unique domain sid (the local sid was still the same for all of them). It seems to me that when I setup TM OS client it identifies itself through the sid. If two pcs have been joined to the domain, they have been assigned two different domain sids, and in this case TM OS uses the domain sid, so no problem. But if I setup TM OS when the two pcs are in a workgroup, and they have the same local sid, TM OS identifies them as the same pc, so You are in trouble.

    So, it seems to me that the duplicate sid issue is still valid.

    Thank You

    Rodolfo Giovanninetti

  155. dcaudill says:

    I should add that these machines were duped OFF THE DOMAIN and then added later.  This is a problem that I just spent over a year troubleshooting…which, by the way, I could not have done without Sysinternals and PsTools!

  156. Abraham Marquez says:

    Rodolfo G,

    There’s actually a TM utility to correct that issue and it does not seem to be the same SID as the windows SID.  Look up the following utility for more details "ImgSetup.exe"



  157. Jason Hart says:

    SCCM sms replacement if the SIDS match and the hardware is identical they have a chance of creating the same GUID for duplicate boxes. This means the SMS server can only see ONE of them at a time. Until we Ghostwalked the machine (similar to new sid) the VISTA SP1 and SP2 machines couldn’t be identified as sepertate entities until the sid was changed and a new GUID was created for SMS (deleting smscfg.ini)

  158. Jolyon says:

    The danger here is that while the author might understand the topic fully it is clear not everyone reading the article does.

    We would all agree that having unique machine SIDs results in no harm whatsoever and that having other identifiers duplicated will result in problems so I question the need to publish this analysis in this manner regardless of the factual correctness.

    I fear the net result of this article will be that careless readers / thinkers will decide that unique identifiers (of whatever sort) are no longer important ‘because the really clever bloke from sysinternals said so’.

  159. nvatray says:

    When two machines are made from the same ghost image and then joined to the domain.  They have the same SID.  If you are trying to disable or delete one computer account the other is also affected.  Meaning the other computer with the same SID is denied access to the domain.

  160. Buddy Farr says:

    We had an issue where we installed 4 new servers that had been cloned by a vendor but new SIDs were NOT created. One was a terminal server and it would reboot on it’s own every day. We finally had to call Microsoft tech support and they said that the error dumps said that it had a duplicate SID. We ran NewSID on the server per Microsoft’s tech support request. Never had the problem again.

  161. rajender saini says:


    We were recently creating domain site with Virtual images. when we were trying to create two different domain under same forest. It was not allowing us due to virtual image being copied. It worked once we changed the SID for one of machine.

    So i am wondering is SID really not required in this scenario ?


    rajender Saini

  162. FSK says:

    Great article.

    Many people not understanding the difference between machine and domain SID though…

    And a lot of people cloning machines on the domain.

    So a sid changer tool is invaluable to help fix people’s problems afterwards. Please reconsider bringing NewSID back from retirement 😉

  163. James M says:

    Forgive me for some possible bad wording, it’s 1:30am here and i can barely keep my eyes open…

    I notice you say that the issues with duplicate SIDs occurs once a machine has been added to a domain, if you are creating an image for cloning which you install all your relevant software on, add to the domain to do some other tasks and then remove it from the domain for cloning (so it’s installed off the domain, been added to the domain, and then removed again for cloning) will this cause the domainSID to be the same as the first time that machine was connected to the domain or will they generate new ones for each machine?

    Thank you for all, especially Mark, for all this information.

  164. Chris Lowde says:

    James M,

    When you add a machine to the domain a computer account is created in the domain, if it does not already exist, and that account object is security enabled which means that it has a Domain SID.  Each computer that is added to the domain will get a unique computer object, and therefore a unique Domain SID.

    When you remove a computer from the domain, the computer object is not deleted.  When you add a computer back to the domain the ADD Computer process finds the existing computer object by searching for a sAMAccountName that matches the computer name plus a trailing ‘$’ (this makes it a hidden sAMAccountName from an NT4 perspective, like share names that are terminated with a ‘$’).  The re-joined computer will therefore get the existing DomainSID which is an attribute of the computer object.

    Many large organisations pre-create computer objects in the AD before joining the computer to the domain so they can control which container the account is created on, based on computer type, geographic location or any number of other rules.


  165. Chris Lowde says:

    In my earlier post I worked through a number series of steps that demonstrated why building domains using cloned machines was definitely bad.  Because I built a single domain forest I was unable to create trusts between the two domains, and therefore SIDS in one domain could not be used against the other domain.  It only caused problems if you try to migrate accounts from one domain to the other.

    Also when you net use to a share, the SID is not used, it is the Domain and sAMAccountName that are used, so it is always going to prompt for a username and password. (unless you supply the username on the net use command, and the password of the account matches the password for the currently logged on user)

    Now for the kicker. 😀

    If you build a multi-domain Forest, and the Forest root domains are not built from cloned systems then it should be possilble to create a cross-forest trust (I have not tested this yet).  At this point it becomes possible for a SID in D1.F1 to match a SID in D2.F2, it would look to AD as if a SID History in D1 had been populated with a SID from D2, and SID filtering would not block it.

    As I said earlier, building Domains using cloned configured machines is really, really bad.


  166. RamGeek says:

    Have seen problem with Duplicate SID when using SMS to push an OS to workstations. Had one of our offsite locations image all of there workstations so they all ended up having the same SID. When one of the administrators pushed an image to a workstation, he ended up pushing to all workstations that had duplicate SIDS!!!!!! Ended up causing quite a problem, since user data needed to be backed up before pushing the image, so no thanks. Will continue to find method to change the SID whether it be Sysprep or NEWSID

  167. james says:

    As sysprep isn’t an option for the way our machines are setup, can anyone suggest a way of creating a newSID on windows 7 machines?

    The program NewSID has caused some very unstable results on windows 7 professional here, we are deploying windows 7 next year across site and will need something to get around this issue.

  168. msb says:

    Uhh…. seems you haven’t fully considered the use case of incident response and forensic analysis.  The status quo provides a benefit to forensic investigators.  Is it daming proof? No… but by discouraging unique SID’s across an infrastructure, you do lose several benefits with respect to forensic analysis and incident response.

    Thumbs down.

  169. aaronb says:

    As others have mentioned, duplicate SIDs for clustered machines is a big problem.  I wasn’t aware of this fact until recently I was clustering a pair of Server 2008 systems that I had used the same image for.  Adding the 2nd node, with the same SID, to the cluster fails.  Apparently it does use the local SID for something or other.

    In the past, I’ve never worried about duplicate SIDs either, but clustering was always something that posed a problem.  I don’t think Windows 2003 clusters had much of a problem, but I don’t recall.  One thing you do need to look out for is DTC, since a duplicate SID can cause strange SQL connection problems.  Resetting/reinstalling DTC is the way around that.

  170. shane says:

    Interesting read. I’ve been using imaging for a while with PC’s & notebooks with the following method with no issues. That’s not to say there would not be software out there that does have issues. I don’t think I’d ever want to use imaging like this for servers though…

    Complete base XP install.

    Connect to network and install Trend Micro AV.

    Join to domain.

    Install all pre user base software and updates (SOE if u like).

    Create image (Symantec BESR or Macrium Reflect).

    Continue user setup of this PC and deploy.

    Image new PC(‘s) from above image.

    Before connecting to network uninstall Trend AV, remove from Domain and rename PC.

    Connect to network and install Trend AV.

    Join to domain.

    Continue user setup and deploy.

    No sysprep or NewSID. No issues on the Domain or the PC’s.

  171. mweb says:


    Keep in mind that sysprep is the only supported way from Micorosft to change the SID,also in Windows 7.

    So you maybe have to change your way of image preparation/deployment.

  172. zhy says:

    A member server can not login DC with the same SID. I always use NewSID to change my Virtual Machine SID before dcpromo.

  173. prb says:

    What is really worrying in this thread is all the ignorant comments and lack of reading comprehension from what are probably sys admins in major corps.

  174. nexor says:

    am glad someone has finally answered for the question!

    but… if now it’s clear and obvious – what are you going to do with that in next windows release?

    …and now something more is clear – since w2k8 R2 there is a way of offline domain join, but the tool do not reSID the machine. i was thinking why – i suppose someone has figure it out earlier that it;s simply not nessesary q:

  175. FillDee says:

    @prb  – Exactly what I have been cursing to my fellow admin all the way down this thread ! 🙂 Some of these may even look after my bank accounts !

    I cannot believe the ammount of people who cannot understand the basics !

    It’s great article, very thought provoking. I’m not entirely convinced all software will work flawlessly (but that’s not MS’s fault), but I’ve personaly never come across any issues DIRECTLY related to the local machine SID. GUID’s – yes, WSUS ID’s – yes, other 3rd party "SID’s" – yes, but not local machine SIDS.

    Anyway, at least the main message got through to some users….Thanks Mark.

  176. Andre says:

    I have found in the past that MSDTC cannot communicate between two machines that have the same local SID. ??

  177. epop says:

    As some other guy noted before in these comments, better check with SMS guys first. I believe SMS client will trigger the creation odf a new SMSID if a new SID is detected upon reboot. Alternatively, it might not do that if SID’s the same and hardware’s the same (clone a virtual machine). That is a bad thing. I am sure there is plenty of software that relies on that SID to determine if it runs on the original system or on a cloned one. That’s why I wouldn’t scrap the new SID generation practice just yet. That’s what happens when the OS developper leaves gaps in their product. While strictly for security resons this may not be an issue, I believe it is an issue from identifying the system aspect. MS should’ve provided and system ID long ago that would be independent of security ID. That wouldv’e avoided many problems.

    Anyway, great article as usual Mark.

  178. Erik W says:

    I never used Sysprep because it usually killed my images (Which contained applications).  All I do is recreate the SIDs relating to WSUS.  I have never had any problems otherwise.

  179. pbkq103 says:

    Mark, please look at the below info an tell me if your identical-SID issue would impact the problem described:

    One of the most frustrating problems I have run into when installing WSUS was an installation in which most of the computers in the organization were not showing up in the WSUS console. My GPO was setup correctly and WSUS was running, but most of the computers were simply just not showing up.

    After some digging here are the results I came up with. The IT Administrator who originally setup the network did so through ghost imaging. In doing that, sysprepping his original source image wasn’t in his list of steps. That being the case, some of the registry keys specific to Windows Update that sysprep clears were inherently not cleared properly.

    Fixing this issue is a pretty simple registry edit for each computer. First, make sure that the Automatic Update service is stopped. Open up regedit, and browse to HKLMSoftwareMicrosoftWindowsCurrentVersionWindowsUpdate. From here, delete the PingID, AccountDomainSid, and SusClientId entires. After doing this, start the Automatic Update service again, and at a command prompt, type "wuauclt.exe /resetauthorization /detectnow". This should make the computer show itself in the WSUS console


  180. Ben says:

    The computer or domain CMSPS01 trusts domain CLOUD.  (This may be an indirect trust.)  However, CMSPS01 and CLOUD have the same machine security identifier (SID).  NT should be re-installed on either CMSPS01 or CLOUD.

  181. Gavin says:

    Thanks Mark!

    Got to love how some things are just done because "its the ways its always been done".

    Thanks also to pbkq103 – Turns out the WSUS issue really isnt caused by the duplicate SID, WSUS is using a different ID that id duplicated when you clone a server.

    Your simple reg hack and re-registration tip got my WSUS working properly again!

  182. Jakob Bohm says:

    According to and other sources, there is at least one situation in which Windows Security relies on Sid uniqueness, although this problem MAY be limited to the Sids of primary domain controllers (= Domain Sids) and one non-DC member at a time:  When a user from a trusted logon source (typically a DC) accesses a resource or machine other than a DC for that domain, the Sids for that user on the domain are transmitted (over the old secure channel or in MS Kerberos extensions) and trusted by the client.  This caused a real security problem where a "trusted" DC (used only for login of untrusted users) could include Sids in *your* domain, thus elevating the privilege of those users.  To fix this SidFilter was introduced in an NT 4 security update.

  183. Jakob Bohm says:

    Remember the ACL editors: The common GUI elements for editing permissions on files registrt keys etc., whose API was undocumented in NT 4 except in an article by Mark.

    If two machines (not DCs) have the same Machine Sid (not the same DomainMachine$ Sid though), then the ACL editor will get confused when showing/editing an ACL of something on the other machine.  Example:

    On COMPUTER1:  Machine SID S-1-5-21-12345678-12345678-12345678

    RIDs under COMPUTER1:

      -500 COMPUTER1Administrator

      -1001 COMPUTER1Alice

      -1002 COMPUTER1Bob

    On COMPUTER2:  Machine SID


    RIDs under COMPUTER1:

      -500 COMPUTER2Administrator

      -1001 COMPUTER2Bob

      -1002 COMPUTER2Alice

    If a directory stored on COMPUTER1 such as \COMPUTER1SHARE1ourdocs has permission COMPUTER1Alice: Read, COMPUTER1Bob: Full control, viewing those permissions with the ACL editor on COMPUTER2 will show the permissions as COMPUTER2Bob: Read, COMPUTER2Alice: Full Control.  And it gets worse from there, especially when propagating inheritable ACEs that refer to CREATOR_OWNER, when taking ownership etc.

    So please resurrect NewSID and update it with whatever extra tricks are needed to work with the latest Windows versions (without throwing away the ability to run it on old "unsupported" systems such as NT 4 and NT 3.x,

    as those may still be needed in lab scenarios such as software testing.

  184. El-Barn-O says:

    Yes, Mr Russinovich, I read it and I understand it. And I agree, from Microsoft’s persepctive, it isn’t needed. Microsoft doesn’t use SIDs external to the machine. Does that mean they aren’t used by other software? Microsoft doesn’t exist in a vacuum. As Kamrate asked, Nov 03, 2009 at 3:06 PM, did you really do your homework? Or have you just decided to tow the Microsoft Line, and the rest of us can fend for ourselves?

    You’re condemning sysadmins to waste hours using Sysprep (which has issues with lots of software I administer). NewSID is much faster. Please return it to us, with updates for Windows 7.

    When Microsoft acquired SysInternals I predicted (as did many PC professionals) the death of many useful SysInternal utilities that did things in ways Microsoft did not approve, or indeed even (in some cases) understand.

    How long before you pull PsTools or Process Explorer?

  185. Rob J says:

    Mark – I just read your comment –

    "@Chuck: because AD uses the machine SID of the first Domain Controller as the SID for the Domain, and all systems subsequently promoted to DCs on that Domain adopt the same machine SID, member systems cannot also have that machine SID.

    For the DC you want to create from a clone, create a unique installation or run Sysprep."

    This is exactly my problem – you think I should waste another whole day building up another machine, one I will use for a week so Microsoft can save disk space for a 50kb file?

    Are you on drugs? I know who is buttering your biscuit these days.

  186. markko says:

    Reading the comments on this article I understand, that NewSID isn’t just a tool to genereate the new SID to the machine but a tool to solve all kind of other problems which are not related to machine SID but which the generation of new SID helps to solve. Like WSUS. You generate a new SID and update services generates also new WSUS ID or whatever. And people forget that if they do windows install, applications install and configuring then they just don’t clone only windows but all applications settings and stuff. And all this other identical stuff causes usually problems, not the same SID. But as we see the new SID generations helps usually with other problems then it’s quite problematic for people who are used to simply launch NewSID and solve their problems with it. They must start doing things differently.

    I have used NewSID as it was always the belief that you must change the SID but recently I have had problems with cloned x64 servers and VSS writers. There is solution( but it also shows that maybe without NewSID I have fewer problems. Next time I try cloning without NewSID.

  187. Ares Apostol says:

    The software company "Stardock" ( Uses SIDs as a form of software protection to their software!!

  188. SteveL says:

    I understand that newSID doesnt do enough, but a lot of things do need a new SID, and you can’t just copy a virtual disk in the filesystem without running it. Sysprep is fine if you are trying to reset everything, but just copying a VM between the desktop and the laptop doesnt justify it, especially when you don’t want the hassle of reactivating everything

    I also think its a shame that the tool has been removed. At the very least, open up the source code and stick it up as an OSS tool for people to work on if they want. As it is I am going to have to look around dodgy sites for a copy. Please at least list the MD5 checksums of the latest binary, so we know the one we get from rapidshare hasn’t been modified.

    Can I close by noting that Linux is a lot happier about being moved around, way more VMWare friendly. Pity that.

  189. Protocol16 says:

    Very cool. I am one of those that argued at my last company as well – even after proving things right, I still got the "well, we’re not going to do it.." routine.


  190. Yves Gattegno says:

    Thanks Mark –

    Now we can refer our users to this page when they fear duplicated SIDs problems!

    Using duplicated SIDs is a common practice with OS streaming products (shared virtual system disks, used to boot diskless computers) such as HP Image Manager, Citrix Provisioning Services or Double Take Flex: Because you share a single disk image, and because of the way machine SIDs are used and implemented, you can’t change SIDs dynamically so that each client computer has its own personal SID when booted off a shared disk image.

    As the original inventor of HP Image Manager, I studied machines SIDs in detail and I can tell that duplicated SIDs never caused any problem in our tests. Actually  we do expect the disks that each client mounts off a shared "disk image" to be 99.9% the same, including SIDs (the remaining 0.1% comprise the computer name).

    Now what about computers that are members of a domain?

    Once again, just let me what our experimentations revealed:

    We invented a technology to dynamically update "Domain Credentials" and it works perfectly on machines with duplicated SIDs, since, as Mark explained, the machine SID is not used in domain operations but for DCs (which uses the Machine SID of the first DC that appeared).

    For all the persons that think they had problesm with duplicated SIDs that were solved by sysprep, please remember that sysprep does not only change SIDs, it does many more things. I do not tell that some 3rd party application do not rely on unique SIDs, I wouldn’t pretend I know every software that can run on Windows, but I can tell that I never saw any issue with duplicated SIDs when it was done "properly" and with the applications used by we and our users.

    Last but not the least, it’s a very good news that Microsoft policy about duplicated SID will evolve nad if it becomes supported to have duplicated SIDs, then I think that a lot of things will become easier…

    Thanks again for this post

    – Yves

  191. Yves Gattegno says:

    I used to refer our users to this article (currently unavailable, but thanks to, nothing really leaves the web… but NewSID and other pages which are explicitly requested to be removed from the 15 billion pages database by their owners…)

  192. Steve Gray says:

    Most of the concerns about cross-machine/domain authentication holes are non-issues. When you authenticate against a SAM (be it local or other), you are issued a token that effectively identifies you to that SAM. Then you call some subsystem (such as reading a file), and the token is passed through. The SAM then confirms it issued the token to allow access.

    In a network scenario you are not at threat from identical SID’s at all. Transparently authentication will normally work anyway if you have identical user names and passwords.

    To understand why this is a non issue, consider the following scenario:

    Machine A: SID 123, User: Bob, SID 123-1

    Machine B: SID 123, User: Alice, SID 123-1

    * Bob tries accessing \MachineBC$ over the network from machine A.

    * Machine A does not support guest authentication, issues a CHALLENGE

    * Bob’s machine answers the challenge with local credentials (since it is a network location), supplied either from the cached credentials or a prompt (Note: Never transparent unless you’ve been to that machine).

    * Bob fails to authenticate (because the cross-machine calls do not operate in terms of SIDs, but usernames!)

    Let’s change this scenario so that both machines use the same username/password. Let’s also suspend reality and assume that Windows will blindly answer an unknown machines ‘challenge’ with the correct response for the authenticated user.

    The last step would thus become:

    * Machine A answers machine B’s challenge.

    * Machine B recieves response, authenticates user against local SAM.

    * Machine B SAM issues token to Bob’s valid credentials (the username/pass ARE the same….)

    * The network connection from A to B now operates in the context of the token (which is never passed across the wire to A, but is held in state for the connection on B).

    Thus if Bob changes his password on A, when the connection ends, the challenge/response cached result will fail and a prompt will be displayed.

    Don’t forget that succesful credential challenges have the credentials changed. So even if you change your password on A, the entry you used for B would still be correct in the cache though. You’ll still be able to log onto B via the cached credentials providing:

    1) You don’t clear the cache.


    2) You don’t change the password on B (invalidating the cache).

    To give yourselves an idea why Windows does not use SID’s across the wire for identification, all you need consider is this – you can get a domain controllers SID from any machine on the domain. Since Administrator is a well known SID, you also can guess the SID for DOMAINAdministrator. It’s not possible to use that SID for anything though (otherwise EVERY domain would be vunerable, which clearly isn’t the case).

  193. Bruce Zikmund says:

    Mark, I understand that newsid might introduce problems because it could miss some deeply embedded SIDs.  However, I definitely wouldn’t make the statement "NewSID has never really done anything useful".  Like dcaudill’s post from Nov 5.  I worked at a large school district that had several thousand Dell computers, of which, a couple thousand had a strange problem due to Dell’s ximage process (similiar to sysprep).  When you would rename a computer just prior to joining the domain, during initial setup, the computer netbios name wouldn’t change under "net config workstation" but the full name would.  This prevented the machine from joining domains successfully. Dell’s solution required re-imaging and a manual touch to every affected computer.  We discovered that newsid completely corrected the problem and could be done so remotely using pstools.  In essence, newsid saved quite a bit of school support time and money.  Granted this might not be a mainstream use of the tool, but its ability to correct this type of a low-level issue in an automated fashion had quite a bit of value for us.

  194. Jonathan Johnson says:

    Seems to me there should be an option on an NTFS filesystem to disable ACLs on removable media without having to resort to using FAT32. Since ACLs are mapped to the machine or domain user account, they can only permit or restrict access when connected to the original machine or domain. When connected to another system, ACLs might appear to restrict access (often when they shouldn’t) but are easily overridden. This causes a lot of confusion for non-technical users.

  195. Jan Kowalski says:

    @Ares Apostol

    "The software company "Stardock" ( Uses SIDs as a form of software protection to their software!!"

    Then it’s their problem. It seems they’ll have to reconsider licensing protection in their software.

    Me too 🙂

  196. Sam McBride says:


    Please do not confuse the value of authentication and the value of identifying a System’s Uniqueness.  Token based authentication is an established relationship trust and a System UUID is a way to identify the System Object from other System Objects regardless of any relationship.  

    Regardless how MS uses SIDs, it is treated as an API from partners as a uniquely identifiable tag for an OS system.  This should not be taken lightly as something that can be discontinued.  Not every system is joined to a domain and MS established the usage of the SID as a UUID.  

    There is tremendous value that a system installation has a unique identifier regardless of the Domain SID that a joined domain gives a host.  HW Serial Numbers, MAC addresses, Domain SIDs, Hostnames, and IP addresses are all outside controlled UUIDs.  Most of them are so weak, that they cannot be used for uniqueness.  Some of them do not survive the constant reorganization that companies perform.

    It is concerning that MS is taking this stance about a SID.  It may be convienent to depreciate the usage of the SID, but now Systems no longer have a UUID.  

    OS Systems are containers for Business applications like MS Exchange.  It is very important to track the system capacity and usage trends over time.  Domains are created all the time and reorganized, but a system generally lasts a long time.  Reconciling the measured performance statistics of a system with a previous Domain SID to the new Domain SID is problematic.  

    ALL Objects should be responsible for generating their UUID.  Having an outside entity create the UUID does not guarantee that the Object will be trackable through all relationships.  Outside entities creating UUIDs on a system’s behalf also is difficult to reconcile cross vendor solutions.  I cannot imagine Ethernet cards getting the MAC address from the Switch.

    BTW…Microsoft SQL Server copies the SID for some purpose during installation to its product.

  197. Nick Brown says:


    So the bottom line is that we can longer use NewSID, but must use Sysprep to ensure a unique SID. I can understand that MS doesn’t want to support two similar utilities and Sysprep is the preferred way forward, so can I make a suggestion. Provide us with a Sysprep switch that ONLY changes the SID and does nothing else – essentially duplicating what NewSID did. Given that Sysprep already has the functionality this should be a five minute job.

    You may ask why not just use Sysprep as it is? Well it’s just that my experience with Sysprep is that it does more than I want it to on the system that it is run (copying the Administrators profile to default, for example, was a real annoyance). I know these things can be configured, but I really don’t want to be wasting my time trying to get it to function the way I want it to. Add to that the longer first-boot experience post Sysprep and I’m not a fan.

    After all who here knows *exactly* what changes Sysprep makes to a system? I don’t and without that info I can’t judge whether those changes are suitable for my situation or not. Let’s not forget that there have been a number of versions of Sysprep so every time a new version is released we’d have to go through this process of evaluation.

    With NewSID I was able to configure a system *exactly* as I wanted and know that it would stay that way even after SID regeneration.

    You may then also ask why not just take this new advice and not worry about SID duplication. Well like others I’m not yet convinced that just because you haven’t a reason for it to be an issue means that there isn’t one. When Sysprep offers the option to skip SID generation (as you suggest it will be in future) then I will accept it to be official MS policy that this is a non-issue. Of course that still leaves me to investigate whether any of our 3rd party apps rely on unique SIDs.

    Finally Mark, did you run your argument past the EFS guys? The reason I ask is that I believe that the machine SID is used in some part of the encryption process. I apologise for being vague, but I remember a few years ago following a process to recover an EFS encrypted directory from a dead system. Part of that process *required* me to prepare a system that had the same SID as the original system that the filesystem came from (of course I used NewSID). This leads me to a concern that not having unique SIDs may weaken the protection afforded by EFS? If I can find the link to the process, I’ll post it, but I don’t have it right now.

  198. Mike Elliott says:

    Great post Mark.  This got me thinking about the imaging process however and what exactly gets reset by sysprep.

    The link you mentioned earlier to show what state gets reset appears to be an incorrect link  Any chance you could repost that link?


  199. John Murray says:

    Very interesting reading, and mostly confusion regarding machine SIDs vs domain SIDs.  Makes me wonder how so many rollouts have happened successfully given the lack of basic understanding.

    Looking forward to your next article on why there is no real need for IP addresses (or simliar) perhaps?

  200. Richard says:

    Maybe I am too cynical (not without reason given MS’s history), but I think the most telling of all comes at the very end of the article:

    "Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep."

    So ONLY MS’s "approved" method is valid?  And notice what it is tied to – getting updates.  What?  MS wants me to use a process that is more complicated and time consuming just so I can get updates?  Why not use the industry standard way to uniquely identify a machine that has been accepted for close to 15 years conveniently known as the SID?  Why change now?  To exert more control over the customer?  

    I mean.  A great 3rd party tool used to accommodate any type of "grow your own" deployment that has been used for years is found to be bogus and then "retired".  Communication goes out that it can’t be used anymore and that the only supported method is to use the MS method.

    I have high respect for you and the tools you have written Mark (and have for I don’t know how many years) which makes this sound even more strange.  

    I don’t know, maybe I read too much

  201. Chris Quirke says:

    I’m a small-scale custom system builder, struggling with WAIK to image new PCs.  None of these PCs work with Domain LANs and most of them use the Home Basic SKU.

    Can I skip the Sysprep stage, before harvesting my (Windows 7 64-bit) reference image?

    I would like to, because I find Sysprep always screws up settings etc. and often botches the "mini-setup" phase that follows on the next boot.  That in turn kills both the reference PC, as well as rendering my harvested .WIM unusable.

  202. Patrick OToole says:

    I happen to think Mark Russinovich is one of the smartest people on the planet, but I have to disagree. I’ve had a lot of experience cloning machines and if we don’t change the SID, there are always problems. I am currently working on a DCOM problem. Two machine setup identically. I can connect to one but not to the other. We just found out the SID is the same. (the drive was cloned) The connection that works is to the original machine. The one that doesn’t is the clone.

  203. Anders says:

    The problems with MSDTC and network load balancing are not related to the machine SID whatsoever. A few years ago I cloned W2K3 servers after running HP’s own variety of SysPrep – hpprep (I assume that tool changes the machine SID), but couldn’t get the DTC to run. Running SysPrep on the two machines solved the problem so I guess SysPrep changed some other intentifier or registry key.

    All problems I’ve had on cloned machines have been related to other identifiers than the machine SID, most of which SysPrep fixes. Why struggle with unsupported ways of imaging when there is a working tool from the guys who built the OS?

  204. Overscan says:

    "I sacrificed a virgin to the gods and the rain came. Hence, virgin sacrifice brought the rain."

    "I had an issue xxxx. I found the SIDS were identical. Therefore identical SIDS cause issue xxxx."

    *EVEN IF* running NewSID somehow fixed your issue, it is entirely possible it did so as an unintended side-effect (for example, the SID changing triggers the actual thing causing the problem to regenerate itself).

    I’ve used sysprep since Win NT without issues in various environments. Its frankly staggering how many admins are cobbling together Windows deployments without following the correct procedures and relying on Mark’s NewSID tool to fudge it into a working state.

    Argument from personal incredulity or anecdote is the antithesis of scientific thinking.

  205. Jeff Schertz says:

    Here is some more background on the WSUS issue; it’s not Machine SID related but uses a different value (pointed out above in a few posts).

  206. Burt says:


    Though the responses have continued to grow, I do not see a response to my posting number 3291283. The scenario and steps used are not machine-state related, nor are they joined to a domain (so is not Domain SID related).

    The case is solely machine SID related as the account for the local Administrator account (using a RID of 500) is the same for each machine since the machine SIDs themselves are the same.

    Just looking for your comments on this and the test I proposed.


  207. Leo Lee says:

    Hi Burt,

    Though I didn’t think it would be an issue, I did a quick experiment with vitual machines just to confirm.

    After you change the administrator password on one of the machines, you’ll not gain access to the other machine. Instead,you’ll be prompted to provide the correct username & password. The test was done with Windows Server 2003.



  208. Ed says:

    Its one thing to write an academic article about whether something is a security risk or not. Its another thing to remove a utility that thousands of people use because you’ve decided for all people that they dont need to use it after 12 years. If you were wrong for 12 years its possible that you are wrong now. Write your article and let the people decide for themselves retiring a program based on your own thought experiment is incredibly arrogant. Thanks Jesus.

  209. Jared Barneck says:


    About time someone debunked the newsid myth.  I challenged it in 2005 or 2006 and could’t find a reason for it but back then I was a nobody back then and I had not idea how to publish my results.

    I had never used newsid nor recommended it.  I did some serious testing when a customer told me they preferred it over Sysprep.  My testing show newsid wasn’t even needed.

    1. Create an image without sysprep.

    2. Depoy it to multiple machines.  

    3. Manually rename the machines (because you can’t have computers with the same name on the same network.)

    5. Join them to the domain.

    Test everything and nothing ever failed.

    Now, because Sysprep will fix the name and there are so many other features of sysprep, if anyone would rather use newsid over sysprep they aren’t really thinking it through.

  210. Jon Mennell says:

    Great Stir-up Mark !!

    Goes to show indeed that people don’t realy know their systems…

    I think general confusion occurs ragarding apps and the way they identify their clients (Nothing to do with the way Windows uses the SIDs).

    Apps likes SMS, WSUS, etc use an ID to uniquely identify clients. It is these IDs that when cloned cause problems, nothing much to do with the SID… If the SID is used as source for these IDs (as a factor, or as a whole), then changing the SID could automatically lead to a ID regeneration, and therefore problem solved, even if it isn’t a real SID problem.

    When imaging systems, even with Sysprep, Unique identifiers still have to be thouroughly inspected. Each app needing its own regisrty tweaks or file deletions (LanDesk needing the deletion of its GUID from the registry, for example, same thing with the SMS 2.0 GUID file, etc). There is a greater chance that if it is a Microsoft app, sysprep will do it for you…

    Many reactions to your great can of worms post are more deployment issues relating to duplicate IDs, not SIDs…

    The real question, therefore, is how do I (product vendor) generate an ID for my client ? Well, the SID is supposed to be unique – huh, well I’ll use that !! It’s not an SID issue as such but when AppID=SID, then things go horribly wrong in my app… Only solution = change SID…

    So the bottom line is most likely : to be safe, follow best practises & Sysprep. Also, know your apps !!!

    Thanks for your neat post !


    IT Trainer

  211. Robin Hood aka landaut says:

    Many times I see the new-born generation of "sys-admins" go too fast, too quick, too much "googling" and showing they know it all well. And none of them really have an answer when it comes to really deep problems that are just slightly different from their "google-paper". Because they often still lack the real internal & technology knowledge and do not wish to spend time studying enough on that. Pity for  those who are pointing with their comments at respected and longtime experienced guys, because they actually show their own lack of knowledge. As these longtime experienced guys  spent long hours really studying & testing/verifying on the why’s and how’s from software/operating-software systems ever since it was released.

    My advice is always: read and wonder why, then ask and/or read more and learn!

    The further we come, the more we discover how little we really know…

    @ Mark, again your work shows you belong among to the best & finest in this world of IT

  212. Roundy says:


    "Microsoft’s official policy on SID duplication will also now change and look for Sysprep to be updated in the future to skip SID generation."

    Would this update in sysprep to skip SID generation be an option? As you say, if you use a clone as the first DC in a domain you would want to create a new SID.

    "For the DC you want to create from a clone, create a unique installation or run Sysprep."

    If Microsoft completely remove SID generation from SYSPREP this could cause issues. Although I could use a scripted windows install for the first DC in a new domain.

    A very interesting article, it created a good debate in a usually docile office. It has also caused a lot of debate here, if not slightly misunderstood by some.

  213. Dean says:


       After trying to take all this in and now having my head swimming all I have is ONE question. If you yourself were an IT admin and had to roll out new workstations which method would YOU use. The image then sysprep method or the install from scratch method ( either by hand or by scripting, including all the applications and drivers). I know Vista and Windows 7 have the new WIM format but they also can be imaged ( cloned ) first and THEN be used in the Desktop Deployment Toolkit so the question is still valid for them.

  214. Ivar A says:

    Interesting read for sure.

    I’ve been using Ghost for cloning for the last 4-5 years, around 70 pc’s in the org. back then.

    When I was working out the procedures, I found Sysprep to be a major PITA to work with, and looked for other solutions. Then found and started using newsid.

    my procedure in short:

    1: install OS, update etc

    2: join domain, install software, do customizing, leave domain. Unplug network

    3: reboot as standalone

    4: make image

    5: load image to new pc, reboot, rename/newsid/run the F-secure ID regeneration util

    6: reboot, attach network cable, join domain

    Then figured out that everything ran just as good even if I forgot running newsid, so then i just skipped that step, 3 years ago.  

    The pc’s won’t connect to wsus until they’re joined the domain after cloning. And they’ll connect to the Antivirus policy server and create a new unique id.

    I would never clone Domain controllers etc without running sysprep/newsid

    So my findings correlate with Mark R’s, and it also makes sense to me that running Newsid can solve other id-related issues.

    But there’s one thing that got me thinking: Our accounting system runs on MSSQL and depends heavily on DCOM.(And sloppy coding – users have to run as admin! to ensure consistent running…)

    And we’ve had some strange trouble on some pcs while others been running fine. From some of the comments above, I think these issues may be SID related, intentional or not.

  215. Fredders says:

    As someone else stated I had problems when trying to setup an SQL enviroment and one would not be able to see admin account or similar on domain.

    What I allways did were removing the network adaptor. Upon restart it was installed again and voila new SID, I think, and then join the domain again…

    Think I left domain first, don’t remember… but the reinstall of network adapter were the point here!



  216. Bob Leithiser says:

    Earlier I posted about a computer not joining the domain with apparently a sid problem, but it turned out to be something else related to a network firewall issue, so I recant.

    But, I still think the newsid tool should be left hanging around a bit longer, based on some of the arguments on the blog.  Although, I understand the argument to not support it.

  217. alex says:

    Leave a comment ? Why ? I haven’t seen any answer from Mark to any of the comments already left here…

    On the other hand, exchanging experiences is always a positive thing.

    And the last paragraph on the article barely mentions WSUS, which others and I am interested in.

  218. Freedom I.T. Systems Limited says:

    Oh My!

    Stumbled upon this blog entry today, while checking to see if there was a new version available before I ghosted a few systems at a school and boy am I glad I did!

    Every since I started working in schools and then working for myself, I have always used NewSID. Like many others, it always seemed to fix problems that reared there ugly heads and it became part of my ‘Ghosting’ process. In fact, I have advised so many people to do the same and I now have to direct them to this blog to show the error of my ways.

    Anyway, I used SysPrep on a suite of 15 machines running Windows XP Pro SP3 after following this articles advice and it went nice and smoothly. Also, would you believe this fixed my problem with only one of the 15 machines ever showing up within WSUS.

    So end result is two problems fixed and probably a lot more besides – so once again thanks and I urge all of you who still use NewSID to dump it and use SysPrep – it only took me about 10 minutes to get used to the utility and without disregarding Mark’s hard work in the past, it does seem to do the job more comprehensively.

    Thanks again!

    P.S. Regarding some of the arguments about SIDS being important, yes they quite possibly are otherwise I would hope they wouldn’t still be lingering around, but who cares when the SysPrep tool assigns a new SID anyway if you ask it to. What is the problem?

  219. The Wanderer says:

    Apparently, the – or, at least, a – problem is that NewSID allowed people to change the SID after the system was already up and running, while sysprep has to be used before deployment time (and can mess up some installed software).

    Given that and my own experience, I would second the request from Nick Brown for a sysprep option to "just change the SID, do nothing else", alongside the option – or at least hopefully it would be an option! – to not change the SID at all. (I would also hope for a version of sysprep with this capability which is compatible with older versions of Windows, at least XP, but I’m not holding my breath over that one.)

  220. Larry says:

    ok Let’s do the check list.

    1. Ph’d check

    2. Microsoft fellow check

    3. Author of some the best windows books on the market. Check

    4. Developer of the software in question (by the way given away for free). Check

    5. On the Microsoft Core OS development team. Check

    Yep you guys are right and he is full of it.No wonder Wintel IT Admins are held in such high regard.  

  221. Andrew says:

    A couple people posted things suggesting that this article is wrong… not that many people will read all the comments, actually getting to and reading this one!  but..

    As per KMS where someone else already said that it uses CMID, which is not SID or some such thing.. The OP re: KMS said "problem with non-sysprepped systems" – indicating the problem with these statements, as someone else mentioned –

    …that MS still says to *use* sysprep, because it does other things that will cause some software problems if they are not done!

  222. Drac346 says:

    @MSDTCDCOMSQLNLB (ect) Posts

    MSDTC does not use the machine SID.  It uses an internal UUID that is created when the computer starts for the first time with MSDTC running (i.e. before it is cloned) (there is a TechNet article on this somewhere).  Most cloning software does not reset the MSDTC UUID Value (including Sysprep in an ESX VM Environment using the default sysprep options).  You can verify this yourself by performing the following in a test environment with the issue (clusters are slightly more complicated but SQL connections are simple between two cloned servers with MSDTC installed prior to the cloning job):

    1)from a command line: MSDTC.EXE -Uninstall


    3)from a command line: MSDTC.exe -Install

    This will fix your ‘SID’ like issues with MSDTC.  We have had 100% success using the method for SQL errors in a cloned VM environment.  The same should be true for all components that use MSDTC.

    We had to update all of our cloned VM systems by removing MSDTC and reinstalling it where applicable (no other changes were needed to other applications).  We also removed it from our master clone and scripted the install during a run once command.  We have never seen the issue return and we have never run any re-SID on the servers.

    The issue above with SQL only arrived when we needed multiple servers to talk to a single SQL server using MSDTC.  There are no issues with our XP workstations using the same UUID to connect to the SQL server since the clients came from a different image; the UUID is already different from the server.

    Please let me know if someone else has experienced otherwise (with details please).  But the ESX (v3.5U4) flags for Sysprep did not reset the MSDTC UUID across images which utilized SysPrep and still generated ‘identical SID’ errors in the event log for MSDTC.  Reinstalling the service is what fixed the internal UUID problem (also documented in a technet article I can no longer find). Setting different SysPrep flags might be another solution during the clone template function.

  223. Myles Pearson says:


    Mark, I am glad that you did the research and found this out. I am also very glad that there are so many people out there that are passionate about this topic. If the reader goes through this thread completely, they definitely will come away with a better understanding of how these identifiers work.

    Great post!

  224. Siim says:

    Even though NewSID was mainly used to generate new unique SID-s, there is need to be able to set specific (cloned/duplicate) SID for an installation. For example, in order to save EFS keys from no longer bootable system (e.g. due hardware failure without replacement available and system not bootable in virtualised environment), one needs to create an installation with identical SID, user identifiers and passwords in order to gain access and decrypt/export the users EFS keys (which are required to access EFS encrypted files on the disk). This is a scenario, where sysprep can not help and NewSID is the only "semiautomated" solution. Thus, retirement of NewSID is premature as it still has valid (and critical, though rare) use cases. It might be an option to create a data recovery helper tool specifically for setting machine SID and user account identifiers without the random ID generation feature to discourage using this tool in production environments.

  225. ML49448 says:

    Can you please add this comment you made to the main post:

    "It appears many readers are confusing machine-specific state, computer Domain SIDs, and machine SIDs …"

    I’m not a trained systems administrator but have helped out people with small networks so all of this is very helpful to me. Thanks for posting this.

  226. Martyn James says:

    Consider users at home – many machines are never added to a domain.

    Now consider that these users are apt to change their machine name occasionally.

    Now imagine you’re a cloud vendor that needs to identify each machine associated with a user’s account that is faced with multiple machines named "Jane’s Computer".

    How else do you know which machine is which? Do you trust the user? (Did I mention they were users at home?)

  227. Kiran says:

    First, I have to admit, that when i saw this post back in oct. i was shocked as the rest of you. I trust Mark’s words to the "T" on everything, but in this case my years of experience with Windows begs me to differ and contest Mark’s findings.

    The new for unique SID can be demonstrated easily with the use of Vmware workstation or such. Take a VM image of 2003 or 2008. Make two linked clones. login to one of them, use dcpromo and make it the first DC in a new domain. get onto the second one, and join it into the domain. reboot. now try to login to the domain from the second machine, and it will not work, and will complain of domain ID problems.

    use newSID on the second machine and add it to the domain. Everything works flawlessly.

  228. aaron says:

    In December, I posted a long comment about how NewSID has helped us and fixed many problems but it was never posted here. I did read the entire posting and there may have been some similar parts of my post but it was detailed to help others. I am disappointed that it was not posted.

    I guess at this point we all would like to know what the verdict is: Mark will continue updating NewSID stating it is not needed and letting the end user decide to use it or not. Or will the windows community have to turn to 3rd party utilities to save them time and money ??

    I feel that if NewSID is not needed then I will not use it in my cloning. However using it to fix problems where a SID change is needed or required to fix a problem the program should be available. The use of NewSID in ESF recovery (I have been there many times) is a God Sent. Server issues: there is no way I want to spend 10 days rebuilding a proprietary server just to change the SID because some Junior Admin did his part wrong, or the company out sourced the OS load and you don’t know you have and issue until it is too late. NewSID has save me many thousands of hours. I would hope that Mark would want to continue to help the Admin Community no matter how they use NewSID.

    Mark thanks for all your hard work, your free software and the many articles and books you have written. They have helped me immensely over the years. I hope you will continue to update NewSID.

  229. Kiran says:


    I must apologize. I overlooked that part. But before that please accept my kudos for responding back. You clearly are better at managing time than me.

    I’m still sure that I faced many strange problems. I’ll work on trying to replicate those problems and post back.

  230. jmt says:


    if I read you correctly (I tried), the real underlying problem is the encoding of a ‘useless’ (or more precisely a ‘uselessly complex’) value in the local user SIDs. Seems a fixed machine part like ‘S-1-5-10’ would fit anyway. If it doesn’t need to be unique, why just not use a known value, like for the predefined accounts?

    Then the system would check for local accounts by comparing the RID-less part to that special prefix instead of the machine SID. Changing the machine SID would then become a simple matter.

    Hope I didn’t overlooked deeper problems.

  231. Robert Baker says:


    I took me just under 2 hours to read all the comments and to follow and read most of the embedded links.  It has enlightened me as to the root cause of many of the issues encountered when ghosting domain members/controllers in our labs.  This is just a rehash and possibly not worth the posting time, but these are the key points I found after digesting the information.

    1) Always use sysprep before making an image for deployment to reset other identifiers and machine state.

    2) Retrieving data from EFS with the original owner’s assistance is pretty much the only valid use for newSid.  This is why Bit-Locker should be used for encryption.

    3) "SIDs must be unique within the authority in which they are used" –

    Third party apps that use the MachineSID to identify a machine within a larger grouping need their own ID; MachineSID is only guaranteed to be unique within their authority which is the local machine.

    Of course, these generated id for a machine must be unique across the third-party’s grouping of machines (WSUS IDs, SMS IDs, NLB GUIDs)… similar to an Active Directory DomainSID.

    4) MSDTC also has an ID, the CID, which is not related to MachineSID and it is generated the first time MSDTC runs.

    Best practice is to install MSDTC after cloning or use a startup script to execute well documented procedures to solve this issue.

    5) A machine that has been added to a domain will have a DomainSID.  The machine must not be imaged at this point for use in creating other domain member machines.

    6) The Active Directory SID is the MachineSID of the very first DC used to create the Domain.  You may not re-use this SID within the domain or for other domains that need to communicate with the first domain.  

    7) If you have a local machine user account with the same username and password (ie Administrator) you have a security hole that has nothing to do with SIDs.

    Thanks for kicking off this awesome discussion.

  232. Darragh O'Shaughnessy says:


    I total;ly agree with you. I still run sysprep on all my images but as you stated, to clear out state specific entries for apps and not the machine SID. It’s amazing how many people re-count tales of newsid saving their bacon without being able to give any technical detail about how! Its funny really as you wrote the darn thing yet they seem to forget that! For my part i have never seen an app that uses the machine sid. Mark, continue the great work. Excellent blog as always. You’re a credit to the inducstry. 😉

  233. Darragh O'Shaughnessy says:

    Hey mark, just 1 question..

    Was this just a design choice? Your point is  that SIDs must be unique within the authority in which they are used. So obviosuly, domain sids need to be unique in the domain. Did the original designets just then extend that to the machine side to keep the logic the same and the indentifier format  i.e. the SID s-x-xx-xxxx etc. the same?

  234. Brian says:


    Thanks for the great article.  One quick question – We’re currently running a Windows 2000 domain, and about to upgrade to 2008 R2.  We have several servers (VM’s) that have duplicate SID’s (none of them are DC’s).  I couldn’t find any reason in reading your article why this would be a problem, but I was wondering if there is any chance for an issue with these machines when we do our upgrade.


  235. Jared Barneck says:

    I spent years doing Level II and Level III tech support for LANDesk specifically doing Operating System Deployment and imaging.  In this time I found that software apps such as VPN software and including our LANDesk agent have unique values too.

    You know what is needed now, is a plugin capability for Sysprep that vendors can use so when their software is installed, and Sysprep is run.

    A vendor oculd let sysprep know about their software specific uinique values so that when sysprep runs, the plugin somehow informs sysprep of these files, registry, etc… So then sysprep can start handling the unique values of other pieces of software as long as those other vendors take time to write a sysprep plugin.

    The plugin would install with the software, maybe add a registry key that sysprep would look at and it would delete every file, registry key, or maybe run a custom command the vendor provides (in case something complex is required) and sysprep would then do it.

    I know if such a plugin capability existed, LANDesk would integrate with it right away.

  236. Vera says:

    Dear Mark,

    I got to this post looking for SID details because a friend told me that he solved a Skype problem using newSID.exe.

    If you have cloned machines with the same SID at the same network, Skype cannot communicate well. For example you can communicate with one contact but it fails with another. Simply run newSID.exe to correct.

    I have a similar problem with Cybera (Cyber Cafe Administration)

    Some client machines were created from the same image and Cybera stores each Cybera client MAC address, machine ID and SID at Cybera´s Server Windows registry.

    Cybera server crashes when we turn on two or more machines with the same SID and works well if only machines with unique SIDs are connected.

    Somehow SID really affects these applications.

    Congratulations for your work!

  237. MP says:

    ROTFL about so many people feeling so strongly about something they obviously don’t understand and didn’t even bother to read the full article (or couldn’t comprehend it).

    Please, please tell me none of you ignorant ones are on my IT staff!

  238. Bob Hyatt says:

    Thank you Mark for your info on Machine SIDs. I have been a user of NewSID for several years now. (Win XP) After reading ALL the responses to your article it is CRISTAL CLEAR that the real problem here is not whether Machine SIDs or any other SID can exist in duplication with out creating errors it is that SYSPREP was VERY BADLY written  with no real understanding of the needs of the communities it is meant to be used in. The bottom line is this… We, IT support who need to deploy Windows systems, need to be in TOTAL control. We need to have a way to create an MASTER image and deploy it WITHOUT A SINGLE CHANGE, except the obvious i.e. Name of PC, the OS keycode for non Enterprise version of the OS, Join a domain on the fly (not needed but would be nice add on) and generate new SIDs, GUIDs or what ever MS say’s MUST be unique to each system and NOTHING ELSE BY DEFAULT, let me repeat that last bit BY DEFAULT!!!!! NO changing of the Admin profile or account, NO OVERWRITING of the default profile we put so many hours in to creating JUST THE WAY WE WANT IT, NO destroying the Administrators’ profile which we, once again have put many hours in to tweaking JUST THE WAY WE WANT IT, no turning on or off ANY settings of any kind etc. These two profiles MUST NEVER BE BASED ON EACH OTHER. They have TOTALY different uses!!!!!! Per MS design. DUH. SO WHAT IS MS DOING MIXING THEM UP? Why being their usual arrogant "we can do no wrong" selves as usual. In fact I bet that they won’t even read your blog, nor even vaguely consider the obvious need for a SYSPREP or similar utility that WILL NOT change my IMAGE except where obviously needed as stated above. If I am wrong about MS then here is their opportunity to prove it by admitting in public that they have COMPLETELY missed the boat on the needs of the customers and that before they do anything else they will IMEDATLY rewrite SYSPREP. If they had done this from the start, NewSID would have never been needed and would not now still be needed for Windows 7 etc. and ITs would not need to haggle over whether duplicate SIDs are or are not a problem.

    So Mark, please respond AS AN MS representative on the subject of the NEED and the MS response to that need for a new version of SYSPREP. If they need help in laying out how it needs to work I am available for consultation and I guarantee you I will not sign off on anything that does not truly fix the problem and is as simple to use as checking or unchecking about 5 to 10 different check boxes before "sealing" the image for cloning. I figure that I could direct the team who wrote the current SYSPREP to modify the current version to do what it should have always done in about 5 days. It should not be rocket science to throw in a few check boxes and via them jump over the parts of SYSPREP that are screwing up all the images and messing with settings that SHOULD NEVER have been messed with in the first place. And this is really all DUH stuff that I am talking about. So what say yee Mark? Do I make sense? What does the Windows Team say now?

  239. DK says:

    Thanks for that great write up. Though, I’m mainly suprised people are just figuring this out now. Although I use sysprep routinely, I’ve also deployed ghost images that weren’t sysprep’d, and have never had an issue with SID duplication. Still better to dot the ‘i’s and cross the ‘t’s though. Things are always changing, and you never know when non-conformity might bite you in the end.

  240. bill says:

    @Bob +1 – Thank you for agreeing with me and 90% of the Corp world, MS for got about the Corp World years ago. I have tried and tried to get a hold of someone a MS that will fix this; if SYSPREP worked correctly there would be no need for Ghost or other imaging software. But MS always over writes your settings. We have policies on how things MUST be so we change the Default Profile and the Admin profile. But SYSPREP over writes those changes, so we have to use Ghost and NewSID or some other SID Changer. (I guess we don’t need to NewSID now). But please fix SYSPREP. Thanks!!!

  241. WhisperingChaos says:

    Mark I’m grateful to you for explaining SIDs (Machine & DC) in both a direct and easy to comprehend style.  I also appreciate the efforts of other posters who provided comments, thereby permitting me to gain experience without its pain. After reading your post, I understand the Machine SID remains encapsulated within the executing OS (authority) and isn’t used by, at least Microsoft, as an interface between remote processes.    However, there are instances mentioned in the reply posts where third party tools seem to rely on unique SIDs, as well as the vulnerability of NTFS formatted thumb and external drives

    In addition to these situations, I’d like to catalog two other concrete examples where a unique machine SID would improve security.  These situations reflect the same vulnerability as would an NTFS formatted thumb drive – more than one authority directly manages/employs the machine SIDs.  They are:

    • A multi-boot computer.   This machine configuration explicitly defeats the machine SID encapsulation constraint, as each OS manages (but not concurrently) the NTFS ACLs of all drives physically attached to the machine.   When building machines, I generally create a base image that includes a number of diagnostic utilities.  This base image becomes a “Diagnostic” partition and evolves to become an end user’s “Primary” partition.  These cloned partitions not only share the same Machine SID they also explicitly share, at least when first cloned, the same Account SIDs.  Finally, since generating an RID involves simply incrementing the last one assigned, this mechanism easily generates overlapping Account SIDs between the different partitions.

    • A situation where a drive is physically removed from one computer and installed into another where these computers were all cloned from one image and not SysPrep(ed)/NewSID .  For example, pretending to work late one evening, a disgruntled employee decides to remove his manager’s hard drive and install it to his own computer.  If this employee happens to know the password for the local administrator account (which might not have one), have the same local Account SID, or generate the same SID as the manager (by adding accounts to his image), the employee would not need to know his manager’s password and could then read/delete his manager’s files.

    The situations above are not common, nor do they contradict Mark’s assertion.  However, having a tool like NewSID would help to better secure the file system from casual attacks.  Then again, having an easy to use tool like NewSID introduces the same vulnerability it was intended to solve….

  242. lucky says:

    @ bahbar.  The Local SID is used for Local Authentication to local resources on that Installation only.  For example.  If a machine does not participate in a Domain then the Local SID is important when logging in, performing privileged tasks etc.  In this environment if you have two systems with the same SID it will not cause issues because no one machine knows about or can utilize any other machines local SID for authentication. So being the same or different is of no concern to the systems.  

    In a Domain all access is handled at the Domain SID level, and this SID is generated by a DC at the time a machine is added to a domain and is based on the DCs SID. This SID is also unique to each machine in the domain.  These SIDs are independent of the Local SID on a member server or workstation.

  243. tama says:

    I feel sort of vindicated by this.  I've never used sysprep with xp and altiris, and used the same image with multiple machine types.  But now sysprep seems to be a way to get the hard drive signature and sector offsets out of the BCD with Windows 7.  I'm thinking of using sysprep, but it comes with a lot of other baggage.

  244. Ben Lotan says:

    that's right. i figure out that like mark said there is sid for windows update.

    here is a script that regenerate the sid for the wsus server (more importent from my point of view)

    put it in a .bat file


    net stop wuauserv

    reg delete "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v PingID /f  > %systemdrive%SUSClientID.log 2>&1

    reg delete "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v AccountDomainSid /f  >> %systemdrive%SUSClientID.log 2>&1

    reg delete "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v SusClientId /f  >> %systemdrive%SUSClientID.log 2>&1

    net start wuauserv

    wuauclt.exe /resetauthorization /detectnow  


  245. MC9 says:

    I think you should reconsider and come out with a new version even though I’m sure like everything else to do with Windows it will be more painful than ever to get it working right. The point is, too many 3rd party apps have the SID buried here and there, I’m working for one right now in fact that has it buried in a couple of SQL server tables. Even if you release a new version I know it won’t be able to touch anything in these tables, however, what’s clearly obvious is the usage of this as some unique identifier over the years has become widespread and right or wrong a tool to change it or match up an old one for a migrated db for instance is useful, in some cases vital.

    On the sysprep side of things I can’t blame people who’ve apparently used newsid as some kind of shortcut. Since Vista arrived on the scene sysprep and windows deployment turned into shambles. I myself have come to grips with sysprep and have avoided newsid through the transition however I’ll never get those months of time back from the WAIK and MS forums, test deployments with VMs etc… it really is a terrible pain compared with XP / 2003.  Frankly I don’t know what MS is thinking anymore, they’ve lost their way in some critical areas, obviously lost a lot of people from the early days

  246. Ata says:

    Great article Mark, i learned now that computer sids are good for nothing, but this didn't changes

    anything. We must use sysprep after cloning just before, but for other reasons. Maybe there is a chance,

    that there will be a button in windows with [Change SID]?  ……..

    I am just kdding, i am really impressed.

    best regards


  247. davide says:

    Hi Mark have you got an explanation to this wierd psgetsid behaviour?

    i have 1 active directory domain (CONTOSO) with 1 domain controller DC01 and 1 Exchange server EX01:

    psgetsid "CONTOSODC01$"

    SID for CONTOSODC01$:


    psgetsid \DC01

    SID for \DC01:


    psgetsid "DC01"

    SID for DC01DC01:


    psgetsid "CONTOSOEX01$"

    SID for ategrantsv-ex01$:


    psgetsid \EX01

    SID for \EX01:


    psgetsid "EX01"

    SID for EX01EX01:



  248. claymanscher says:

    I'm a year late to discover this post, and I took the time to skim through the multitude of comments, so hopefully I'm not being redundant here.

    I work in a Novell-centric environment where all Microsoft networking services are disabled, so SIDs never have been an issue for us. However, we've found SID changers useful for renaming computers immediately after imaging, without having to boot them up to do so, so I wouldn't call NewSID "useless." Anything that saves the tech a reboot cycle is worthwhile.

    We're currently using it in a script to ensure that each installed copy of a VM has a unique name that incorporates the name of its host but has additional characters to identify its purpose. How could we ever script such an operation without a utility like NewSID? It's more than just a SID changer; it's a scriptable renamer, which makes it a valuable tool in its own right, SID or no SID.

    I also noticed a couple of comments about having to uninstall Trend OfficeScan before cloning. This has nothing to do with machine SIDs; it's a separate GUID that Trend creates when the Trend client connects to its server for the first time. Trend has a utility called ImgSetup that you can run on the system before imaging so that a new Trend GUID will be created when the clone boots up. Admins can obtain ImgSetup from their own Trend server, as described here:…/Deploying-OfficeScan-80-clients-using-disk-imaging.aspx

    Probably the people who could use this information won't be back here, but I'm offering it anyway FWIW.

  249. itsme says:

    I made a respectful comment some while ago on this blog suggesting that if Sysinternals were still independent from Microsoft, NewSID would have been updated instead of retired.  For some reason that post never showed up here.  I find it interesting that type of post would be censored here.

  250. cpmin says:

    I have to disagree with this completely. In fact, some of the labs in the Microsoft Exam prep for 70-642 are not possible if you are using virtual machines from a clone unless syspreped. After experiencing the problem with the labs I ran into it on a customer network. In the lab as well as at the customer, the member server was not able to resolve local machine security groups for use on file/folder or other security permissions. After syspreping the VM the problem went away both in the labs as well at the customer site.

  251. Kevin says:

    Mark, please don't even bother to publish comments like cpmin's, who obviously did not read the whole article or any comments regarding sysprep.  There were LOTS of them.

    And thank you for this article.  It has helped clear up a lot.  We just imaged about 700 machines using MDT, and some I used the setup process with, some I didn't.  None were joined to the domain.  It's comforting to know it won't be an issue, and we don't use WSUS.

  252. Jani Anttila says:

    Hi Mark,

    Your post helped me to understand one very important thing. I also wrote my first blog post about it. You can read it from…/virtual-machine-cloning-and-sysprep

  253. Joaoma says:

    Hi Mark,

    Just a correction for the blog post. the WSUS still requires a manual process to remove its own entries even when sysprep is used.…/903262

  254. Drewfus says:


    suppose files or folders on removable media were ACLed with the SID-RID of a local user. The machine is then reimaged or Windows setup is rerun after formatting %systemdrive%. The machine now has a different SID, at least in the latter case, and the user represented by SID-RID can possibly no longer access the files on the removable drive. Isn't this a case where cloning of SIDs is not only a non-problem, it's actually *desirable*? Furthermore, wouldn't it also be desirable for that same user to receive the same RID on the rebuilt system as they had previously? Is a mechanism required for this? I know RIDs on a local system are allocated sequentially, but would some mechanism for matching new accounts to a prefered RID be beneficial?

    > net user username password /add /matchrid:@Users-RIDs.txt | \MasterBrowser

    That is, get the RID from a file that associates usernames with RIDs, or compare username to the same name on another computer in the workgroup.

  255. Fred Peterson says:

    I'm amazed people keep bring up 3rd party software, even if that 3rd party software is WSUS or some other Microsoft software.

    Mark's original post is commenting only with regard to the functionality of Windows the operating system.  In frank words, he could give a flying rats ass about add-on MS or 3rd party software functionality and requirements – he wasn't commenting on that.

  256. Veldrik says:

    Hi Mark, and everybody else.

    Firstly I want to thankyou for taking the time and writing this article.

    Secondly, I have a request that if at all possible, could you please provide a link to an archived version of newsid.exe 4.1?

    The situation I have come across is that a customer has around 1500 XP machines, that due to the seclection of a particular third party vendors management software (goal is a win7 upgrade), require each machine have a seperate windows SID.  I've hunted down the architects for that product, and they confirmed that duplicate SIDs cause issues as the software running on each client, and the inventory management server use this information…

    Currently the easiest solution is to change the SID, however syspreping the windows xp machines will cause alot of issues with other legacy software being used.



Skip to main content