Top 5 Roles for Deploying Windows Server 2012

Although Windows Server 2012 has been out for some time, few organizations have deployed it in their production environments. This isn't a reflection on Server 2012, which in my opinion is by far the best server OS that Microsoft has released (surpassing even Windows Server 2008 R2). Rather, it's an artifact of the way that organizations deploy server OSs. The lag between the release and general adoption of a server OS can stretch to years. This lag is likely to be even more pronounced with Server 2012, given that existing products such as Microsoft Exchange Server 2010 and SharePoint Server 2010 aren't supported on the OS. Some organizations will wait until they're ready to transition to Exchange Server 2013 and SharePoint Server 2013 before adopting Server 2012.

For those just beginning to consider deployment, this article details the steps to deploy Server 2012 in five common scenarios: as an Active Directory (AD) domain controller (DC), as a file server, and as the host OS for SQL Server 2012, Exchange 2013, and SharePoint 2013.

Side-by-Side Features

With Server 2008 R2, you didn't need to re-use the installation media after you installed the product. The installation process copied to a folder on the local hard disk all the required files for adding features. If you wanted to add a new role (e.g., AD, Background Intelligent Transfer Service—BITS), all you needed to do was run the wizard and you were on your way.

This isn't the case with Server 2012. To reduce the size of the Server 2012 installation footprint, Microsoft hasn't included all roles and features in the files that are copied when the OS is installed. Therefore, some features require access to the installation media when you try to install them by using the Add Roles and Features Wizard. One feature in particular that trips up many administrators when managing Server 2012 is the installation of .NET Framework 3.5 features.

When you attempt to install these features, you'll be prompted to enter an alternate source path, as Figure 1 shows. If the installation media is present, the alternate source path is the \sources\sxs folder. If the computer is connected to the Internet, then Server 2012 downloads the required files directly from Microsoft. You can also specify a network location, so creating a share and putting the sxs folder on that share ensures that you won't be scratching around for the installation media when you need it.

With Server 2012, you can install roles and features by using the Add Roles and Features Wizard or the Install-WindowsFeature Windows PowerShell cmdlet. If you use the cmdlet to install .NET Framework 3.5, you'll need to specify the source location in the command. This location can be the \sources\sxs folder of the installation media, an accessible install.wim file, or a parallel installation of Server 2012.

For example, if the installation media is located on volume E, you can install .NET Framework 3.5 features by running the following PowerShell command:

Install-WindowsFeature NET-Framework-Core -Source E:\Sources\SxS

.NET Framework 3.5 tends to trip up people because many products that run on Windows Server need it as a prerequisite. Unless your Server 2012 installation is connected to the Internet, you'll need to remember to have the installation media handy.

Active Directory Domain Controller

In previous versions of Windows Server, you promoted a computer to DC by running the dcpromo.exe utility. With Server 2012, the process is a little different. Many separate steps, such as having to run adprep.exe to prepare the forest and domain separately, are handled automatically when introducing a DC. There are numerous improvements in AD, including better support for virtualized DCs, DC cloning, and group managed service accounts. In Active Directory Administrative Center, you'll now find tools that vastly simplify the process of deploying fine-grained password policies and an intuitive interface for using Active Directory Recycle Bin. To learn more about the improvements in AD, see the Microsoft article "What's New in Active Directory Domain Services (AD DS)."

Before you deploy the DC role on a computer, you should do the following:

• Configure the computer with a static IPv4 address. Although you can configure a DC with an IP address that's assigned through a DHCP reservation, the setup wizard will recommend that you configure a static IPv4 address on the DC.
• Name the computer. When you install Server 2012, the computer is assigned a random name. Provide a meaningful name that describes the computer's role and location. For example, you might name the first DC in the city of Melbourne Melbourne-DC-1.
• Decide whether the DC will also function as a DNS server and as a Global Catalog (GC) server. Most administrators deploy the DNS role with DCs. You can also choose to configure the DC as a GC server or enable universal group membership caching.
• Decide on the Directory Services Restore Mode (DSRM) password. You need a password to perform directory restore mode operations. It's a good idea to have a uniform password across all DCs in your organization, rather than separate passwords for each DC. Uniform passwords ensure that restore operations can run more smoothly than they might if each DC has its own DSRM password.

