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.

 

SIDs

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

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  An attempt to explain the distinction between the machine SID and the computer account SID in a domain: http://blogs.msdn.com/aaron_margosis/archive/2009/11/05/machine-sids-and-domain-sids.aspx

• Anonymous
  January 01, 2003
  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. References: User Community procedures for updating the MSDTC CID:  http://blog.wadewegner.com/index.php/2007/08/13/warning-the-cid-values-for-both-test-machines-are-the-same/ Microsoft Support Procedures for reinstalling MSDTC on Server 2000 (very similar in 2003): http://support.microsoft.com/kb/867520 Microsoft MSDTC Troubleshooting tools (which would have correctly identified your problem as a CID issue): http://support.microsoft.com/kb/918331 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) , http://msdn.microsoft.com/en-us/library/aa561924(BTS.20).aspx @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?

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  @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?

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  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. George

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  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.

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  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.

• Anonymous
  January 01, 2003
  @Stephen: Thanks!

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  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).

• Anonymous
  January 01, 2003
  @Martin Zugec: I've updated the text to make the distinction between machine SIDs and computer Domain SIDs more clear.

• Anonymous
  January 01, 2003
  @lyle: Again, this is a case of other unique per-machine state, not the machine SID, causing a problem - state that Sysprep resets: http://support.microsoft.com/kb/931265

• Anonymous
  January 01, 2003
  @Itsme Sorry, but you're incorrect.

• Anonymous
  January 01, 2003
  @Timothy: yes, with the exception that machine SIDs are used as the basis for Domain SIDs, machine SIDs could have been a constant.

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  @prb, @FillDee - Thanks for taking the time to read the article and the comments and thanks for the feedback.

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  @jared barneck Sysprep has always included a provider model for third-party applications: http://technet.microsoft.com/en-us/library/ee676646(WS.10).aspx

• Anonymous
  January 01, 2003
  @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.

• Anonymous
  January 01, 2003
  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.

• Anonymous
  November 03, 2009
  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 ?

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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?

• Anonymous
  November 03, 2009
  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!

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  Better check with the KMS guys. We've had a problem with non-syspreped imaged computers and KMS.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  @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.

• Anonymous
  November 03, 2009
  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 )

• Anonymous
  November 03, 2009
  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? Aaron

• Anonymous
  November 03, 2009
  Great Mark! "Obvious" things are abvious because nobody ever asked "why?" strong enough. Now you did!

• Anonymous
  November 03, 2009
  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.. comments? thanks!

• Anonymous
  November 03, 2009
  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, Gabriel

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  Xcellent post Mark !! Really impressed with your article. Cheers' Vijay

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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. Martin

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  @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: http://support.microsoft.com/kb/929829

• Anonymous
  November 03, 2009
  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...

• Anonymous
  November 03, 2009
  Then why is there a clean up method with ntdsutil for duplicate SID?

• Anonymous
  November 03, 2009
  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??

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  @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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  "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.

• Anonymous
  November 03, 2009
  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?

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  @Dean 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.

• Anonymous
  November 03, 2009
  There still is a problem with duplicate SIDs. http://support.microsoft.com/kb/828258 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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  Mark, 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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  Excellent post, Mark.  Your research has answered some questions I didn't even realize I had.

• Anonymous
  November 03, 2009
  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: NODE1adminaccess NODE2adminaccess ....with full access to the shared storage. Then I go and make a few service accounts with limited access to a few directories: NODE1limitedaccount NODE2limitedaccount 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?

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  Mark, 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! Adam.kf

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  Is any regression testing going to be done and reported? Thanks for the informative article!

• Anonymous
  November 03, 2009
  Mark, 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.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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. Burt

• Anonymous
  November 03, 2009
  The comment has been removed

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  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)

• Anonymous
  November 03, 2009
  I commend your ability to turn your scrutiny upon your own assumptions and then broadcast the results.

• Anonymous
  November 03, 2009
  @Scott: That's a domain SID issue, not a machine SID issue. Different problem.

