SBSMigration.com

We do that to solve the problem of recreating a domain controller with the same name as the existing one. Therefore, the answer here is that you are welcome to build just one new DC in the existing domain and that meets the requirements for adding an SBS to an existing domain. That will be an operational solution, it’s certainly an option if you don’t care about changing the server name from whatever it was before. Just realize, you will break all references to your original UNC and URL paths to the server regarding batch files, shortcuts, favorites, recently used links.

I suppose that someone will suggest using the new tools that Microsoft has discussed about DC renaming, but this is really outside the scope of our process. If it does eventually save some time, I’d welcome not building a DC twice, but since the installation process involved is pretty simple and runs mostly unattended, we don’t look at this too closely.

In this scenario, you are accepting a fair amount of change to your network. By continuing with the DC you have just built which has a different server name than the previous SBS, you will be causing all network shares, shortcuts, printer connections and perhaps some Group Policies to become voided. The UNC path to places hosted by the old SBS server would have been used in many different places, some rather subtle. About the only circumstance in which this choice is fairly transparent is if you either are replacing all the workstations at the same time as well, or if you were using another server as a file and print server host, and now are making it the SBS to reduce the number of servers you operate.

Yes, this is certainly possible, perhaps even preferable in some situations. It's probably not necessary to learn to use Virtual Server for this purpose.

It's clearly convenient if you are doing Swing Migration projects all the time, you can reduce your project construction time and make the construction steps convenient and easy to repeat.

The answer to this question is that you can avoid Exmerge if you want to go the route of using LegacyDN to solve any namespace issues you might run into.

This is discussed in later parts of the documentation, but the main reason for bringing this up here is to identify that our migration process for all other aspects of this regarding AD and the server itself really don’t require you to use the LegacyDN approach. Rather, LegacyDN is one of the options that has been included in this overall migration discussion.

This is an excellent and fair question. The answer is that it’s reliable and consistent if you handle the steps responsibly, and if you ensure that your replication processes are completed at each step.

If you chose to use FSMO role transfers rather than seizures, and if you choose to use Exmerge rather than LegacyDN, then you really have nothing exceptional involved here, just a technical process more commonly used in Disaster Recovery scenarios, or migration methods used in multi-domain transitions and upgrades.

As with any technical process, you can make a mistake that is unanticipated, and that can lead you to problems, but since most of this process involves working offline, it’s pretty safe and it’s pretty reliable overall.

Doing a swing upgrade back to the original SBS server hardware is achievable, it’s not a technical problem, but it redefines a few preferences I have in doing migrations. You just need to decide if you want to maintain the same level of roll-back that is possible with a separate server for the final target of the upgrade.

The short answer is that you lose the open-ended timeline when you take the original SBS offline to install the new platform configuration. Depending upon your skill and resources, you might be able to keep the previous condition on a drive image copy in order to go back to it.

Three possible approaches come to mind, and it sort of depends upon whether or not you have the additional resources available to explore this. The main tool you would want to have, as always, is drive imaging software.

• When you reach the point of doing the second server, you could use a spare hard drive for the construction process. When you finish the upgrade and are satisfied with the complete result, you image that back over to the production drives at a convenient opportunity. This allows you to keep the original SBS production installation intact, though you can’t run the SBS server at the same time as you are building the new one. Still, this offers the opportunity to do the upgrade progressively over a series of evenings or weekends.
• Another alternative is to image the original production server over to a temporary computer with compatible hardware features. You run the production LAN from this temporary server during the period you finish constructing the permanent server. However, this obviously implies a migration of a different type: how to shift a configured server installation to new hardware with minimum effort.
• Of course, there is the obvious approach, but it’s not really consistent with the entire spirit of this migration technique: you reformat the production drives and do the upgrade on them. As an alternative, you could make a drive image to a temporary drive to preserve the production system configuration. If needed, you can put the server back online with that drive if the upgrade doesn’t go as expected.

If you intend to use the method outlined in this chapter to redeploy on the same server, you must pay attention to a very important point. The specific sequence of the steps in this documentation are presented in an order with the assumption that you want to export some settings and the Exchange Information Store from your current SBS after you build the new server. I allowed for this in organizing the steps. Therefore, you will need to do the "export steps" described in the Phase 5 section first before you finish Phase 1, before your current SBS server is actually gone forever!