To configure Server 2012 as a DC, perform these steps:

1. In the Server Manager console, click the Manage menu, and then click Add Roles and Features.
2. On the Select installation type page, choose Role-based or feature-based installation, as shown in Figure 2.
   

   

3. From the pool of servers, choose the server on which you want to install AD. Server 2012 allows you to manage multiple servers simultaneously, so you can use this wizard to deploy roles such as an AD DC to a local or remote server.
4. On the Select server roles page, choose Active Directory Domain Services. When you do this, you'll be prompted to install the associated Remote Server Administration Tools if they haven't already been installed locally.
5. Click Next until you reach the page on which you can click Install. Click Install and the AD Directory Services binaries will be installed. Click Close to dismiss the Add Roles and Features Wizard.
6. On the All Servers Task Details and Notifications page, click Promote this server to domain controller.

Performing all these steps installs the AD components but doesn't actually promote the computer to DC. To do that, you'll need to perform these steps:

1. In Server Manager, click the AD DS workspace, and then click Configuration required for Active Directory Domain Services.
2. In the All Servers Task Details and Notifications dialog box, which Figure 3 shows, click Promote this server to a domain controller.
   

   

3. On the Deployment Configuration page, you'll be asked whether to add a DC to an existing domain, add a new domain to an existing forest, or add a new forest.
4. On the Domain Controller Options page, which Figure 4 shows, choose the domain and forest functional level. Also choose whether you want the DC to function as a DNS server or GC server (the first DC in an organization must always be a GC server). Specify the DSRM password.
   

   

5. If you've chosen to deploy a DC, you'll be given the option of creating a DNS delegation.
6. If you're creating a new forest or a new domain, you'll be provided with an automatically generated NetBIOS name for the domain. This name can be modified if necessary.
7. On the Paths page, which Figure 5 shows, you can specify the database, log files, and SYSVOL folder to be used on the DC. In most cases, using the defaults is appropriate.
   

   

8. After you review your options, you can view a script that performs the installation. Figure 6 shows the use of the Install-ADDSForest PowerShell cmdlet to deploy and configure the DC role.
   
9. After you've reviewed the selected installation options, a prerequisite check is performed. Assuming that the check is successful, you can install the DC role. The server will reboot to complete the promotion.

File Server

The file server role is the most commonly deployed role for computers running Server 2012. Almost every organization with Windows client OSs has at least one server functioning as a file server.

With Server 2012, Microsoft put a lot of work into improving the Server Message Block (SMB) protocol. File servers running Server 2012 have much better throughput than those running earlier versions of the Windows Server OS. File servers running Server 2012 can handle more clients than file servers running Server 2008 R2 and are much less likely to choke under heavy load. (You can find out more about the improvements in SMB 3.0 in the Microsoft article "Server Message Block Overview.")

In addition to the improvements to the SMB protocol, Server 2012 also supports storage spaces, a technology that allows you to create flexible and fault-tolerant virtual drives using multiple disks. Storage spaces are built into the OS, so you don't need to add any roles or features to use them. You can find out more about Storage Spaces in the Microsoft article "Storage Spaces Overview."

Deploying the File Server Role

The default installation of Server 2012 includes the file server role, so you can start sharing files immediately after completing installation. However, most organizations have more complicated needs, in which case you'll want to deploy more than one file server. The following role services can be deployed to computers running the full version or Server Core installation of Server 2012:

