Preparing for Windows Server 2012 R2

Lesson 1: Planning for Windows Server 2012 R2

The success of a deployment project depends on careful planning combined with meticulous execution. First, you need to define the scope of the project so that you know where you want to end up. Then, you need to lay out a project plan that involves pilot testing to familiarize yourself with the new platform and to identify any potential issues that might arise during the process. You also need to perform a thorough assessment of your existing environment to ensure there are no surprises coming and develop a methodology to migrate existing servers and roles. Finally, once deployment is underway, you need to perform continued testing to ensure everything is happening as planned.

Deployment scenarios

Deployment projects involving servers can be categorized in a number of ways, depending on whether you are deploying a new infrastructure, upgrading or consolidating an existing infrastructure, or implementing a new infrastructure model such as cloud computing. In addition, deployment can differ depending on whether you are migrating your existing infrastructure or only a portion of it; whether you plan to reuse existing hardware or move to new hardware; whether your environment is managed or unmanaged; whether your existing infrastructure is large or small, centralized or distributed, heterogeneous or homogeneous; and many other factors.

With so many different ways of envisioning and scoping deployment projects, it’s obvious that there is no single approach to planning and executing such projects. However, there are some steps and considerations that are common to all deployment projects, and being aware of such best practices and implementing them can help ensure the project’s success.

I’ll begin by describing six deployment scenarios for organizations that want to take advantage of the new features and capabilities found in Windows Server 2012 R2:

• Greenfield
• Forest upgrade
• Existing environment
• Server consolidation
• Private cloud
• Hybrid cloud

Greenfield

In terms of infrastructure, a greenfield deployment is one in which no infrastructure currently exists. For example, let’s say that Contoso, Ltd., is a new company that needs an on-premises infrastructure deployed for its rapidly growing workforce. A greenfield deployment of an infrastructure based on Windows Server 2012 R2 might include steps like these:

• Designing, acquiring, and implementing the underlying network infrastructure of switches, routers, access points, and other networking hardware.
• Designing the Active Directory environment using the guidelines and best practices found in the AD DS Design Guide at http://technet.microsoft.com/en-us/library/cc754678(v=WS.10).aspx.
• Purchasing system hardware that has been certified for Windows Server 2012 R2.
• Performing a pilot deployment to determine whether the planned infrastructure will meet your business needs and to anticipate any possible problems that might arise during the rollout.
• Rolling out your production infrastructure using whatever deployment tools you’ve decided to use. We examine some of these tools in Chapter 2, “Deploying servers.”

The main advantage of a greenfield deployment is that it gives you the opportunity to get it right from the start. However, businesses are always evolving and are rarely static, so even if you carefully plan for future growth you might still be faced with challenges in evolving your infrastructure to address events such as mergers, acquisitions, and spinoffs of business units. And in reality, most readers of this Training Guide who are looking to upgrade their job skills are most likely working at companies that have one or more existing Active Directory forests in place and are contemplating migrating them to Windows Server 2012 R2, which is what the next scenario is about.

Forest upgrade

Administrators of Active Directory environments have traditionally been cautious, even paranoid, about performing schema upgrades by using the Adprep.exe command-line utility. With the release of each new version of Windows Server comes a new schema version, and in the past, the task of introducing domain controllers running the new version of Windows Server into your existing Active Directory environment has required that you first prepare your forest by upgrading the schema. The reluctance that administrators have about performing such upgrades is based largely on three concerns:

• The process of upgrading a forest schema by using Adprep was often a cumbersome one on previous versions of Windows Server and involved using a variety of different credentials to log on to specific domain controllers, copy Adprep files, and run Adprep from the command line with various parameters. The more complex the process, the greater the chance of an error occurring.
• There was the possibility that something might go wrong during the schema upgrade process, resulting in a corrupt forest that requires you to perform a forest recovery, which can be a difficult and time-consuming process.
• There was the possibility that the schema upgrade might go well but result in side effects, such as enterprise applications that break and no longer function properly.

