The Sikh Geek

I’ve been discussing why you can’t run more than one SBS 2003 server on the same network (subnet) on the Yahoo SBS Groups and there is a reply from Jeff Middleton MVP which gives a detailed explanation. I think it is so important that I’m reproducing his reply here. Does this guy know his stuff or what!!

Hi Gang,

I can clarify a couple of points of confusion in the thread.

I agree with what Vlad asked about and was supported by others, you can plug a bunch of SBS servers into the same subnet, not a problem. They don’t mind being neighbors or sharing a gateway, whatever.

The more important question here I do want to clarify just so everyone does understand the Swing process and why the constraint of behavior is as it is.

MS provides for a brief period of time measured in hours and days during which you can quite happily have more than one SBS server in the same domain at the same time. After a period of hours, you begin to see nag messages telling you that you are in violation of the license agreement, but not much more happens. These messages get more aggressive, and then in a period of days later you will find that more aggressive things happen including shuting down at least one of them, the one without the FSMO roles. The FSMO roles are unique in a domain, so you can understand why there’s a predictable outcome as two why one has a better lock on
authority.

Now, there’s a misconception about what I say in my documentation as it was relayed in this thread. I do actually recommend that you install the TempDC and the FinalDC using the same media. This isn’t because it accomplishes some magical solution, it’s just a simple way to say “if it works to build the TempDC, it will work the same way for the finalDC”.

It’s also true that you can use non-SBS media if you like. No matter.

What you can’t do, and this is the real key, is you can run a server installed from SBS media for an extended period (think days) without it
(a) being promoted to a DC
(b) having all the FSMO roles
(c) being the only SBS DC in the domain

Oddly enough, all three of those rules don’t apply during the very initial period after you install from the media. That means, there’s a period of hours and days applicable to the combination of those three things. I can assure you that after a period of weeks and month(s), you will find enforcement causes all SBS servers in the LAN to become non-functional for production use if they don’t match that set of criteria.

On the CRITICAL point I make about not ever plugging the originalDC and the FinalDC into the same network together, this MAJOR PROBLEM has nothing to do with SBS. What it relates to is that the point of the Swing is that both these servers are identified in the AD by essentially identical characteristics in the AD, that’s the point of the exercise. The differences are extremely subtle to the point of not mattering, but here’s the issue: The believe as far as can be identified in AD that they are the same DC, and they are storing cloned replicas of Active Directory that at some point back (when you split off the TempDC) began a split reality in the life of their AD. Starting with identical AD conditions, you went through your offline construction process to wipe out substantial sections of AD (Think: exchange and the original DC) and those changes are present in the originalDC’s view of AD. If you let these boxes see each other, there’s a really good chance they will attempt to “play the transactions” from both AD experiences against each other and totally obliterate the AD from having a usable condition. They can effectively destroy it on both servers. It has nothing to do with SBS, it has to do with having violated a basic rule in Active Directory design: you cannot reconverge diverged AD realms without exceptionally complicated issues being addressed. Certainly you don’t want to have major modifications to the very DCs in question as part of the changes.

Finally, the thing on the DHCP collision, you should expect that if you plug together (n) number of SBS servers on a common subnet, you will probably have (0) DHCP Service running in short order. I believe they will all shut down as soon at any two recognize the other. Of course, this can be a really amusing thing, sort of a brain teaser because I think I can also predict that it depends upon how you do the test. (Not that this matters to anyone) If you plug them in and turn them on one at a time, the last one to boot will run DHCP, the others will all cause one another to go off.

If you plug them all into a dead switch, then power it on all at once, they probably all shutdown. In other words, if any two see each other’s DHCP service active by doing an announce and reply, they both shutdown.