• File Server—Provides basic access to shared folders. This role is installed by default on a computer running Server 2012.
• BranchCache for Network Files—Allows the server to support BranchCache functionality, allowing files served to be stored on BranchCache clients across the WAN.
• Data Deduplication—Reduces disk utilization by storing only a single copy of data on a volume.
• DFS Namespaces—Allows you to create DFS namespaces.
• DFS Replication—Provides synchronization of files across branch offices.
• File Server Resource Manager—Allows you to create file screens, manage folder-level quotas, create file classifications, and generate storage reports.
• File Server VSS Agent Service—Allows applications that store data on the file server to create Volume Shadow Copy Service (VSS) snapshots.
• iSCSI Target Server—When installed, allows Server 2012 to function as an iSCSI target.
• iSCSI Target Storage Provider (VDS and VSS)—When installed, applications connected to an iSCSI target on the local server can create VSS snapshots.
• Server for NFS—Allows Server 2012 to function as an NFS server. NFS is primarily used by UNIX and Linux clients.
• Storage Services—Provides storage-management functionality.

You can implement data deduplication only on the volumes that do not host the OS.

Managing the File Server

A big improvement in Server 2012 is the centralized nature of file and storage server management. In Server 2008 R2, you needed to use disparate consoles to manage file server–related tasks. For example, you used separate consoles to manage volumes, shares, iSCSI targets, file screens, and quotas. In Server 2012, these have all been co-located in the File and Storage Services section of the Server Manager console, as Figure 7 shows.

Choose the item that you want to work with—such as volumes, disks, shares, or iSCSI—from the list of objects in the left pane. You can then manage the details of those objects in the right pane. Remember Server 2012's multi-server management paradigm; you can use this console to manage File and Storage Services on multiple servers, not just on the server where you've signed on. Being able to view the status of file shares and volumes across the organization from one console is far more efficient than the process used in Server 2008 R2 and earlier.

To create a new shared folder, perform the following steps:

1. In Server Manager, click File and Storage Services.
2. In File and Storage Services, click Shares.
3. Next to Shares, click Tasks, and then click New Share.
4. In the New Share Wizard, which Figure 8 shows, choose between file share profiles.
   

   

For most uses, the SMB Share - Quick option is appropriate. When you choose this option, specify the share location, name, permissions, and whether you want to enable features such as caching, access-based enumeration, BranchCache, and encrypted data access. Choosing the SMB Share - Quick option doesn't restrict you from later configuring advanced options, such as quotas and file screens. (Use the NFS options only if you're providing shared files to UNIX or Linux clients.)

SQL Server 2012