The recommended approach to avoiding such problems is to create a test environment that mirrors your production environment in terms of its Active Directory schema, network services, and business applications. By using Adprep to upgrade the schema of your test forest, you can better anticipate any problems that might arise when you upgrade the schema of your production forest. For information on how to mirror your production schema into a test environment so that you can perform such testing, see the article “Export, Compare, and Synchronize Active Directory Schemas” from the April 2009 issue of TechNet Magazine at http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx.

Clearly, these are not trivial concerns when your job as administrator potentially is at stake. So before you perform a forest upgrade, you need to be well prepared. For example:

• You need to understand the schema upgrade process and its possible impact on your environment.
• You need to have a forest recovery plan in place as a backup solution for your worst-case scenario.

Beginning with Windows Server 2012, however, Microsoft has endeavored to alleviate many of the concerns administrators often have about performing forest upgrades. For example:

• Adprep functionality is now integrated into the Active Directory Domain Services (AD DS) installation process. In most cases, this eliminates the need to separately run Adprep prior to introducing domain controllers running the new version of Windows Server into existing AD DS infrastructures running Windows Server 2008 R2.
• The new AD DS installation process includes prerequisite validation to identify potential errors before installation begins. For example, if the installation process determines that adprep /domainprep needs to be run to prepare the domain, verification is done first to ensure that the user who initiated the process has sufficient rights to perform the operation.
• The Windows Server 2012 or Windows Server 2012 R2 forest functional level does not add any new features to a forest. It ensures only that any new domain added to the forest will automatically operate at the Windows Server 2012 R2 domain functional level.
• The Windows Server 2012 or Windows Server 2012 R2 domain functional level adds only one new feature to a domain. This new feature relates to Dynamic Access Control (DAC) and therefore is unlikely to affect any existing applications and services in your environment.

Despite these improvements to performing schema upgrades and raising forest and domain functional levels, you should use careful planning and due care when completing these tasks. These issues are addressed further in Chapter 4, “Deploying domain controllers,” and in Chapter 5, “Active Directory administration.”

Existing environment

Existing businesses that currently have Windows Server 2008 R2 or earlier deployed and that want to take advantage of the new capabilities of Windows Server 2012 or Windows Server 2012 R2 can do so without ripping out their infrastructure and replacing it with a new one. All they need to do is introduce servers running Windows Server 2012 or Windows Server 2012 R2 into their environment and promote them as domain controllers. Doing this automatically upgrades the schema, and administrators can raise the forest and domain functional levels to Windows Server 2012 or Windows Server 2012 R2 with minimal fear of it having a negative impact on their existing applications and services. Of course, regardless of this, you should still be sure to first test your schema upgrade and functional level changes in a test environment that mirrors your production environment just to make sure there will be no issues that might impact your business.

Some new features of Windows Server 2012 and Windows Server 2012 R2 can be implemented into existing Active Directory environments without making significant changes to the existing forest, such as upgrading the schema or raising the forest or domain functional levels. A situation in which this might be done is when deploying new DHCP servers to take advantage of the new DHCP failover feature of Windows Server 2012 and Windows Server 2012 R2 that ensures continuous availability of DHCP services to clients. For information on how to implement this new capability, see Chapter 6, “Network administration.”

The introduction of member servers running Windows Server 2012 or Windows Server 2012 R2 into an Active Directory forest based on an earlier version of Windows Server results in a mixed environment of servers running different versions of Windows. By not introducing new domain controllers running Windows Server 2012 or Windows Server 2012 R2, administrators can continue to manage their environment by using existing tools and processes. Although this seems like a simpler and less risky approach than upgrading your forest as described previously, there are several disadvantages to following this approach:

• Some new features and capabilities of Windows Server 2012 and Windows Server 2012 R2 can be implemented only when your Active Directory environment includes domain controllers running Windows Server 2012 or Windows Server 2012 R2. These features might have limited functionality or might not work at all when your Active Directory schema hasn’t been upgraded to Windows Server 2012 or Windows Server 2012 R2 level. In general, information about such limitations might be buried in the TechNet Library documentation for Windows Server, which means you need to do some research before you try deploying Windows Server 2012 or Windows Server 2012 R2 member servers with roles and features installed in your existing Active Directory environment.
• Some of the server administration tools built into Windows Server 2012 and Windows Server 2012 R2 that are included in the Remote Server Administration Tools (RSAT) for Windows 8 and Windows 8.1 have limited or no functionality when managing servers running earlier versions of Windows Server, such as Windows Server 2008 and Windows Server 2008 R2. You might have to install additional updates on servers running these earlier versions of Windows Server to manage them using the Windows Server 2012 or Windows Server 2012 R2 server administration tools or using RSAT for Windows 8 or RSAT for Windows 8.1. For more information, see KB 2693643 at http://support.microsoft.com/kb/2693643.

