SBSMigration.com

Scratch Install

Scratch Install

(Reinstall server/domain from scratch as clean install to new domain)

• Abandons the domain accounts and configurations
• Workstation profiles for users are abandoned, require transition at every station
• All settings and preferences are recreated from scratch
• No specific solution provided for maintaining security preference in data, or Exchange configuration, Group Policies, Security Groups, and similar items
• Essentially this implies significant work at all workstations, all servers, replacement of any other DCs, in addition to the server

Join to Domain

Join to Domain

SBSmigration.com started it all in 2004. IT consultants were learning that the "join to domain" methodology was normal procedure in Windows. Swing Migration made much more sense. Many a Brit has summed up the process: "Brilliant!"

The SBS product team decided to embrace what we were already doing in preserving the domain, what was already the standard for migration. In 2008 Microsoft incorporated "Join to Domain" setup as a feature. A feature? 

You might wonder, if Microsoft has "fixed" the psuedo-block on join to domain setup, what's left for Swing Migration? Everything.

What's different: Join to domain is like a "setup.exe /migrate" switch to launch a DVD...that's all. It's just an installation mode to join an existing domain, a problem we solved long ago. Yet, it's not a complete migration solution like Swing Migration provides, or what you get in a Swing It!! Kit that provides you a proven solution procedure including support. 

Join to Domain: Everything to Undo

Do you know any IT consultants that like to build blind in the customer's office? Worse still is knowing that if anything goes wrong, you are doing a full disaster recovery restore of Active Directory and your production server to undo the "join to domain" in this implementation. Is there a better way? Yes, the way we have done this for years, and do it with ANY WINDOWS AND EXCHANGE ENVIRONMENT you want to address.

Swing Migration: One methodology, one set of benefits that remain consistent.

For instance, here are a few of the things you can't get just with Microsoft's outline of "join to domain", but you can with Swing Migration:

• Same domain name and Active Directory preserved
• Same server name and IP preserved
• Work "construction offline" for parallel testing and an open timeline to deploy
• Existing production server remains online and unchanged during construction
• Nothing to Undo if your migration plan is delayed or construction becomes blocked
• Transparent replacement of the OriginalDC with a new FinalDC
• Option to put the OriginalDC back online if needed...unchanged by the migration path
• Convenient and optimized work to build offsite, offline, and minimize transition time
• Schedule the server transition, and the data transfer, obtaining minimized downtime
• Little if nothing to do at the workstations, no change to profiles or UNC paths
• Predictable project construction path
• Clean install server that "looks the same" to the domain computers and users

Are you scratching your head? That looks like almost the entire list of Swing Migration benefits we have offered since 2004. These are the things that "join to domain" doesn't solve when you simply "add to domain" instead of "substitute transparently for the existing server.

Microsoft vs SBSmigration.com?

Swing Migration is not in a battle with Microsoft over how you choose to migrate SBS products or any other Microsoft products. The SBS product team recognized that the need to migrate domains is essential to why people buy Microsoft products. Swing Migration is a perfect solution for Microsoft because we provide support, we fully understand the Migration Mode setup tools, and we help people do transparent installations and upgrade. This is why you will see cooperative tours to meet MS Partners where SBSmigration.com is presenting solutions at local meetings worldwide, side by side with Microsoft.

SBS 2008 and now the SBS 2011 family now support the convenience of joining an existing domain, the setup is designed for that option. After years of teaching our customers how to "halt the setup to do a NORMAL Windows domain join", with SBS 2008 we have exactly what we always wanted. Well, almost exactly. We think everyone should use Swing Migration strategy, not just an answerfile to boot setup.

SBSmigration.com fully capitalizes on the "migration mode" setup now employed by the SBS suites. If you are not familiar with it, this mechanism of setup uses a customizable SBSanswerfile.xml that is detected as the machine boots into setup, and the behavior of the install alters to look for an existing domain to join. The details of the domain are in the answer file. It's a similar answerfile to what a standard Windows installation uses, but actually has nothing more in common than the syntax of the file. In fact, they are so different in purpose that you could technically use both the SBSanswerfile.xml and the Windows answerfile.xml at the same time in the same construction. Fortunately, this isn't really necessary, we can get what we need done with the SBS file.

Check out Swing Migration, or ask us for more details.

In-Place Upgrade

In-Place Upgrade

(Direct install over the current installation) There are many reasons to disregard this approach, not the least of which is that Microsoft no longer supports the technical overwrite of one installed Windows OS by a different Windows OS. Here are a few reasons why:

• Puts the production server at risk with interactively performed live transfers
• Odd mix of drivers or DLLs specific to one product vs. the other
• Hardware compatibility with drivers that change from one release to another
• Doesn’t directly support change of hardware as a result
• Requires preliminary clean-up of current server prior to install
• Fails to provide a clean server configuration as a result

If you are still thinking about In-Place Upgrades, you won't have many places to practice them anymore!

Microsoft ADMT

Microsoft Active Directory Migration Tool (ADMT)

SBSmigration.com supports and embraces using ADMT for projects where it is the right tool and exactly what you need. In fact, we are building Swing Migration project around ADMT features, combining the unique value of both.

There are three reasons you might use ADMT:

1. Merge 2 or More Domains Together
2. Unavoidable Domain Rename (Single-Label or Legal issues)
3. Disaster Recovery

ADMT is a tool specifically intended to merge or export Active Directory objects from one domain/forest into another. It's not an ideal solution for most migrations in SMB space. But it is irreplacable for manipulating multi-domain situations.

• Merge 2 or More Domains Together

When two companies combine, you may need to converge the IT resources and general staff under one common domain/forest. This often becomes part of an upgrade and migration rolled into one large project. ADMT provides the mechanism to bridge between the separate forest and combine them.

But how can that be possible with SBS products that don't support trusts? We have several ways this is addressed as part of an efficient Swing Migration solution with the normal benefits of "Nothing to Undo", "No Change or Interuption to the Domain until Transition", and you still get to work offline for your construction. 

• Unavoidable Domain Rename (Single-Label or Legal issues)

Single-Label domains are a headache, they don't behave properly and Microsoft is dropping support for them. What do you do if you must address an existing single-label domain? You can't Rendom an SBS server, that doesn't work with Exchange on a DC. Besides, if you wanted to upgrade anyway, why not just do a Swing Migration where you rename the domain in the process. Same solution for legal or vanity reasons to rename your domain. We have the answer on this one too!

• Disaster Recovery

Nothing solves a problem if your server is crashed and you must replace the hardware, at least you can save the Active Directory with a Swing Migration to a healthy new DC and infrastructure. SBSmigration.com can help you recover from non-boot conditions, even non-functional servers where all you have is a backup and no matching hardware.

But what happens if things are one step worse: What if AD is actually corrupt? It's very rare but faulty hardware can cause such problem. We have the solution for using ADMT to export the critical AD objects you need, we can guide you on your process into a new and clean Active Directory forest/domain with as transparent as possible a result as you can get. Obviously, this isn't an offline build unless you have a wounded operation, but the end result is as fast as you can get recovered because we can help you optimize your work. Recovery what you need, abandon things you don't, and it's entirely up to you how far you want to go. We have the project solutions for disaster recovery to new servers, new domains, new products and new platforms all handled in one efficient deployment.