• Anonymous
  November 03, 2009
  WSUS generates and uses SUSClientID to uniqly identifiy WSUS clients. Machine SIDS are not.

• Anonymous
  November 03, 2009
  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.

• Anonymous
  November 03, 2009
  "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.

• Anonymous
  November 03, 2009
  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 http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx 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?

• Anonymous
  November 03, 2009
  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 -Yozwar

• Anonymous
  November 03, 2009
  @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).

• Anonymous
  November 03, 2009
  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)

• Anonymous
  November 03, 2009
  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. http://blogs.msdn.com/richardbpi/archive/2006/05/19/601898.aspx I've seen this to, and the only solutions seemed to run newsid AND reinstall the DTC.

• Anonymous
  November 04, 2009

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.

• Anonymous
  November 04, 2009
  "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.

• Anonymous
  November 04, 2009
  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?

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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,

• Anonymous
  November 04, 2009
  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?

• Anonymous
  November 04, 2009
  I would ask the SMS guys inside Microsoft... We have had incidents with SMS and duplicate SIDs.

• Anonymous
  November 04, 2009
  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 :/ DS

• Anonymous
  November 04, 2009
  @Scott That's because you have a duplicate Domain SID.  Domain SIDs are completely different to Machine SIDs.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  @ #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.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  Mark, 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! Thanks! Pete Downing

• Anonymous
  November 04, 2009
  Mark, 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.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  "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.

• Anonymous
  November 04, 2009
  Mark, I think you have made some mistakes. Many people on Slashdot disagree: http://tech.slashdot.org/story/09/11/04/0040203/The-Machine-SID-Duplication-Myth 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: http://tech.slashdot.org/comments.pl?sid=1430036&cid=29977210

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  For more information about the problem of duplicated SusClientID: http://support.microsoft.com/kb/903262 Machine's SID definitly has nothing to do with WSUS.

• Anonymous
  November 04, 2009
  "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?

• Anonymous
  November 04, 2009
  @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.

• Anonymous
  November 04, 2009
  So why do all domain controllers have the same SID? What's the purpose for that?

• Anonymous
  November 04, 2009
  @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.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  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: http://KB.UltraTech-llc.com/?File=SID.TXT -ASB: http://xeesm.com/AndrewBaker Providing Competitive Advantage through Effective IT Leadership

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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?

• Anonymous
  November 04, 2009
  Once again Russinovich schools us all.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  Mark, 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.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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.  

• Anonymous
  November 04, 2009
  Microsoft SQL replication also does not work when machines have the same SIDs

• Anonymous
  November 04, 2009
  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.  

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  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) Joe

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  Hey Mark..  Did you open a can of worms or what???

• Anonymous
  November 04, 2009
  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 :>

• Anonymous
  November 04, 2009
  Perhaps you should offer $1000 to the first person to publicly report a verifiable problem with a machine with a duplicate SID? =)

• Anonymous
  November 04, 2009
  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. Kudos. -Brian

• Anonymous
  November 04, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 04, 2009
  I sometimes clone test VMs and run DCPromo on some of them. So basically I still need this tool.

• Anonymous
  November 04, 2009
  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.

• Anonymous
  November 05, 2009
  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.

• Anonymous
  November 05, 2009
  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.

• Anonymous
  November 05, 2009
  I wonder if duplicate machine SIDS impact any forensic considerations?

• Anonymous
  November 05, 2009
  The comment has been removed

• Anonymous
  November 05, 2009
  The comment has been removed

• Anonymous
  November 05, 2009
  The comment has been removed

• Anonymous
  November 05, 2009
  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.  

• Anonymous
  November 05, 2009
  Interesting that Microsoft own Core Team just posted a blog entry contradicting this:  http://blogs.technet.com/askcore/archive/2009/10/16/kms-host-client-count-not-increasing-due-to-duplicate-cmid-s.aspx

• Anonymous
  November 05, 2009
  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.

• Anonymous
  November 05, 2009
  The comment has been removed

• Anonymous
  November 05, 2009
  The comment has been removed