So although rolling out a few Windows Server 2012 R2 member servers with a few roles and features installed might seem like a good idea and less risky than performing a forest upgrade, the gains you experience from following this approach might not be worth the effort involved.

Server consolidation

Server consolidation involves using virtualization to consolidate multiple server workloads onto a single virtualization host. With the greatly increased scalability of the Hyper-V role in Windows Server 2012 and Windows Server 2012 R2, businesses can often migrate much or even all of their existing Active Directory infrastructure based on a previous version of Windows Server and run it on a cluster of Hyper-V hosts running Windows Server 2012 or Windows Server 2012 R2. In other words, they can migrate their existing physical servers into a virtual environment. For more information, see Chapter 7, “Hyper-V virtualization.”

Private cloud

Cloud computing provides organizations with new options to increase efficiencies while reducing costs. The traditional data-center approach, in which the organization deploys and manages its own Active Directory infrastructure on-premises, has known stability and security, but the infrastructure servers involved often run at less than 15 percent utilization. Virtualizing the data center by using server consolidation can increase utilization, reduce cost, and simplify management, but this approach lacks the elasticity to rapidly meet changing demands as your business grows or experiences market changes.

Cloud computing can simplify management and reduce cost even further while providing elasticity and the perception of infinite capacity for the IT services your business uses. Cloud resources are pooled so that they can be allocated on demand as the needs of the business grow or shrink. If additional resources are needed, they can be provisioned without the need for extensive planning and testing beforehand.

Cloud computing can be provisioned according to three possible service models:

• Software as a Service (SaaS) The cloud is used to deliver an application to multiple users, regardless of their location or the type of device they are using. Compare this model with the more traditional approach of deploying separate instances of applications to each user’s PC. This approach typically is used to deliver cloud-based applications that have minimal need for customization. Examples include email, Customer Relationship Management (CRM), and productivity software. The advantage of this approach is that application activities can be managed from a single central location to reduce cost and management overhead.

  An example of a SaaS offering from Microsoft is Office 365, which provides users with secure access from anywhere to their email, shared calendars, instant messaging (IM), video conferencing, and tools for document collaboration. For more information on Office 365 for business, see http://office.microsoft.com/en-us/business/.

• Platform as a Service (PaaS) The cloud is used to deliver application execution services, such as application runtime, storage, and integration for applications designed for a prespecified, cloud-based architectural framework. This enables you to develop custom cloud-based applications for your business, which you can then host in the cloud so that your users can access them from anywhere over the Internet. PaaS also enables you to create multitenant applications that multiple users can access simultaneously. With support for application-level customization, PaaS enables integration with your older applications and interoperability with your current on-premises systems, although some applications might need to be recoded to work in the new environment.

  An example of a PaaS offering from Microsoft is Windows Azure Cloud Services, which enables you to deploy highly scalable web applications built with C#, PHP, Python, Node.js, or Java. An instance of Cloud Services represents a logical container for two types of roles: web role instances and worker role instances. The web role provides an ASP.NET programming model you can use for programmatically provisioning node instances of a web farm. The worker role exposes a programming model you can use for implementing batch processing farms with resources. For more information on Windows Azure Cloud Services, see http://www.windowsazure.com/en-us-/documentation/services/cloud-services/.

