After focusing on the File Server migration recommendations in the last post, it's time to focus on Web Server migration recommendations.
Upgrade on new hardware
Hardware requirements define the minimum hardware required to run the Windows Server 2012 R2 server, but your actual hardware requirements might be greater, depending on the server’s load and responsiveness and the services that it hosts. Each role service and feature places a unique load on network, disk I/O, processor, and memory resources. For example, the File Server role places different stresses on server hardware than the DHCP role does.
Confirm that running this workload on a physical server is required. Running workloads as Virtual Machines offer more flexibility and tend to be more cost effective
Upgrade on virtual machine
Windows Server 2012 R2 can be deployed on a virtual machine in your Microsoft Hyper-V or other hypervisor environment for increased operational efficiency, flexibility, and ease of management. Windows Server 2012 R2 virtualized deployments need to match the same hardware specifications as physical deployments. For example, when you create a virtual machine to host Windows Server 2012 R2, you need configure the virtual machine with enough memory and hard disk space.
When deploying Virtual Workloads verify you are building with capacity to support all workloads that the Virtualization Host supports
Web Server Role
Here we discuss migrating the Web Server Role and using the Web Deploy extension. For more information about migrating roles and features in Windows Server, go to
Windows Server 2003 was a great operating system in its day—but that day was more than a decade ago, and Microsoft has made major advancements across the board in scalability, performance, reliability, automation, security, and virtualization. Migrating your web server or web server farm takes careful thought and planning to take advantage of the improvements in the Windows Server operating system. Some important things to consider are:
- Web pointers
- Webpage names
- Web links
- Web references
- Web attachments
- Keeping and/or changing Cascading Style Sheets (CSS)
- New hardware: Moving from x86 to x64
- Virtualization: Implementing Hyper-V
- Consolidation: Moving to cloud within Microsoft Azure
- Security: Applying patches and Windows updates
- Application migration: Moving Visual Studio Online to Microsoft Azure
For more information, read Step-By-Step: Migrating Web Servers to Windows Server 2012 R2 at
Web Deploy (Including Features Content)
Web Deploy is a Microsoft-supported extension that enables simplified deployment of web applications and sites to Internet Information Services (IIS) servers. You can use Web Deploy to synchronize content and configurations between IIS servers, or to migrate an IIS server to a newer version of IIS.
Synchronization and migration
You can use Web Deploy to synchronize sites, applications, or servers across an IIS environment. This enables multiple like-configured IIS nodes. With multiple-node configuration, it's easier to migrate and retire a single node than to migrate a single IIS server that provides a web app.
Web Deploy provides the following features to simplify the packaging and exporting of IIS components:
- Seamless integration with IIS Manager (7.0 and newer) and Visual Studio (2010 and newer) to create and deploy packages to a server, both locally and remotely.
- Interoperability with WebMatrix to deploy and download web apps.
- Seamless integration with the Web Platform Installer to install community web apps.
- Web application packaging: Ability to package a web app or an entire site, including the associated databases.
- Packages access control lists (ACLs), Component Object Model (COM), global assembly cache (GAC), and registry settings.
- Supports both live servers and zipped packages as the source or destination file for the packaged web app.
- Web application deployment: Administrative privileges are not required to deploy web apps.
- Adds powerful parameters to change text in files when deployed (for example, prompting to replace a connection string when deploying from QA to staging environments).
- Integrates with the IIS Web Management Service for remote deployment by non-administrators.
- Provides server administrators with granular control over operations and tasks that can be delegated to non-administrators.
- Web server synchronization and migration: Ability to synchronize or migrate an entire web server, website, or application.
- Synchronizes only the data that has changed.
- Detects missing dependencies during synchronization.
- Automatically gathers content, IIS configuration, Secure Socket Layer (SSL) certificates, and ASP.NET configuration when a website is synced.
- Website backup: Ability to automatically back up websites before making changes.
- Administrators can configure Web Deploy so that it creates and stores a backup of websites on the server.
- End users can directly restore their websites without administrator involvement.
You can use virtualization to address many business and IT requirements, but you can't virtualize all servers and applications. Before your organization implements virtualization, you need to identify the apps and servers that are the best candidates for it.
You must consider several factors when deciding whether to virtualize server workloads:
- Hardware requirements: Typically, virtual machines require approximately the same resources as a physical server. For example, if you have a physical server that uses 1 GB of RAM, you should expect the virtual machine to use that same amount—assuming it runs the same operating system and apps.
Note: When you plan resource utilization on your host computer, remember that the host computer requires additional resources for running the virtual machine. For each additional GB of memory that you assign to the virtual machine, there is a potential overhead of 8 MB on the host computer. For example, if the virtual machine requires 4 GB of RAM, there is a potential overhead of 32 MB on the host computer.
- Hardware utilization: In some cases, a server workload may require hardware resources that make it impractical to deploy the workload on a virtual machine. For example, if the server workload requires more than half of the hardware resources available on a virtualization host, the benefit of server consolidation may be nil.
Note: When evaluating a virtual machine's hardware requirement, ensure that you are using the actual hardware utilization rather than the physical hardware. You can deploy a physical server that is using only 5 percent of its current hardware resources on a virtual machine that has much lower hardware resources.
- Compatibility: It's important to determine if the application can run in a virtualized environment. Business apps range from simple executables to complex, distributed, multi-tier products. Be sure to consider the requirements for specific components of distributed applications, like the need to communicate with other infrastructure elements or to have direct access to system hardware.
Note: Applications and services that have specific hardware or driver requirements generally are not good virtualization candidates. For example, an app may not be ideal for virtualization if it contains low-level drivers that require direct access to system hardware. This may not be possible through a virtualization interface, and it can negatively affect performance.
- Supportability: You need to evaluate whether a virtualized environment will support the operating system and the application. You can verify vendor support policies for operating system and application deployments that use virtualization technologies.
- Licensing: You need to verify if the application can be licensed for use in a virtual environment. Reducing the licensing costs of multiple apps or operating systems can result in significant savings—a strong financial reason for virtualization.
- Availability requirements: Most organizations need to make at least some apps highly available for users. While some of these apps provide built-in options for enabling high availability, others can't easily be made highly available outside a virtual machine environment. When deciding whether to virtualize a server, remember to assess if the application has high availability options, if the virtual machine environment supports those options, and if failover clustering can be used to make the virtual machine highly available.
With Windows Server 2012 R2, your organization can run its IT infrastructure on virtualization technologies or connect it to external cloud services. The Windows Server edition that you deploy depends on the planned level of virtualization.
Designing Virtual Machines
For anyone developing a virtualization strategy, one key goal is to simplify and standardize the host computer and virtual machine configuration as much as possible. Consider the following general guidelines, which apply to all virtual machines:
- Develop a small number of standard virtual machine builds. To streamline virtual machine deployment and management, develop a set of standard virtual machine builds. For example, consider creating standard low-end, medium, and high-end server builds. Assign a standard CPU and memory configuration for each role. Also, consider configuring each virtual machine with a standard 50 GB system partition and providing additional disks on which to store data or install apps. Finally, consider using SCSI controllers for all hard disks, other than the disk that contains the boot and system partition. Windows Server 2012 R2 enables you to add new VHDs that connect to a SCSI controller without having to restart the server.
- Plan virtual machines for specific server roles. Although you should be able to configure most virtual machines with the same basic disk and operating system configuration, the actual physical requirements for each virtual machine varies. For example, some virtual machines require significantly more RAM or CPU resources than others. To design the actual physical requirements for a virtual machine, you should:
- Monitor the servers before virtualizing them. Collect performance data on the servers to evaluate how specific applications perform on physical servers. If an application uses a low percentage of a physical server's hardware resources, deploy a virtual server with significantly less capacity to run the same app.
- o Configure each virtual server similarly to the hardware configuration that the application requires on physical servers. Virtualizing a server does not change the hardware resources required by the server.
- If your organization runs more than two virtual machines on the same hardware but still doesn't require an unlimited number of virtual licenses, you might choose to install a second instance of Windows Server 2012 R2 Standard on the server. In this scenario, you would be licensed to run four virtual machines on the same hardware.
- Consider other options for ensuring physical server utilization. The goal in most organizations is to use all servers adequately, whether they are physical or virtual. For example, you can use the SQL Server or Exchange Server Mailbox servers more fully by deploying additional SQL Server instances or moving more mailboxes to the server.