This is a little complicated, but it’s manageable. You will reach a transition point in the upgrade where you are ready to substitute the new SBS for the old one. At that time, you must demote your DCs from the “old” domain, then DCpromo them into the “new” domain. This should be transparent in most cases.

A constraint of the SBS product is that all DCs must be online during SBS Setup phase. The method I’ve described assumes that you delete all other DCs from AD before you move to the SBS Setup phase. Anything else becomes not only hard to document for me, it also becomes dramatically more complicated to administer. I’m not really comfortable suggesting the seizure of roles rather than transfers if you have additional DCs that could be seeing administrative changes during the process. I’m also not really comfortable with ensuring the replication process is doing what we think in the time we expect to allow. Therefore, you have two threads of logic you can choose between while still using this method.

• You could swing the DCs over to the construction domain, but that means you aren’t working offline, and your production domain is missing some servers for the duration.
• Alternatively, you could do the method as described here including the removal of all DCs in the offline AD processing. You would then need to demote the DCs out of the production domain just before you introduce the new SBS because it’s not going to like seeing computers that claim to be DCs from another world, yet have valid SIDs. With the SBS connected, you could immediately DCpromo your additional DCs back to their established role in the “new AD” configuration. As a general rule, this should be fairly safe, but that’s not something I’m endorsing as impossible to cause problems.

The answer is that you can’t do the exact method without being aware of what your concerns will be. In general, these sort of project are the type I can really add some value to in helping you determine your best course of work. You will need to bring your existing domain and Exchange profile into a baseline condition of only one Exchange Server, or you will need to swing the Exchange upgrade separately.

The logic I present could work for you, but it’s dramatically more complicated. It depends upon if your additional Exchange Server is also a DC, and how the Information Stores are managed across both DCs. I will make some basic statements that I hope will be useful, but I’m not going to get into the detailed discussion on this point, or elsewhere in this chapter.

• If your additional Exchange Server is also a DC, you need to consider what I just described above, and now compound that with Exchange Information Store issues.
• Even if your additional Exchange Server is just a member server, you would be the one who has to figure out if you prefer to kill the entire Exchange Organization as I described, or to swing all Exchange mailboxes to be preserved on that server and to preserve the Exchange AD information as well. There’s a dramatic difference now.
• It’s not that I can’t imagine making this work, rather that I can’t imagine you getting Microsoft to take a support call on your Exchange or AD issues if you go this route in multi-server mailbox realm. Therefore, unless you can condense back done to a single Exchange Server and the “concepts” of an SBS type configuration, you don’t have my encouragement to beat up on Exchange and AD as I’ve described here. The simplicity of SBS isn’t where you are playing anymore, so this upgrade concept isn’t really intended for your situation.

I wouldn’t want anyone to take the disaster recovery techniques to work offline and assume that you will get it all right on the first try. The place you might usually see such tools used in this way is to solve a problem you don’t have any other options left to go at it with.

I’ve outline an efficient, brute force migration path with deep tree edits to Active Directory using NTDSutil and ADSIedit that yield a rapid solution to our scenario problem, but there’s no undo in the realm you are operating. We are rocking the copy of AD very hard with the FSMO shifts, and it’s efficient because we don’t have a huge domain and lots of DCs to sort out at the same time. Doing this offline isn’t just a feature of the process, it's a global safety net as well. You can’t lose the production domain if you aren't working on it. I feel comfortable, in the lingo of golf, taking a mulligan to start all over again with a second attempt using another offline DC construction process that didn’t go right on the first round.

Therefore, under no circumstances do I offer encouragement or tolerance with people who commit themselves to try things like this in a way they can’t do over, or undo like what this document describes. To be blunt, if you aren’t working offline, you aren’t following the documentation steps or the plan I have in mind to be a safe and responsible approach.

The only steps I have outlined for modifying the online AD are to simply update AD to allow a Windows 2003 Server as a DC, and then to create it. At that point, when we detach the new DC, the production domain is really going to be quite safe. The further away from this you drift, the less anyone would be able to support bringing you back, including Microsoft. Microsoft has documented a way to swing a live domain, and it’s called the ADMT Method. That’s probably your better option.