• Infrastructure as a Service (IaaS) The cloud is used to create pools of computer, storage, and network connectivity resources, which can then be delivered as cloud-based services billed on a per-usage basis. IaaS forms the foundation for the other two cloud service models by providing a standardized, flexible, virtualized environment that presents itself as virtualized server workloads. In this approach, the organization can self-provision these virtualized workloads and fully customize them with the processing, storage, and network resources needed and with the operating system and applications needed. The organization is relieved of the need to purchase and install hardware and can simply spin up new workloads to quickly meet changing demand.

  An example of an IaaS offering from Microsoft is Windows Azure Virtual Machines, which enables you to provision, deploy, and manage virtual machine instances in the Windows Azure public cloud. These virtual machine instances can be provisioned from a gallery of stock virtual hard disks (VHDs) that include different versions of Windows Server, SQL Server, and Linux. For more information on Windows Azure Virtual Machines, see http://www.windowsazure.com/en-us/documentation/services/virtual-machines/.

In the context of Windows Server 2012 R2, the cloud service model under consideration here is the IaaS model, which can be implemented by using the Hyper-V role of Windows Server 2012 R2 with Microsoft System Center 2012 R2.

When IaaS is implemented in such a way that a customer deploys the cloud on-premises in its datacenter, the solution is called a private cloud. There are several ways an organization can implement a private cloud solution:

• By having the customer build and host the private cloud in its own datacenter, using Windows Server and the System Center family of products
• By having the customer purchase a dedicated private cloud appliance with Windows Server and System Center preinstalled and configured
• By having a partner company host the customer’s private cloud

Migrating an organization’s existing Active Directory infrastructure into a private cloud sourcing model can be straightforward or complex, depending on a number of different factors. Because of this, it’s often best if you enlist a Microsoft partner to help you design and implement a solution that meets the needs of your organization.

If you want to explore the private cloud approach further, there are several places you can start:

• You can download evaluation versions of Windows Server 2012 R2 and System Center 2012 R2 from the Server And Cloud Platform page at http://www.microsoft.com/en-us/server-cloud/solutions/virtualization-private-cloud.aspx. Then you can use these platforms to create a proof of concept private cloud using documentation in the TechNet Library, such as http://technet.microsoft.com/en-us/library/gg610625.aspx.
• You can purchase an IaaS private cloud with a prevalidated configuration from server partners in the Microsoft Private Cloud Fast Track program. These offerings combine Microsoft software, consolidated guidance, validated configurations from original equipment manufacturer (OEM) partners, and other value-added software components. For more information, see http://www.microsoft.com/en-in/server-cloud/fast-track.aspx.
• You can use the Microsoft Pinpoint site to find a partner in the Microsoft Private Cloud Service Provider Program that can host a dedicated private cloud for your organization. For more information, see http://www.microsoft.com/en-in/server-cloud/find-a-partner.aspx.

Hybrid cloud

When IaaS is implemented as a combination of an on-premises private cloud solution and a public cloud service such as Windows Azure Virtual Machines, the solution is called a hybrid cloud. The hybrid cloud approach enables organizations to extend their infrastructure into the cloud for greater flexibility and agility so they can scale on demand to meet rapidly changing business requirements.

Microsoft believes that the hybrid cloud approach is the key to helping organizations cloud optimize their business. Beginning with the R2 release of Windows Server 2012, Microsoft uses the term “Cloud OS” to represent its visionary approach to how IT can deliver innovative new hybrid solutions that can address the needs and challenges that businesses are facing today. These needs and challenges include

• The need for new tools to automate datacenter provisioning, management, and monitoring in addition to tasks and workflows both in the datacenter and in the cloud. These tools must be able to manage both physical and virtual workloads on-premises and across public and service-provider clouds. They also need to be scalable, flexible, and secure.
• The challenge of managing diverse mobile devices like tablets and smartphones that are frequently personal devices owned by the users themselves rather than corporate assets. Existing technologies need to be integrated with new platforms that allow device registration and enrollment, policy-based management, and management from the cloud. There is also the challenge of delivering a secure and personalized experience on any device, anywhere and at any time.
• The need to deal with the apps users run on mobile devices. Deploying and managing these apps presents new challenges to accelerate the application life cycle, the handoff from developer to infrastructure specialists.
• The challenge of dealing with greater amounts of data than ever before. Big data needs powerful new tools for business intelligence to unlock the value of data stored both on-premises and in the cloud.
• The challenge of accomplishing all of the above without breaking ever-constrained IT budgets.

