Windows Server 2012 Deployment

Windows Server 2012 Deployment

Information you need to know to plan your deployment strategy

You heard about all the great new capabilities in Windows Server 2012, so you performed some basic capability testing and decided to do at least a limited deployment of the product. This guide can speed up the development of your Server 2012 deployment strategy by providing the information you need to answer questions such as:

  • Which Server 2012 edition should I use?
  • Can I deploy Server 2012 on my existing hardware?
  • Should I upgrade my existing systems or perform a fresh install?
  • What installation option should I choose?
  • How well will Server 2012 play with my deployed applications?

Which Server 2012 Edition Should I Use?

The good news is that Server 2012 licensing, like Microsoft System Center 2012 licensing, has been dramatically simplified over its predecessor. The 14 different editions of Windows Server 2008 R2 have been pared down to four. In order of scale, the four editions are Foundation, Essentials, Standard, and Datacenter.

Foundation. Purchasable only through OEMs, this OS provides, as the name implies, a foundational infrastructure server for your network. It offers a wide variety of server roles, including Active Directory Domain Services, DNS, DHCP, Active Directory Certificate Services, Web Server, File Services, Print Services, Remote Desktop Services, DirectAccess, Storage Spaces, and Server Manager. Many of these roles have some kind of small-environment limitations suitable to the price of the product. For example, Hyper-V and failover clustering isn't available, and this server must be the PDC role holder in a domain that has no trusts. It has a maximum user limit of 15. Its Server Message Block (SMB), Routing and Remote Access (RRAS), Internet Authentication Service (IAS), and Remote Desktop Services (RDS) connections also have enforced limits. This edition supports only a single socket processor (although multiple cores are allowed). Even with its limitations, this edition provides an excellent set of infrastructure IT services for a small business. In contrast with Essentials, it assumes you have some degree of IT support, such as a service partner. You can find out more about the Foundation edition's capabilities and restrictions in Microsoft's Introduction to Windows Server 2012 Foundation web page.

Essentials. Server 2012 Essentials is the replacement for Windows Small Business Server (SBS) and Windows Home Server. (It evolved from SBS 2011 Essentials.) Designed for a larger environment than the Foundation edition, the Essentials edition supports up to 25 users and 50 devices. It has a similar feature set to Foundation, with an important exception: It supports integration with cloud services (e.g., Microsoft Office 365, Windows Azure backups) instead of these services being built into the OS. If you're an SBS user, you'll want to read the Essentials edition documentation, such as Microsoft's "Windows Server 2012 Essentials Frequently Asked Questions." Paul Thurrott has also written extensively about the product.

Standard. Server 2012 Standard is a full-featured OS version for businesses with more than 25 users. It basically has the same features as the Datacenter edition. The difference is that the Standard edition is designed for nonvirtualized or lightly virtualized environments. It's licensed for only two virtual instances. In addition, the license is good for only two physical processors on a server, which means that you need to buy two licenses if you want to run the Standard edition on a four-processor server.

Datacenter. Server 2012 Datacenter Edition is designed for heavily virtualized environments, as it's licensed for an unlimited number of virtual instances. Like a Standard license, a Datacenter license covers only two physical processors, so again you might need to purchase additional Datacenter licenses depending on the number of processors your server has.

Most businesses will likely use the Standard or Datacenter edition. Microsoft has a handy licensing datasheet that explains the different types of licensing in more detail.

Although technically not a Server 2012 edition, Microsoft Hyper-V Server 2012 is a free downloadable hypervisor that supports all the features of Windows Server 2012 Hyper-V. What the free hypervisor doesn't have is:

  • A full Windows Server OS interface (similar to a Server Core installation but much simpler)
  • Licensing for any server virtual operating system environments (VOSEs) running on it

The free hypervisor can be used when server licensing isn't an issue. For example, you can use it to provide a virtual desktop infrastructure (VDI), where the VOSEs are clients and not servers. You can also use it for non-Windows virtual machines (VMs) and down-level VMs (e.g., Windows Server 2003 VMs) where you already have the license.





Can I Deploy Server 2012 on My Existing Hardware?

When considering a Server 2012 rollout, one of your first questions will probably be "Can I deploy Server 2012 on my existing hardware?" The answer is "It depends." If you deployed your server hardware in the last couple of years, it'll probably run Server 2012 just fine as long as you follow the long-understood best practice of satisfying the base hardware requirements plus some sensible headroom. Another way to look at hardware compatibility is that if you bought hardware that could run Server 2008 R2, running Server 2012 on it should be no problem.

According to the Installing Windows Server 2012 web page, the base requirements to run Server 2012 are:

  • 1.4GHz 64-bit processor
  • 512MB RAM
  • 32GB hard disk space

