Migrating from Microsoft Windows SBS 2011 Standard
Microsoft Windows SBS (Small Business Server) 2011 Standard is an package that includees Windows Server 2008R2, Exchange 2010, and SharePoint 2010 Foundation. Installing SBS 2011 Standard fresh is an easy task and gives you what works out a complete Windows infrastructure, complete with DNS, ActiveDirectory, WSUS, File & Print services configured as well as user mailboxes on Exchange and an Internal SharePoint site. It runs on TECT and it may run on a server you have.
Windows Server 2011 Standard will be supported out through 2019 or 2020. This document will investigate why you may want to move from SBS 2011 Standard (or an even older version) and at what point you might want to do it. Windows SBS 2011 Standard may potentially have seven more years of life left in it before its component
Why Migrate?
Although this is several years down the road, the components of Windows Small Business Server 2011 Standard are all going to fall out of support by 2020. For SBS 2011 Standard, Microsoft is listing the support on each component individually. Windows 2008R2 will fall out of support (and stop receiving security updates) at different times. If at all possible, I recommend (and plan for myself) to be off of this product by 2017.
In addition to the end of support of each of the products, it may be worth migrating as different products become available. One example of this is that SharePoint 2010 Server and Enterprise may not run directly on the main SBS 2011 Standard server and each have a lot of additional functionality, such as My Sites and enterprise/public web site content management functionality.
In addition to that, Microsoft considers the way that Small Business Server is set up to be against best practices. Ideally, the infrastructure services such as AD, DNS, DHCP, File, and Print would be on one installation of Windows, and Exchange and SharePoint would each be on their own installations.
Potential Strategies
Sidenote: This is not going to happen and relying on this is a terrible idea.
Do Nothing
One potential strategy is to keep using SBS 2011 forever. It may be that by 2017 to 2018, Windows 7 and Windows Server 2008R2 will be unpopular enough that they will not suffer the same fate that Windows XP and 2003 are suffering and by the time Microsoft stops supporting them, malware authors and other malicious forces will not be targeting this version of Windows anymore.
Server 2012 R2 Essentials on Hardware
One other strategy for deployments of SBS 2011 Standard is to move SharePoint and Exchange services into the cloud using a service like Microsoft Office 365 and migrate the on-premisises infrastructure services to a new Windows Server 2012 R2 Essentials machine. You can also upgrade or reinstall your existing SBS 2011 Standard machine to 2012 R2 Essentials.
I haven't yet researched the process to upgrade from SBS 2011 Standard to Server 2012 R2 Essentials
2012 R2 Essentials will be a sore spot if you have more than 25 users, but if you have 25 or fewer users, then you can simply buy a copy of Windows Server 2012 R2 Essentials, install it, and then choose what you want to do with your e-mail and collaboration. 2012 R2 Essentials has hooks to both Office 365 as well as on-premises Exchange and SharePoint servers.
Server 2012 Essentials in Hyper-V
Windows Server 2012 R2 Essentials now supports a maximum of 64 gigabytes of memory and can be used as a Hyper-V host. Another option is to install it in a virtual machine on the free edition of Hyper-V. There's already a good TechNet Blog entry about using Hyper-V. No word on what doing backups on a free Hyper-V system is like.
Virtualization with Windows Server 2012
Windows Server 2012 R2 Standard is another option for the base Windows operating system. When you move in this direction, you can either use the standard Windows experience and administration tools or techniques, or you can use the Windows Essentials experience. However, you are still responsible for traditional Windows Server licensing.
Windows Server 2012 Standard has a higher memory limit, and allows for two instances to be virtualized.
If you want a graphical base, you can either forgo Exchange or SharePoint, buy both Windows Server 2012 R2 Standard and Windows Server 2012 R2 Essentials so that you can run Exchange and SharePoint on their own VMs and run your infrastructure in the Essentials VM, or you can buy two copies of Windows Server 2012 R2 Standard, run your infrastructure on one of those copies, run Exchange and SharePoint on two others, and have another VM available for whatever other tasks, such as a line of business application, terminal services, or to spread some of the infrastructure services between multiple boxes. (Useful for keeping DNS and AD available while rebooting vor updates.)
Multiple Servers
In my particular situation, SBS 2011 Standard is installed on a fairly big piece of hardware that's capable of a fair amount of virtualization. With some more memory, the machine could easily run the tasks of SBS 2011 as separate virtual operating systems, even running newer software.
However, one other strategy is to use multiple physical servers. This lets you scale each server up and down individually, however it could introduce complications in terms of backups, requiring more expensive backup products, or a backup infrastructure for each server.
In the reasonably far future however, a machine like TECT will be pretty close to the end of its life cycle at seven to eight yers old. In 2016, it may be that purchasing and running several servers that are much smaller, such as the Intel NUC.
Any given network can have more than one Windows Server Essentials server, so one NUC could host infrastructure services, a bigger server could run Windows Server Essentials for file services, and two additional NUCs could run Windows Server Standard for Exchange and SharePoint.
Migrate or Rebuild?
Normal installations of Windows Server and its associated applications have a fairly straightforward migration path. You can install a new version of Windows right on top of an old one, or you can add a new version of Windows to a domain, copy information out, and then remove the old server.
Unfortunately, with SBS, simply installing a new version has almost never been an option. Typically, SBS expects you to start by building a new server.
The best method of migrating away from SBS is likely to be building a new server and then moving data to it.
There are several types of data that will need to be moved or rebuilt
- User account data (Active Directory, Exchange)
- Mailboxes (Exchange)
- "CompanyWeb" or other SharePoint sites
- Shared files on the file server.
- Individual home directories
The type of environment, number and technical skill level of the users of a system, and the overall usage of the system (as well as its importance in daily operation) will be the primary factors in deciding how to migrate the system.
But let's behonest here: asking your users to move their own mail is kind of ridiculous. Ideally, it should be possible to move all of the data on the server end of things.
If your users are non-technical, then asking them to keep a copy of their own mail account may be asking too much and finding a way to gracefully migrate both the user account data and the mailboxes will be necessary.
Migration Strategies
One strategy may be to migrate the services of your SBS server to other, indepenent servers (especially Exchange/SharePoint) before upgrading SBS to Server Essentials, or installing Server Essentials on a new server and having that machine take over.
In addition, if you are in an environment where keeping services up (especially e-mail and core network infrastructure) as much as possible, the migration strategy may end up looking like this:
- Install Exchange 2010 on a new server.
- Add this server to a DAG with the SBS server
- Allow the data to synchronize. Make the new server the primary mail delivery and edge server.
- Remove the SBS server from the DAG.
Once this migration is complete, you now have Exchange running independently on a new box.
You can do a similar migration with SharePoint:
- Install SharePoint 2010 Foundation on a new server.
- Back up your SharePoint content
- Restore the SharePoint content on the new server.
- Re-direct web traffic to the new server.
Build a new Environment
If your users are technical or your environment is very small and very new, it may make more sense to simply back up your critical user data (Exchange mailboxes, SharePoint sites, file folders) and restore this data on new installations of Windows Server, Exchange, and SharePoint.
When to Move
Deciding when to move can be almost as important as making the decision that you should move to begin with. This document is being written in late 2013 and early 2014, and Windows SBS 2011 Standard will continue receiving security updates through 2019 or 2020.
As with any migration from one major version of a product to the next, the migration will become more technically difficult if you wait longer. Some of the steps listed above appear straightforward, but those are just steps to change the environment within a single environment, and don't even talk to the potentially complicated nature of moving from one version of a product to the next, such as from Exchange 2010 to Exchange 2013.
The decision of how long to stick with a particular version will depend at least as much on what resources and budget are available as it does on the life cycle of hardware and the amount of time and expertise that can be dedicated to the upgrade.
One advantage of upgrading more frequently is that the upgrades are typically vendor supported and can be completed more quickly with less man-power. This may be a financial trade-off for some organizations, choosing to hire more staff to keep systems running longer and jump more versions at once, or employ a smaller IT staff but put more money into server hardware and software to make migrations easier and less expensive, as well as possibly to save costs.
There is no perfect answer, although there are certainly plenty of sub-optimal situations. It would be a poor strategy, for example, to avoid thinking about the issue until the product is already unsupported. As mentioned in a sidebar above, it is also a poor strategy to simply hope that the product works forever.
For an extremely small installation used primarily personally and by local groups, such as TECT, the answer is also not clear. It makes sense to split the functions of SBS out into their individual server components earlier rather than later, which will make later upgrades to subsequent versions simpler, and lets upgrades of different components be staggered, rather than upgrading the entire stack at once.
For a bigger installation with multiple dozens of users actively using a system, where there's a formalized IT structure and hardware and software get purchased based on a particular budget, that budget will most likely dictate when a migration is made. One possibility is that because subsequent servers only need to run a part of the total workload, smaller servers can be purchased, but more frequently.