Microsoft’s Cloud OS vision for hybrid computing consists of three key platforms:

• Windows Server 2012 R2 Provides the foundation for building enterprise-class datacenter and hybrid cloud solutions that are simple to deploy, cost-effective, application-focused, and user-centric.
• System Center 2012 R2 Delivers a unified management experience across on-premises, service provider, and Windows Azure environments in a manner that’s simple, cost-effective, application-focused, and enterprise-class.
• Windows Azure Provides an open and flexible cloud platform for building, deploying, and managing applications using almost any language, tool, or framework and running them in a secure public cloud hosted in a global network of Microsoft-managed datacenters. Windows Azure also enables you to integrate your public cloud applications with your existing on-premises IT environment to enable hybrid cloud capabilities.

If you want to explore Microsoft’s hybrid cloud approach further, you can complete the following steps:

1. Begin by downloading evaluation versions of Windows Server 2012 R2 and System Center 2012 R2 and getting a trial subscription for Windows Azure from the Server And Cloud Platform page at http://www.microsoft.com/en-us/server-cloud/solutions/hybrid-cloud.aspx.
2. Next, use these platforms to create a proof of concept private cloud using documentation in the TechNet Library, such as http://technet.microsoft.com/en-us/library/gg610625.aspx.
3. After this, you can use Windows Azure Virtual Machines to deploy virtual machine instances running Windows Server 2012 R2 in the Windows Azure public cloud by using the documentation found at http://www.windowsazure.com/en-us/documentation/services/virtual-machines/.
4. Finally, learn how to use System Center 2012 R2 App Controller to manage these virtual machine instances across the private cloud and the Windows Azure platform from a single console by downloading the free ebook Microsoft System Center: Cloud Management with App Controller, which is available from the Microsoft Press blog at http://blogs.msdn.com/b/microsoft_press/archive/2013/11/26/free-ebook-microsoft-system-center-cloud-management-with-app-controller.aspx.

Deployment process

As I said earlier, there is no single approach to planning and executing deployment projects. However, there are some best practices that apply in various degrees to the different scenarios discussed earlier, and from these you can identify some of the key steps that should be involved in any deployment or migration process. I’ll briefly focus on providing some guidance for the following four steps, which are common to most infrastructure projects:

• Assessment
• Pilot testing
• Deployment/migration
• Role/feature migration

Note that to help you use the information in the upcoming sections, some of it is presented in the form of a series of questions that you can use as the basis for creating worksheets for implementing your project.

Assessment

Assessment involves determining the readiness of your organization’s infrastructure, hardware, applications, and personnel for migrating your infrastructure to Windows Server 2012 R2. Although some of this will be examined in more detail in the next lesson, here are some of the key questions that you need to address as part of the assessment process:

• Have you inventoried all the hardware in your environment?
• Do you have any tools for performing an inventory of your infrastructure?
• Is your existing server hardware capable of running Windows Server 2012 R2?
• Is your existing server hardware capable of supporting the various roles and features of Windows Server 2012 R2 that you plan to deploy in your environment?
• Will your existing storage hardware work with Windows Server 2012 R2?
• Is your network infrastructure ready for Windows Server 2012 R2?
• Are your various network appliances (for example, firewalls, VPN gateways, and so on) capable of interoperating with Windows Server 2012 R2?
• If you plan to deploy DirectAccess, do your network infrastructure and appliances fully support Internet Protocol version 6 (IPv6)? Does your Internet Service Provider (ISP) support IPv6?
• Have you inventoried all the operating systems and applications in your environment?
• Are there any operating systems or applications in your environment that have compatibility issues with Windows Server 2012 R2?
• Will you be virtualizing any of your existing operating systems or applications on Hyper-V hosts running Windows Server 2012 R2?
• Have you inventoried the server roles on each of the servers of your infrastructure?
• Is there anything you need to consider with regard to virtualizing any of the server roles currently running on your servers or migrating these roles into the cloud?
• Have you assessed your budget to ensure you have sufficient funding to purchase any hardware or software needed for your project?
• Have you assessed the potential cost savings and return on investment (ROI) your organization can achieve by migrating to Windows Server 2012 R2?
• Are your IT staff members ready for the project? Do they need any additional training?

