Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Background: 5 ESXi servers running in DRS, ~20TB storage. Loads of virtual servers including DC's/child DC's/member servs all 2K8 and Exchange 2010 servers.

Majority deployed from a template (not joined to domain), renamed and then joined to domain.

I'm pretty sure 90% of my machines have the same SID, at the very least I know my 3 Exchange 2010 servers have same SID (1 CAS/HUB, 2 MBX in DAG).

I know I can change the SID of my machines using NewSID, my question is can I do this to a machine already joined to the domain, let alone an Exchange 2010 server.

Any insight is helpful, thanks!

share|improve this question
up vote 1 down vote accepted

Are you seeing any specific issues from this situation?

I'd recommend using sysprep in your procedure of deploying from a template, the "Customization Specifications" of the template deploy wizard will do this for you.

That said, duplicate machine SIDs alone shouldn't break anything; the domain RIDs of the computers are already different from each other because they were independently joined to the domain. See this article for too much information.

share|improve this answer
Specific issue I am seeing is that all the sent items of a user is sitting in Drafts. This issue occurred the other day for the entire org, I moved the active copy of the DB to the other server of the 2 MBX servers and it resolved the issue. Other than that I don't see any other issues. – Shadow00Caster Mar 8 '11 at 18:11
This doesn't seem to be even remotely related to SIDs. – Massimo Mar 8 '11 at 20:03
@Massimo, it is related. However the takeaway in this case is that as long as the SID of the joined computer isn't the same as the SID of the DC that first joined the domain he shouldn't have a problem (allegedly). If it is, then he's got larger problems. – Holocryptic Mar 8 '11 at 20:49
@Holocryptic, I really don't see how a duplicated SID could cause messages being stuck in the Drafts folder (and be resolved by moving the active DB copy around). There are some known SID-related issues in Exchange 2010 SP1 (SP1, not RTM), but those don't affect message delivery. I'm not saying the issue here can't be caused by the duplicated SIDs... but I think it's much more likely to be caused by something else. – Massimo Mar 8 '11 at 20:57
@Massimo, sorry. I was reading this in the middle of doing a bunch of other stuff and misunderstood your comment. For whatever reason I thought you were saying the article had nothing to do with SIDs. Or something like that... It's been a long day. – Holocryptic Mar 8 '11 at 22:21

Exchange servers are very sensitive to domain membership and computer name, so I'd guess they are very sensitive to their SIDs, too; anyway, changing a machine's SID effectively breaks its trust relationship with the domain, so it will require to be de-joined and re-joined; and that's definitely something that you don't want to do to an Exchange server.

If you are really serious about this, then creating new servers (with new SIDs...), moving roles to them and removing the old ones would be your best approach here. Anything else might work, but it's practically guaranteed to get you into lots and lots of troubles.

share|improve this answer

Sysprep does alot more than just changing the SID. You should not deploy a non-syspreped image. Once domain joined I'm not sure what the behavior is if the sid changes. If you have already deployed a non-syspreped image I would urge you to come up with a rebuild plan.

share|improve this answer
It will need to be re-joined. Sysprep should never be executed on domain-joined machines, if you want them to be still working (as much as domain access is concerned) after it. – Massimo Mar 8 '11 at 20:12
Yes sysprep will break the domain membership. – Jim B Mar 9 '11 at 19:53

If you are referring to the issue described to here:

My opinion if something goes wrong and you need to engage Microsoft for support, you probably should not be using tools that are not supported. NewSID was retired a while back, that is not something I would run on a server that is already in production. I would agree with Massimo, turn up fresh servers and move resources to them, then after you have the old servers unplugged from the network for a while you can decommission them.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.