Plan for Windows Server 2008 R2 Roles

• Active Directory–related roles

• Hyper-V

• Remote Desktop Services

1. Plan for Active Directory

One of the most common functions installed on a Windows Server 2008 R2 server is Active Directory (AD). AD governs authentication and access to your network applications and resources. AD provides the directory services that allow you to organize and secure your network infrastructure. Before you begin to plan the AD environment, you need to understand some of the common terminology used in a typical AD deployment:

Forest This is the main and first logical structure for your directory structure. The forest is the main security boundary and will contain all the objects for your directory, starting with domains. Domains inside a single forest will automatically have a two-way transitive trust with all the other domains in the forest. The forest also defines several things for all the domains in the forest. First, the forest defines the schema for the AD structure. The schema contains the definition and attributes for all the objects in the forest. The schema is extremely important to the AD structure, because it defines the various objects such as the users and groups. It will also define what properties make up those objects; an example of a property would be a last name or phone number. Also, with some enterprise-wide applications, such as email, the schema will get extended to support any new objects or properties needed by the new application. Some applications need to extend the schema to provide the proper objects for the application to function. Second, the forest also contains the replication information for the directory to properly function. Lastly, the forest holds the global catalog, which provides search capabilities for the forest.

Domain Domains are how you divide the forest into logical units. Domains are created to help control data replication and are instrumental in allowing your directory structure to scale. The domain contains all the security principals (for example, users and groups are stored here) for your organization. The domain also handles the authentication for your network as well and through this provides the base for securing your resources. The domains also helps manage trusts. The domain is also considered one of the main security boundaries for your network. Domains not only allow you to quickly segment resource access for users but also provide a tool to delegate administrative tasks.

Trees Inside forests you have trees; these are where your domains reside. A tree is where you have domains sharing a common namespace as well as a security context for sharing the many resources located in a domain. Any domains you install underneath the first domain become child domains and get a new DNS name. However, the name inherits the parent domain name. For example, if the parent domain is called admin.com, you install a new child domain called server. The child domain's DNS name would be server.admin.com.

Trusts Trusts allow the domains to authenticate resources not natively stored in the domain. Trusts can be one-way or two-way. Typically trusts are two-way. For example, if a two-way trust exists between domain A and domain B, users from either domain could log on and be authenticated regardless of physical location. Inside a single tree in a forest, all the domains automatically have a two-way transitive trust between one and another, making the flow of information much easier. You can control and configure the trust relationships to meet your needs. Additionally, when you create a new forest, there is no trust relationship created between the two forests, but you can, however, create one.

Organizational unit (OU) This provides logical organization to a domain. Without the use of OUs, the domain is just one giant bucket of unorganized objects, making administration a headache. OUs offer the ability to logically organize the objects in your directory. Objects are generally user or group accounts; however, there are several objects you can find in a domain. However, the main objects you will use on a day-to-day basis are users and groups. This organization provides several administrative benefits. Being able to find users and edit properties of a group of users is easier with OUs. You can also delegate administration to the OUs, which allows you to have multiple administrators without having to grant them access to the entire domain. Lastly, OUs are used in the deployment of group policies.

User The user is the account you grant access to log on to your network. This is one of the main objects inside your domain environment.

Group This is another important AD object. Providing another way to organize your users, groups are an invaluable resource when you're granting secure access to your networks resources, such as file shares, printers, or applications. Groups can have scopes that range from local to the domain to the entire forest.

Domain controller (DC) This is the main server (or servers) holding your domain objects (users, groups, and so on). The domain controller is also responsible for replication of the directory structure to other DCs as well as for providing support for search capabilities.

Read-only domain controller (RODC) This is a variation of the domain controller and holds only read-only copies of the directory. Traditional DCs can receive and deliver changes to other DCs in the directory structure, but RODCs can receive only replication updates. Normally these servers are used in branch-office scenarios but could also be used for other reasons such as web applications.

Sites When you're designing Active Directory domains, OUs, and the many other objects that offer logical containers to help organize your structure, an important physical element of Active Directory is the site. Sites allow you to control the physical structure of your network. Sites help govern three important functions in your environment: replication, authentication, and service location. Sites allow you to define boundaries of your network via IP addresses and subnets, and they give you a mechanism to control traffic. For example, when a user logs on to the network, the site will determine what domain controller will handle the request. The site containing the same IP subnet of the system the user is logging in from will be where the request will be directed. Any domain controllers in the site will then proceed to authenticate the user.

For more information on working with Active Directory, please review the planning guide located here:

http://technet.microsoft.com/en-us/library/ cc794908(WS.10).aspx

When you start planning your AD structure, you start at the top with the forest and domains. Typically most organizations will have one forest, but it is not uncommon to have more than one forest. For example, you may have a forest for testing and research purposes. This forest is normally logically and physically segmented from the rest of the network. A typical scenario for this type of forest would be when you are testing applications, such as Microsoft Exchange, that extend the schema.

When you install your first domain controller, this becomes the root domain and the beginning of your forest. Server Core cannot be installed as the first domain controller in your forest; the first DC must always be a full install of Windows Server 2008 R2. Additional domain controllers may be installed under the root domain, becoming child domains or installed off the root of the forest, which will become new trees with new namespaces.