Here's what I've found in regards to the system requirements:

Processor. A 1U small to midsized business server with an Intel i3 2.6GHz processor (e.g., an early 2013 HP ProLiant DL120 G7 Server) will likely have no difficulty running Server 2012. I recommend staying away from Intel Atom and AMD Turion processors, however. They barely clear the hardware requirements. Plus, as I found out firsthand, they become processor bound when running Server 2012 for anything but the most basic File Services role.

Memory. As always, the more RAM you can throw at the OS, the better it performs. You've probably heard this for a long time, but you might not know why. There has always been very few performance-tuning "knobs" in Windows Server OSs. By adding memory to the system, you reduce the need to page stale memory pages out to the paging file on disk (it's hidden in the root of the system volume) and read them back in when they're needed. Because the disk subsystem is thousands of times slower than memory—even with a solid state disk (SSD)—the more data you can keep in memory, the better the system performs. And don't forget that practically any server can become a virtualization host, so adding memory at the beginning for this role makes enabling this capability that much easier when you need it.

Disk. Magnetic rotational disks are cheap, so you shouldn't have any problem meeting the 32GB hard disk space requirement. Implementing a disk fault tolerance method such as mirroring is a relatively cheap way to protect even the most failure-prone of server subsystems.

SSDs have come down in price to a point where they're increasingly being used in both clients and servers. They aren't a slam-dunk for servers the way they are for clients, however. An SSD's increased performance ensures the server boots quickly, but after the initial boot, most server I/O comes from other volumes that hold databases, file stores, or IIS directories. If these volumes are on large rotating drives, you're back to where you were. SSDs on a system volume will page faster, but if you've added enough memory per my recommendation, the system will page only the bare minimum.

Network. Multiple Gigabit Ethernet (GbE) adapters are pretty standard fare for servers in the last few years. Server 2012 will take full advantage of them and NIC teaming to provide aggregate throughput and fault tolerance for your network collection. If you're buying new servers that will have high network I/O requirements, considering springing a little extra for Remote Direct Memory Access (RDMA) capability. This capability automatically turns on Server 2012's SMB Direct feature for high speed, low latency network I/O. Also look for receive side scaling (RSS) capability, as this enables the new SMB Multichannel network I/O distribution in Server 2012.

If you've satisfied the basic requirements, a further test for hardware compatibility is to check the Windows Server Catalog to see if your server (or an individual component in it) is listed there. The Windows Server Catalog is a regularly updated, comprehensive list of all the hardware and software that has been tested to work correctly on a given version of Windows Server. Note that your hardware might not be on this list but still work correctly with Server 2012.