Pilot testing

Pilot testing involves more than just installing the software and playing around with it. You should start by creating a test plan that defines the scope and objectives of the testing you want to perform. You should also define a testing methodology that describes the architecture of your test environment, your testing tools and techniques, and the type of automation you plan to use for your testing. You then need to identify the resource on which you need to perform your testing and establish a schedule for performing your various tests. Finally, you should have a process for evaluating the results of your testing to see whether the objectives you set have been achieved.

The following are some key questions that you need to address during pilot testing of Windows Server 2012 R2:

• Why are you pilot testing Windows Server 2012 R2?
• Who will be performing the testing?
• What training will the testers need before they can perform their testing?
• What are the specific objectives of your test process?
• What scenarios will you be using as the basis for performing your testing?
• What roles and features do you plan to test?
• How will you test each of these roles and features?
• What hardware will you require to perform your tests?
• What additional software will you require to perform your tests?
• Will you be using any scripts or automation as part of the test process?
• Where will you set up your test environment?
• How will you ensure that your test environment will not affect your production environment?
• What is the schedule for performing your testing?
• How will you record your results for later analysis and evaluation?

Deployment/migration

Deployment or migration of Windows servers can take several different paths, depending on the scenario you decide to implement. The choices you make concerning the deployment or migration process can be dictated by various factors, including cost, timeframe, the topology of your organization, the complexity of your infrastructure, and the server roles you currently have deployed in your environment. Some of the key questions that you need to address concerning the process include the following:

• Do you have a rollback plan in place in case something goes wrong with the deployment or migration?
• Have you performed a full system backup of the servers you’ll be migrating?

• Which of the following methods will you be using for deploying or migrating your servers?

  • New computer, in which you either deploy Windows Server 2012 R2 yourself on bare-metal hardware or purchase preconfigured server systems from your vendor and further configure the servers as desired.
  • In-place upgrade, which keeps the current hardware and upgrades the current server operating system to Windows Server 2012 R2. If you follow this approach, make sure you are aware of the supported upgrade paths for your existing server operating systems.
  • Refresh, which keeps the current hardware, saves the state information (operating system and application settings) of the current installation, wipes the hardware to remove the current operating system, performs a clean install of Windows Server 2012 R2, and restores the state.
  • Replace, which saves the state of the current installation to a network location, retires the current hardware, performs a clean install of Windows Server 2012 R2 on new hardware, and restores the state.
• Have you acquired and learned how to use tools such as Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager (SCCM), which you can use to perform server deployments and migrations? Use of these tools is discussed in Chapter 2.
• Will you be migrating any physical servers into virtual environments? If so, you might need System Center Virtual Machine Manager (SCVMM) or other tools for performing the physical-to-virtual (P2V) migrations of your server workloads.
• Will you be migrating any servers running operating systems that are no longer supported, such as Windows 2000 Server, which might require special procedures such as migrating to an intermediate operating system before migrating to Windows Server 2012 R2? For more information, see Chapter 7.
• Will you be migrating any servers across processor architectures? For example, migrating a server running a 32-bit version of Windows Server 2003 to Windows Server 2012 R2, which is only available as 64-bit software?
• Have you developed plans for migrating the roles on each of your servers? Role migration should be planned concurrently with server migration. See the next section for more information on this topic.
• Have you developed plans for migrating any business data stored on any of your servers? Will you be migrating your storage hardware and your servers? Is your business data safely backed up to prevent data loss from occurring during the process?
• Have you developed specific plans for migrating Microsoft server applications, such as Microsoft Exchange, Microsoft SQL Server, and Microsoft SharePoint? The migration of server applications such as these requires special planning and consideration. Search the TechNet Library if you require more information on planning the migration of Microsoft server applications.
• Have you discussed your deployment or migration plans with the vendors of any third-party server applications you have deployed in your environment? Will the new operating system require a new version of these applications?
• Have you developed plans to ensure business applications and services remain available to users during the deployment or migration process?
• Have you informed your user population about any possible service interruptions or problems that might arise during the deployment or migration?
• Have you laid out a schedule for performing your migrations and determined the order in which you’ll be deploying or migrating your servers?
• Have you assigned responsibilities to different members of your deployment and migration team?
• Have you thoroughly tested your deployment and migration plans in a test environment that mirrors your current production network?