SQL Server is a prerequisite of many other Microsoft products, including the Microsoft System Center suite and SharePoint Server 2013. You can install SQL Server 2012 with Service Pack 1 (SP1) on computers running both the standard GUI and Server Core versions of Server 2012. (SQL Server is different than products such as SharePoint and Exchange, in that previous versions of SQL Server are supported on Server 2012. You can see the list of SQL Server editions and versions that Server 2012 supports by navigating to the Microsoft article "Using SQL Server in Windows 8 and Windows Server 2012 Environments." This article concentrates on SQL Server 2012 because you're more likely to deploy the most recent version of SQL Server on the most recent version of the Windows Server OS.)

SQL Server 2012 has the following requirements:     

• .NET Framework 3.5 SP1 and .NET Framework 4.0
• PowerShell 2.0 or later (included by default with Server 2012)
• Microsoft IIS (required if you're installing SQL Server Reporting Services—SSRS)

SQL Server 2012 comes with a prerequisite checker that allows you to identify any missing components before they block you from installing the product. SQL Server 2012 supports the use of group managed service accounts and virtual accounts, defaulting to virtual accounts when installed on Server 2012. (You can view the SQL Server 2012 software and hardware requirements in the Microsoft article "Hardware and Software Requirements for Installing SQL Server 2012.")

Installing SQL Server in a default configuration, in which you install only the database engine and the default management tools, involves performing these steps:

1. On the splash screen, select New SQL Server stand-alone installation, or add features to an existing installation on the Installation tab.
2. The Setup Support Rules check will ensure that the basic requirements for installation have been met. Another check later in the process looks for feature-specific requirements. During this process, updated installation files can automatically be downloaded from the Microsoft website. The setup files are installed, allowing the next steps in the installation process to continue.
3. During the next stage in the installation process, enter the product key and agree to the license terms.
4. On the Setup Role page, choose whether to install specific features, SQL Server PowerPivot for SharePoint, or all features with defaults. In most cases, such as when SQL Server is supporting another product such as System Center 2012 Configuration Manager or Operations Manager, you need to install only a few features. As with any product, you should install only the features that you know you need, rather than the ones that you think you might need.
5. On the Feature Selection page, which Figure 9 shows, select the features that you want to install. (Figure 9 shows Database Engine services being installed. The management tools are also being installed, although that isn't visible in the figure.)
   

   

6. SQL Server performs another check to determine whether the desired configuration can be installed or whether there are blocking issues.
7. On the Instance Configuration page, choose whether to install SQL Server as a default or a named instance. If other instances are already installed on the server, they'll be listed in this dialog box.
8. SQL Server setup will then recommend that you use a default set of virtual service accounts. You can specify custom service accounts at this point, although the benefit of using virtual service accounts is that the OS manages the account's password, ensuring that it's changed on a regular basis. You can also choose which collation the SQL Server instance will use. If you're installing a SQL Server instance to support a specific product, you should determine whether the product requires a specific collation.
9. On the Database Engine Configuration page, which Figure 10 shows, choose which users will have SQL Server administrator privileges.

   

   
   On this page, you also choose the authentication mode. Most modern applications use Windows authentication, but some older applications might require mixed mode, which allows you to use SQL Server authentication.
10. At this point, SQL Server is ready to install. Although installing SQL Server doesn't require that you reboot the server, it's generally a good idea to do so. Then use SQL Server Management Studio to connect to the instance and verify that everything works.                    

Exchange Server 2013

You can install Exchange 2013 on computers running Server 2008 R2 or Server 2012. To prepare AD for the deployment of Exchange 2013, you need to have .NET Framework 4.5 and Windows Management Framework 3.0 installed. (Both are included with the default installation of Server 2012 and don't need to be installed separately.) You also need to have deployed the AD Directory Services–related Remote Server Administration Tools. You can install these tools by using the Add Roles and Features Wizard or by executing the following PowerShell command:

Install-WindowsFeature RSAT-ADDS

Exchange 2013 also requires that the schema master, GC server, and at least one DC in each site run Windows Server 2003 with SP2 or later. The forest functional level must be Windows Server 2003 or later. It's fairly safe to assume that if you're thinking of deploying Exchange 2013 on Server 2012, your organization's infrastructure meets these requirements.

If you're going to install both the Mailbox server and Client Access server roles on a computer running Server 2012, you can install them all by running the PowerShell command that Listing 1 shows.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, 
NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, 
RSAT-Clustering-CmdInterface, Web-Mgmt-Console, WAS-Process-Model, 
Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, 
Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-
Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, 
Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-
Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, 
Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-
Auth, Web-WMI, Windows-Identity-Foundation

You'll need to restart the server after the command executes. You'll then need to install the following software, which you can download from the Microsoft website, in this order:

1. Microsoft Unified Communications Managed API 4.0, Core Runtime (64-bit)
2. Microsoft Office 2010 Filter Pack (64-bit)
3. Microsoft Office 2010 Filter Pack SP1 (64-bit)

After you've installed these components, you can install Exchange 2013 by performing the following steps:

1. Run Setup from the installation media. You'll be prompted to check for updated installation files, to agree to the license agreement, and to decide whether to provide feedback to Microsoft.
2. On the Server Role Selection page, which Figure 11 shows, you can choose whether to install the Mailbox server role or the Client Access server role.
   

   

   
   You can also configure the Exchange 2013 installation routine to automatically install any roles and features that are required to support Exchange, although it's better to do this prior to starting the installation routine.
3. You'll be prompted to specify the location of the Exchange installation files and to choose a name for your Exchange organization. You can also choose to apply AD split permissions, if you want to separate the administration of AD and Exchange.
4. Choose whether to disable native malware scanning. (The only reason that you'd do so is if you're using a third-party product for malware protection on your Exchange server.)
5. The installation routine performs a prerequisite check and analysis. After these checks are passed, you can install Exchange 2013. As long as you have the AD Directory Services Remote Server Administration Tools installed, any preparation of AD prior to deployment will occur automatically.
6. After installation completes, you can verify the success of the installation by using a web browser to navigate to the Exchange Administrative Center, which Figure 12 shows. A link to this page is provided on the final page of the installation wizard.
   

   

As you use a web browser to manage Exchange 2013, you might find it useful to pin the Exchange Administrative Center website address to the taskbar of the computer on which you have installed Exchange 2013. (You can find the Exchange 2013 prerequisites listed in the Microsoft article "Exchange 2013 System Requirements.")

SharePoint 2013

There are many ways to install SharePoint 2013. The simplest is to install a single server using a built-in database.

The SharePoint Products Preparation Tool installs the following roles, features, and additional software:

• Web Server (IIS) role
• Application Server role
• .NET Framework 4.5
• SQL Server 2008 R2 SP1 Native Client
• Microsoft WCF Data Services 5.0
• Microsoft Information Protection and Control Client (IPC)
• Microsoft Sync Framework Runtime v1.0 SP1 (x64)
• Windows Management Framework 3.0, which includes PowerShell 3.0
• Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously WIF 1.1)
• Windows Server AppFabric
• Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server

You can run this tool by running prerequisiteinstaller.exe from the root folder of the SharePoint 2013 installation media. Unless you have copies of all the required local files in addition to the roles and features, such as the SQL Server 2008 R2 SP1 Native Client, you need to have an Internet connection to successfully run this tool. Running the preparation tool necessitates one or more reboots. The preparation tool will continue to run after reboot, until all prerequisites have been installed or enabled, as Figure 13 shows.

After all the prerequisite components have been installed, you can install SharePoint Server 2013 by performing the following steps:

1. Provide your SharePoint 2013 product key and agree to the license terms.
2. Choose either a complete or standalone installation. The latter installs a local instance of SQL Server 2008 R2 Express with SP1 and isn't recommended for production environments. If you choose a complete installation, you need to have administrative access to an instance of SQL Server 2008 R2 SP1 or later. The installation of SQL Server 2012 described earlier in this article can function in this role.
3. After installation is complete, you must run the SharePoint Products Configuration Wizard. This wizard is launched by default when you complete the installation wizard.
4. When running the configuration wizard and setting up a new SharePoint 2013 deployment, choose to create a new server farm. Specify the location of the database name and the account of a user that has administrative permissions on the instance, as Figure 14 shows.
5. Configure a farm passphrase. You'll use this passphrase whenever you want to join new servers to the SharePoint 2013 farm.
6. On the Configure SharePoint Central Administration Web Application page, choose a port number for the web application or allow one to be selected at random. You can also choose between NTLM and Kerberos authentication, with NTLM being the default value.

When configuration is complete, as Figure 15 shows, you can connect to the SharePoint Central Administration website to complete the configuration of SharePoint 2013. (The Microsoft article "Hardware and Software Requirements for SharePoint 2013" shows the requirements for a single SharePoint server with a built-in database.)

Straightforward Deployment

This article has described how to deploy common Server 2012 roles. Although I've shown you how to deploy products such as Exchange 2013, SharePoint 2013, and SQL Server 2012, I haven't covered the post-installation configuration steps that you need to take to customize each of these products before deploying them to a production environment. Deployment of these roles and products on Server 2012 is straightforward. The only thing that you need to do is review the system requirements pages on TechNet and ensure that the appropriate roles and features are installed or available before you begin deployment.