An automated way to analyze your existing hardware is to use the Microsoft Assessment and Planning (MAP) Toolkit 8.0. This tool currently offers 31 different types of analyses across many Microsoft products. Of interest here is the Windows Server 2012 Hardware Assessment report package. After you install and run the tool, this package includes an inventory of your existing server hardware and installed OSs, and a Server Inventory Proposal that assesses your current environment for Server 2012 hardware readiness. (It doesn't address application compatibility.)





Should I Upgrade My Existing Systems or Perform a Fresh Install?

When deciding whether to deploy Server 2012 by upgrading your existing servers or performing a fresh install, you need to weigh the pros and cons based on the target server's workload. If you upgrade, the process is presumably much easier than a fresh build because all the work is done for you. At the end of the process, you'll have an updated server with all the applications intact. The risk is that upgraded applications don't always work correctly, although you can mitigate this risk with testing. You'll also be carrying forward old applications and the cruft they've left behind, which could potentially slow down the system or cause other problems.

A fresh build is the obverse. You'll have a clean system with only the applications you need. However, for some applications such as Microsoft SQL Server, it might take a lot of work to reinstall and restore the system's workloads. For distributed applications such as Active Directory (AD), a fresh build is generally the recommended best practice because the important AD components can be either replicated in from other domain controllers (DCs) or quickly installed from an AD database backup.

If the servers you want to upgrade are virtualized, you can take advantage of the virtual environment's flexibility and use this upgrade method:

  1. Take the target VM off the production network or otherwise make it unavailable to users.
  2. Take a snapshot of the VM.
  3. Upgrade the VM.
  4. Perform acceptance tests on the upgraded VM.
  5. If it passes testing, return it to production. Otherwise, roll back to the original VM and return it to production.

It's important that you check your application's compatibility to snapshotting before you attempt this upgrade method. Thus, I recommend that you follow the best practice of upgrading and testing a copy of the VM in a lab environment before you perform the production upgrade.

What Installation Option Should I Choose?

Not only do you need to decide on the version of Server 2012 to install and whether to upgrade or perform a fresh build, you must also select the installation option. You can install:

  • A server with a GUI. With this installation, the server will contain the full graphic interface Windows Server has always had
  • Server Core. With this installation, the core OS is installed with only a minimal command line/Windows PowerShell interface. This provides a smaller footprint than the full product, which means less maintenance and a smaller attack surface.
  • MinShell. You can think of MinShell as Server Core with training wheels. The core OS is installed with the ability to run basic GUI administrative tools such as Server Manager or the Microsoft Management Console (MMC) Computer Management snap-in.

Which option you choose depends on the technical requirements of your server applications and your server management environment. With MinShell, you need to test your server applications to make sure they'll work. With Server Core, server applications that require a GUI to manage them won't work. However, many mainstream server applications have become much less GUI dependent since Server Core has been introduced. It's also important to note that to run Server Core in production, your management infrastructure must be set up to remotely manage Server Core instances if your staff isn't proficient with PowerShell. The only way you can run administrative tools is either remotely from another computer or using PowerShell from the local console.

Unlike Server 2008 R2 and Server 2008, Server 2012 doesn't make you commit to one installation option. Using PowerShell scripts, you can move freely between all three options. This freedom gives you the ability to try MinShell or Server Core. For example, you can build a Server 2012 installation with a full GUI and certain set of roles and features. After running it for a while to make sure it's exactly what you need, you can strip down the system to MinShell and make sure you can remotely manage it. If you encounter any management problems that require you to log on to the system, you can still use the management utilities that are available in GUI form in the system's console. When you have all the remote management kinks worked out, you can remove the GUI management tools from the system by changing the installation option to Server Core. For more details on the Server 2012 installation options, see the Windows Server Installation Options web page.





How Well Will Server 2012 Play with My Deployed Applications?

Application compatibility with a new OS is probably the single largest factor blocking new OS deployment. First, let's start with Microsoft applications, then cover third-party applications.

Microsoft applications. You might think that all Microsoft applications are compatible with Server 2012, but unfortunately that's not always the case. For example, although Microsoft Exchange Server 2013 is compatible with Server 2012, Exchange Server 2010 SP2 isn't compatible. SP3 will provide compatibility when it's released, which is currently predicted to be sometime in first quarter 2013. For more information about Exchange 2013's OS requirements, see "Exchange Server 2013 Requirements."

SQL Server 2008 is compatible with Server 2012 if you install SP3. SQL Server 2008 R2 requires SP1, and SQL Server 2012 will (appropriately) run as is on Server 2012. For information about SQL Server compatibility, see "Using SQL Server in Windows 8 and Windows Server 2012 environments."

Note that although you can manage Server 2008 R2 and Server 2008 from Server 2012's Server Manager, you must install Windows Management Framework 3.0 on the target systems. Be sure to apply the correct version for your target system's version and architecture.

Third-party applications. To determine your third-party applications' compatibility with Server 2012, you should first check the Windows Server Catalog to see if they're listed. If not, check with the vendors. Do the vendors certify that their applications work with Server 2012? Failing that, will the vendors support their applications if they're running on Server 2012? If not, you need to perform your own tests and decide whether upgrading is worth the risk. You don't want to have a production problem, call the vendor for help, and have its support staff turn you down. Virtualization has made this situation easier because you can run an application with Server 2012 compatibility problems in a VM running an older OS version.

Microsoft provides a wide range of tools to check applications for Server 2012 compatibility. For example, the company provides the Application Compatibility Toolkit as well as two video series about it. The video series "Application Compatibility Toolkit (ACT) Feature Walkthroughs" covers key features in the toolkit, whereas the five-part video series "How to Use the Application Compatibility Toolkit" demonstrates how to use it.

There's also the Software Certification Toolkit (x64), which was originally created for application developers but is now available to everyone, and the Microsoft Platform Ready Test Tool to test applications for compatibility. If you have in-house applications you want to test, you can follow the guidelines in the "Windows 8 and Windows Server 2012 Application Compatibility Cookbook."

Getting third-party applications certified with a new OS is a chicken and egg problem. Although Microsoft pushes their partners to release compatible versions of their applications soon after a new OS ships (thus making the OS easier to deploy), the vendors know that most customers wait a while before installing a new OS version. So, there's little incentive for vendors to make upgrading their products a high priority.

More Deployment Choices

Server 2012 provides you with more deployment choices than any previous version. Its hardware requirements are a little different than its predecessors, and its installation options are both broad and flexible. Nonetheless, application compatibility testing is as important as it's ever been. Fortunately, you also have a good selection of application compatibility tools to help ensure your upgrade runs smoothly.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.