Role/feature migration

A key aspect of server deployment is the migration of server roles and features together with configuration settings and data. To migrate roles and features from earlier versions of Windows Server to Windows Server 2012 or Windows Server 2012 R2, you can use the Windows Server Migration Tools. These tools include best-practices documentation and are designed to ensure the role and feature migration process goes smoothly and without errors.

Windows Server Migration Tools can be installed on the following operating systems:

• Windows Server 2003 with Service Pack 2
• Windows Server 2003 R2
• Full installation option of Windows Server 2008
• Full installation option of Windows Server 2008 R2
• Server Core installation option of Windows Server 2008 R2
• Server with a GUI installation option of Windows Server 2012
• Server Core installation option of Windows Server 2012
• Server with a GUI installation option of Windows Server 2012 R2
• Server Core installation option of Windows Server 2012 R2

The source server is the server from which you are migrating the role or feature, and the destination server is the server to which you are migrating the role or feature. For example, the source server might be running a Full installation option of Windows Server 2008 R2 and the destination server might be running a Server Core installation option of Windows Server 2012 R2. The Migration Tools must be installed on both the source and destination servers, and you must be a member of the Administrators group on both servers.

The following migration paths are supported:

• Migrating between 32-bit and 64-bit architectures
• Migrating between physical machines and virtual machines
• Cross-subnet migrations

The following migration paths are not supported:

• Migrating between source and destination servers that have different system UI languages.
• Roles on the Server Core installation option of Windows Server 2008 cannot be migrated because the Microsoft .NET Framework is not available on this installation option.

The sections that follow demonstrate how role and feature migration can be performed.

Installing the Migration Tools on the destination server

The following procedure shows how to install and configure the Migration Tools on a destination server running Windows Server 2012 R2. The goal is to be able to migrate a role such as the DHCP Server role or the Windows Server Update Services (WSUS) role from an existing server running Windows Server 2008 R2 to a new server running Windows Server 2012 R2. To install the Migration Tools on the destination server, complete the following steps:

1. Open a Windows PowerShell session with elevated rights on a server running Windows Server 2012 R2 in your environment.

2. Execute the following command to install the Windows Server Migration Tools feature on the remote server running Windows Server 2012 R2 and named SERVER7:

   Install-WindowsFeature Migration –ComputerName SERVER7

   If the local server running Windows Server 2012 R2 you are logged on to is a Server Core installation, type powershell.exe before executing the Windows PowerShell command just shown.

   If the local server running Windows Server 2012 R2 you are logged on to is a Full installation, you can also install the Migration Tools on the remote server by launching the Add Roles And Features Wizard from Server Manager.

3. Open an elevated command prompt by typing cmd in your elevated Windows PowerShell session and change the current directory as follows:

   Cd %systemroot%\system32\ServerMigrationTools

4. Create a deployment folder on the destination server by running the SmigDeploy.exe utility. This utility creates an installation package for performing the migration and places it in a new folder named C:\downloads\<subfolder>, where <subfolder> depends on the operating system version and architecture of the source server. For example, if the source computer has AMD64 architecture and is running Windows Server 2008 R2, run SmigDeploy.exe using these parameters:

   SmigDeploy.exe /package /architecture amd64 /os WS08R2 /path C:\windows

   This creates a new deployment folder named C:\downloads\SMT_ws08R2_amd64 on the destination server and copies the Migration Tool files to the folder.

5. Copy the deployment folder to the local drive of the source computer running Windows Server 2008 R2 by using any appropriate method.

For more information on installing and using the Windows Server Migration Tools on Windows Server 2012 or Windows Server 2012 R2, see http://technet.microsoft.com/en-us/library/jj134202. There are also specific role and feature migration guides available on TechNet at http://technet.microsoft.com/en-us/library/dn486809.aspx for Windows Server 2012 and at http://technet.microsoft.com/en-us/library/dn486773.aspx for Windows Server 2012 R2.