The domains are logical units inside the forest that help you organize all the directory objects and define the namespace for the rest of the domains in the forest. You define the DNS namespace for your entire forest when you install the first domain controller in AD; typically this is your company's public-facing DNS name. However, it does not have to be. Remember, these are logical structures, and you can call them whatever best suits the needs of your organization. It is important to note, however, that you should have your DNS name well thought out and planned before you install your first domain controller. Changing your DNS name can have wide-ranging impact not only on your Active Directory forest but on any applications that leverage the directory, such as email or other line-of-business applications.

For example, if your first domain is called corp.com, all the domains installed as part of the parent domains tree will share that namespace of corp.com. Take a look at Figure 1 for a quick picture of what a logical structure of Active Directory would look like.

Inside the domain, you create organizational units to further create logical organizational structure for your domain. When you create OUs, there is no right or wrong way to set them up as long as they add efficiency and organization to your directory structure. You may choose to organize the OUs alphabetically by last name, which is the least common way, or align them by business units, which is the most common way. There are any number of other ways, but the main point is that you want to make your life easier as an administrator.

Figure 1. Example Active Directory design: triangles represent domains, circles are OUs, and trusts are represented by arrows.

2. Plan for Hyper-V

Growing in demand is the use of virtualization technologies to leverage underutilized resources to help with server consolidation and flexibility. Windows Server 2008 R2 Hyper-V is built upon the hypervisor technology. Hypervisor allows for virtual systems to access server hardware efficiently. Unlike other virtualization technologies, Hyper-V does not place any third-party drivers in the hypervisor layer. The drivers that are leveraged by the virtualized systems are placed in the parent partition, which is the host operating system. All other virtual machines you install will be placed in child partitions.

Deciding to have your server handle virtualization workloads may seem straightforward, but this role does require additional planning. You need to take a look at what server workloads will be virtualized on the server and what additional hardware resources, if any, will be needed on the server, should you virtualize your open source (Linux) systems. With all of these questions you need to answer, you may be inclined to start looking at your performance logs and application logs to determine workloads. Fortunately, you can take advantage of a resource that Microsoft provides called the Microsoft Assessment and Planning (MAP) Toolkit. You can download this utility from http://www.microsoft.com/downloads/details.aspx?FamilyID=67240b76-3148-4e49-943d-4d9ea7f77730&displaylang=en.

This tool provides several reporting and analysis functions that you can take advantage of; specifically, to plan for Hyper-V, there is a report that will help you make those server consolidation decisions. The MAP Toolkit will generate both application and server recommendations for your network to determine the most optimal candidates for virtualization. This tool will dramatically reduce the amount of planning time when you are looking at Hyper-V. If you plan correctly, you could have the potential of reducing several of your physical servers to just a few.

3. Understand Remote Desktop Services

Windows Server 2008 R2 has renamed Terminal Services to Remote Desktop Services (RDS). The functionally of Remote Desktop Services is still very much the same and similar to the functionality of Terminal Services in Windows Server 2008. You can use these services to provide presentation virtualization to your environment. Planning for presentation virtualization follows similar methodologies of server virtualization. In addition to traditional terminal services, RDS provides capabilities for Virtual Desktop Infrastructure (VDI), which allows you to virtualize your desktop infrastructure workload onto servers in your data center. VDI allows you to take your typical desktop applications, data, and even the operating system itself and provide it on your thin clients. The systems those users work on use the Remote Desktop Protocol to connect to the back-end server. When installing RDS, you should consider the proper order for installing these services as compared to the applications you will use on the RDS server. The general rule of thumb is to install these applications after you install RDS so you avoid any potential issues or reinstallations of applications. These applications in most cases will have special installation instructions to make them terminal server friendly.

Another planning consideration is how are you going to allow clients to authenticate against your server and with what level of security. You have two choices:

• Require network-level authentication

• Do not require network-level authentication

This decision can impact the type of clients and the level of security provided by your RDS server. The decision also controls when the authentication of your clients occurs during the logon process. If you choose to require network-level authentication, the user is authenticated before the remote desktop connection is established. This method provides a higher level of security. However, this method also requires your remote desktop clients be using at least version 6.0, and the Windows client needs to support the Credential Security Support Provider (CredSSP) protocol. CredSSP is built into Windows Vista and comes with Service Pack 3 for Windows XP.

If you choose to not require network-level authentication, you will allow any version of the remote desktop client software to connect. However, this will lower the security because the user authentication occurs late in the connection process.

When planning Remote Desktop Services, you need to understand the core services provided by it, as described in Table 1.

4. Understand Windows Server 2008 R2 Features

Windows Server 2008 R2 provides an additional set of functions to the server called features. These features were part of Windows Server 2008, but there are also some new features in Windows Server 2008 R2. Some of these features are required for certain roles to function, while other features will add reliability to your server, as in the clustering feature. Some will just add aesthetics, like the desktop experience feature. When planning your server OS, you may need to install some of these features to achieve your desired configuration. In most cases, you will not need to install the necessary features to support a role. Required features will generally be installed when you install the role.

To install a Windows Server 2008 R2 feature, open Server Manager. Table 2 provides a quick review of the features.