• Anonymous
  November 05, 2009
  @Mark - Please ignore my comment from 11/3/09. I was getting my machine GUID and SID mixed up :D

• Anonymous
  November 05, 2009
  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

• Anonymous
  November 05, 2009
  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!

• Anonymous
  November 05, 2009
  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" Thanks, Abraham

• Anonymous
  November 06, 2009
  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)

• Anonymous
  November 06, 2009
  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'.

• Anonymous
  November 06, 2009
  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.

• Anonymous
  November 06, 2009
  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.

• Anonymous
  November 06, 2009
  Hi, 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 ? Regards, rajender Saini

• Anonymous
  November 06, 2009
  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 ;-)

• Anonymous
  November 06, 2009
  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.

• Anonymous
  November 06, 2009
  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. Chris

• Anonymous
  November 06, 2009
  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. :D 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. Chris

• Anonymous
  November 07, 2009
  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

• Anonymous
  November 07, 2009
  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.

• Anonymous
  November 07, 2009
  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.

• Anonymous
  November 07, 2009
  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.

• Anonymous
  November 08, 2009
  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.

• Anonymous
  November 08, 2009
  @James Keep in mind that sysprep is the only supported way from Micorosft to change the SID,also in Windows 7. http://support.microsoft.com/kb/162001 So you maybe have to change your way of image preparation/deployment.

• Anonymous
  November 08, 2009
  A member server can not login DC with the same SID. I always use NewSID to change my Virtual Machine SID before dcpromo.

• Anonymous
  November 08, 2009
  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.

• Anonymous
  November 09, 2009
  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:

• Anonymous
  November 09, 2009
  @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.

• Anonymous
  November 09, 2009
  I have found in the past that MSDTC cannot communicate between two machines that have the same local SID. ??

• Anonymous
  November 09, 2009
  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.

• Anonymous
  November 09, 2009
  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.

• Anonymous
  November 10, 2009
  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 Regards

• Anonymous
  November 11, 2009
  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.

• Anonymous
  November 11, 2009
  The comment has been removed

• Anonymous
  November 12, 2009
  According to http://technet.microsoft.com/en-us/library/cc755427%28WS.10%29.aspx 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.

• Anonymous
  November 12, 2009
  The comment has been removed

• Anonymous
  November 12, 2009
  The comment has been removed

• Anonymous
  November 12, 2009
  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.

• Anonymous
  November 13, 2009
  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(http://forums.techarena.in/windows-server-help/889459.htm) but it also shows that maybe without NewSID I have fewer problems. Next time I try cloning without NewSID.

• Anonymous
  November 13, 2009
  The software company "Stardock" (www.stardock.com) Uses SIDs as a form of software protection to their software!!

• Anonymous
  November 13, 2009
  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.

• Anonymous
  November 13, 2009
  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. Thanks!

• Anonymous
  November 13, 2009
  The comment has been removed

• Anonymous
  November 13, 2009
  I used to refer our users to this article (currently unavailable, but thanks to archive.org, 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...) http://web.archive.org/web/20070212020819/http://appdeploy.com/articles/sids.shtml

• Anonymous
  November 14, 2009
  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. or
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).

• Anonymous
  November 15, 2009
  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.

• Anonymous
  November 16, 2009
  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.

• Anonymous
  November 17, 2009
  @Ares Apostol "The software company "Stardock" (www.stardock.com) 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 :-)

• Anonymous
  November 17, 2009
  Mark, 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.

• Anonymous
  November 18, 2009
  The comment has been removed

• Anonymous
  November 18, 2009
  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 http://support.microsoft.com/kb/931265.  Any chance you could repost that link? Thanks

• Anonymous
  November 18, 2009
  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?

• Anonymous
  November 18, 2009
  The comment has been removed

• Anonymous
  November 19, 2009
  The comment has been removed

• Anonymous
  November 19, 2009
  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.

• Anonymous
  November 19, 2009
  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?

• Anonymous
  November 22, 2009
  The comment has been removed