Installing the Migration Tools on the source server

The following procedure shows how to install and run the Migration Tools on a source server running Windows Server 2008 R2 to which you have already copied the deployment folder from the destination computer. Note that additional steps might be required for migrating certain roles, such as the Hyper-V role, the Routing And Remote Access Services role, and others. To install the Migration Tools on the source server, complete the following steps:

1. Open a Windows PowerShell session with elevated rights and execute the following command to load the Server Manager module:

   Import-Module ServerManager

2. Install the Windows Server Migration Tools feature by running this command:

   Add-WindowsFeature Migration

3. Note that if your source server is running an earlier operating system such as Windows Server 2008 or Windows Server 2003, you also need to install the Microsoft .NET Framework and Windows PowerShell on the source computer and then run SmigDeploy.exe on it to register the Windows Server Migration Tools cmdlets into Windows PowerShell.

You can now launch the Migration Tools from either the destination server or the source server. For example, to launch them from a destination server running Windows Server 2012 or Windows Server 2012 R2, right-click the Windows Server Migration Tools tile on the Start screen and click Run As Administrator on the app bar, as shown here:

This opens a custom Windows PowerShell session from which you can run the various Windows Server Migration Tools cmdlets, as shown in Figure 1-1.

For help with the syntax of these cmdlets, use the Get-Help cmdlet. For more information on installing the Windows Server Migration Tools on Windows Server 2008 R2 and earlier, see http://technet.microsoft.com/en-us/library/dd379545(v=WS.10).aspx.

Lesson summary

• Each type of infrastructure migration scenario (greenfield, forest upgrade, mixed environment, server consolidation, private cloud, hybrid cloud) has both benefits and challenges for organizations wanting to take advantage of the new features and capabilities found in Windows Server 2012 and Windows Server 2012 R2.
• Forest upgrades to Windows Server 2012 and Windows Server 2012 R2 are simpler than with previous Windows Server versions because of the integration of Adprep.exe into the AD DS role installation process.
• Four key steps for any infrastructure migration project are pilot testing, assessment, server migration, and role and feature migration.
• The Windows Server Migration Tools ease the process of migrating roles and features from previous Windows Server versions to Windows Server 2012 or Windows Server 2012 R2.

Lesson review

Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. Which of the following are disadvantages of the existing environment deployment scenario? (Choose all that apply.)

   1. It gives you an opportunity to get it right from the start when it comes to implementing an infrastructure based on Windows Server 2012 R2.
   2. Some new features and capabilities of Windows Server 2012 R2 might have limited functionality or might not work at all when this deployment scenario is implemented.
   3. Server management might become more complex because of the need to use separate tools for managing servers running Windows Server 2012 R2 and those running earlier Windows Server operating system versions.
   4. It can help your organization improve server utilization and reduce costs.

2. Which of the following is not an enhancement that Microsoft made in Windows Server 2012 and Windows Server 2012 R2 to alleviate some of the concerns administrators often have about performing forest upgrades? (Choose all that apply.)

   1. Adprep functionality is now integrated into the AD DS installation process.
   2. The new AD DS installation process includes prerequisite validation to identify potential errors before installation begins.
   3. The Windows Server 2012 and Windows Server 2012 R2 forest functional levels add several new features to a forest.
   4. The Windows Server 2012 and Windows Server 2012 R2 domain functional levels add only one new feature to a domain.

3. Which of the following migration paths is not supported by the Windows Server Migration Tools?

   1. Migrating between x86-based and x64-based architectures
   2. Migrating between source and destination servers that have different system UI languages
   3. Migrating between physical machines and virtual machines
   4. Cross-subnet migrations

4. Which Windows PowerShell cmdlet for the Windows Server Migration Tools can you use to get the set of all Windows features that can be migrated from the local server or from a migration store?

   1. Export-SmigServerSetting
   2. Send-SmigServerData
   3. Get-SmigServerFeature
   4. Import-SmigServerSetting