• Anonymous
  November 23, 2009
  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). http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=38

• Anonymous
  November 23, 2009
  Mark, 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. Burt

• Anonymous
  November 24, 2009
  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. Cheers, Leo

• Anonymous
  November 25, 2009
  The comment has been removed

• Anonymous
  November 27, 2009
  Mark, 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.)
4. 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.

• Anonymous
  November 28, 2009
  The comment has been removed

• Anonymous
  November 29, 2009
  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

• Anonymous
  November 29, 2009
  @Mark: "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.

• Anonymous
  December 01, 2009
  The comment has been removed

• Anonymous
  December 01, 2009
  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 wininternals.com 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.

• Anonymous
  December 11, 2009
  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! Regards Fredders...

• Anonymous
  December 11, 2009
  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.

• Anonymous
  December 13, 2009
  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.

• Anonymous
  December 16, 2009
  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?

• Anonymous
  December 16, 2009
  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.)

• Anonymous
  December 17, 2009
  The comment has been removed

• Anonymous
  December 20, 2009
  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!

• Anonymous
  December 22, 2009
  The comment has been removed

• Anonymous
  December 27, 2009
  @markrussinovich 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!

• Anonymous
  December 29, 2009
  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.

• Anonymous
  December 31, 2009
  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.

• Anonymous
  January 01, 2010
  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?)

• Anonymous
  January 06, 2010
  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.

• Anonymous
  January 06, 2010
  The comment has been removed

• Anonymous
  January 07, 2010
  Mark, 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.

• Anonymous
  January 15, 2010
  Mark, 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.

• Anonymous
  January 19, 2010
  The comment has been removed

• Anonymous
  January 19, 2010
  Mark, 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. ;)

• Anonymous
  January 19, 2010
  The comment has been removed

• Anonymous
  January 21, 2010
  funny in light of this blog: http://windowsitpro.com/article/articleid/14919/what-are-the-problems-with-workstations-having-the-same-sid.html

• Anonymous
  January 29, 2010
  Mark, 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. Thanks.

• Anonymous
  January 30, 2010
  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.

• Anonymous
  February 12, 2010
  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) www.sourceforge.net/projects/cybera 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!

• Anonymous
  February 16, 2010
  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!

• Anonymous
  March 04, 2010
  The comment has been removed

• Anonymous
  March 05, 2010
  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.

• Anonymous
  March 29, 2010
  @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!!!

• Anonymous
  April 13, 2010
  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….

• Anonymous
  June 03, 2010
  @ 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.

• Anonymous
  June 25, 2010
  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.

• Anonymous
  August 10, 2010
  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   

• Anonymous
  August 25, 2010
  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

• Anonymous
  September 03, 2010
  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 Ata

• Anonymous
  September 20, 2010
  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$: S-1-5-21-3593370919-795868457-2976776762-1000 psgetsid \DC01 SID for \DC01: S-1-5-21-3593370919-795868457-2976776762 psgetsid "DC01" SID for DC01DC01: S-1-5-21-2334179199-2593070578-4289130869 psgetsid "CONTOSOEX01$" SID for ategrantsv-ex01$: S-1-5-21-3593370919-795868457-2976776762-1103 psgetsid \EX01 SID for \EX01: S-1-5-21-3593370919-795868457-2976776762 psgetsid "EX01" SID for EX01EX01: S-1-5-21-3593370919-795868457-2976776762 Thanks.

• Anonymous
  November 02, 2010
  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: esupport.trendmicro.com/.../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.

• Anonymous
  November 15, 2010
  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.

• Anonymous
  December 20, 2010
  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.

• Anonymous
  December 27, 2010
  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.

• Anonymous
  January 12, 2011
  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 www.citrixpro.com/.../virtual-machine-cloning-and-sysprep

• Anonymous
  February 03, 2011
  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. support.microsoft.com/.../903262

• Anonymous
  March 17, 2011
  Mark, 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.

• Anonymous
  April 22, 2011
  The comment has been removed

• Anonymous
  December 12, 2013
  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. Cheers, James