Understanding Workgroups

The workgroup was the original form of networking supported by Windows, and it’s really still the basic form of all Windows networking. The concept of a workgroup was originally defined around peer-to-peer networking, where any machine on a network can act as a server and any machine can act as a workstation. Even today, Windows Server 2008 has both the Server and the Workstation services that provide these two roles. You can use your Windows Server 2008 server as a workstation if you want — no one can honestly say that this functionality is unavailable. Of course, Microsoft now has the Server Core version of Windows Server 2008. Theoretically, you can use Server Core as a workstation, but I don’t know of anyone who’d want to.

The other standard form of networking is client/server. In this form of networking, you don’t use the server as a workstation. In fact, when working with operating systems such as NetWare (http://www.novell.com/products/netware/), you can’t use the machine that has the operating system installed as a workstation. It’s simply impossible to use a NetWare server as a workstation because no functionality exists to do it. The advantage of client/server setups is that they’re very light and reliable. The server uses all its resources to perform tasks on behalf of the client. However, this form of networking lacks flexibility. All workstations are always workstations, and all servers are always servers.

Understanding the pros of workgroups
Workgroups are convenient because you don’t have to have one super machine to handle everyone’s requests. Any workstation can also act as a server, so you can attach a laser printer to one workstation and an inkjet to another workstation. With the proper settings, everyone has access to both printers even though the printers appear on different machines. Sharing occurs on many levels. A workstation with an exceptionally large hard drive can share some of that hard drive space with everyone on the network. Likewise, a workstation with an Internet connection can share the connection with everyone else. Peer-to-peer networking is all about sharing whatever a workstation has in excess with everyone else on the network so that everyone benefits from that excess.

Most administrators also find workgroups easier to manage, at least when they’re small. If someone wants access to a particular workstation, their name must appear on the list of users for that workstation. When a workstation wants to share a particular asset, you must configure that asset for sharing and define who can use it. All of the settings are localized and easy to understand. You don’t have to worry about global security policies, Active Directory, or anything else that’s overly complicated.

A workgroup need not exist as a separate entity. You can use a workgroup network setup at the departmental level and a domain or client/server setup at the enterprise level. The concepts behind a workgroup work equally well in the departmental environment as they do in standalone mode. One question with workgroups is finding out how large can you make them before they reach their limit. The best way to answer this question is to determine how the administrator configures the workgroup, know whether the workgroup contains the proper number of dedicated servers, and what you expect the workgroup to do. If your only goal for the workgroup is to share files and print documents, a workgroup of any size is possible. As you add tasks, such as database management, the potential size for a workgroup decreases because you’re asking it to perform more work. A workgroup configuration that includes e-mail, file, print, and database management services is probably limited to 100 nodes. However, a skillful administrator could potentially increase that size.

Understanding the cons of workgroups
Using a workgroup becomes less advantageous when you begin using a number of custom applications and require centralized management for help desk support and other needs. Adding remote users and other enterprise requirements increase complexity and the need for centralized management, which usually means obtaining a central management application. For example, if you plan to use Microsoft’s System Center Operations Manager, or SCOM (http://www.microsoft.com/systemcenter/opsmgr/default.mspx), you need a domain. Consequently, the workgroup meets its match in complexity, not necessarily in size.

Workgroups also tend to provide poorer security than does a centralized network (client/server or domain). Because everyone is sharing resources freely, it can be difficult to lock down those resources and ensure that they’re shared only as required to accomplish tasks within the workgroup. Because of the poorer security, workgroups often encounter problems with adware and viruses where one machine’s woe automatically becomes every machine’s woe.

Source of Information : For Dummies Windows Server 2008 For Dummies

Reviewing Legacy Windows Server 2003 Active Directory Improvements

It is important to understand that AD DS is a product in constant development since its release with Windows 2000. From humble beginnings, Active Directory as a product has developed and improved over the years. The first major set of improvements to AD was released with the Windows Server 2003 product. Many of the improvements made with Windows Server 2003 AD still exist today in Windows Server 2008 R2 AD DS. It is subse quently important to understand what functionality in AD was born from Windows Server 2003. The following key improvements were made in this time frame:

. Windows Server 2003 Active Directory Domain Rename Tool—Windows Server 2003 originally introduced the concept of Domain Rename, which has continued to be supported in Windows Server 2008 R2. This gives administrators the ability to prune, splice, and rename AD DS domains. Given the nature of corporations, with restructuring, acquisitions, and name changes occurring constantly, the ability of AD DS to be flexible in naming and structure is of utmost importance. The Active Directory Domain Rename Tool was devised to address this very need. Before AD DS domains can be renamed, several key prerequisites must be in place before the domain structure can be modified. First, and probably the most important, all domain controllers in the entire forest must be upgraded to Windows Server 2003 or 2008 in advance. In addition, the domains and the forest must be upgraded to at least Windows Server 2003 functional level. Finally, comprehensive backups of the environment should be performed before undertaking the rename. The domain rename process is complex and should never be considered as routine. After the process, each domain controller must be rebooted and each member
computer across the entire forest must also be rebooted (twice).

. Cross-forest transitive trust capabilities—Windows Server 2003 Active Directory introduced the capability to establish cross-forest transitive trusts between two disparate AD DS forests. This capability allows two companies to share resources more easily, without actually merging the forests. Note that both forests must be running at least at Windows Server 2003 functional levels for the transitive portion of this trust to function properly.

. AD DS replication compression disable support—Another feature introduced in Windows Server 2003 AD was the ability to turn off replication compression to increase domain controller performance. This would normally be an option only for organizations with very fast connections between all their domain controllers.

. Schema attribute deactivation—Developers who write applications for AD DS continue to have the ability, introduced in Windows Server 2003, to deactivate schema attributes, allowing custom-built applications to utilize custom attributes without fear of conflict. In addition, attributes can be deactivated to reduce replication traffic.

. Incremental universal group membership replication—Before Windows Server 2003, Windows 2000 Active Directory had a major drawback in the use of universal groups. Membership in those groups was stored in a single, multivalued attribute in AD DS. Essentially, what this meant was that any changes to membership in a universal group required a complete re-replication of all membership. In other words, if you had a universal group with 5,000 users, adding number 5,001 would require a major replication effort because all 5,001 users would be re-replicated across the forest. Windows Server 2003 and 2008 simplify this process and allow for incremental replication of universal group membership. In essence, only the 5,001st member is replicated in Windows Server 2003/2008.

. AD–integrated DNS zones in application partitions—Windows Server 2003 improved DNS replication by storing DNS zones in the application partition. This basically meant that fewer objects needed to be stored in AD, reducing replication concerns with DNS.

. AD lingering objects removal—Another major improvement originally introduced with Windows Server 2003 and still supported in 2008 is the ability to remove lingering objects from the directory that no longer exist.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Examining Additional Windows Server 2008 R2 AD DS Improvements

In addition to the changes listed in the preceding sections, AD DS in Windows Server 2008 R2 supports the following features:

. Read-Only Domain Controller (RODC) support—Windows Server 2008 R2 includes the ability to deploy domain controllers with read-only copies of the domain. This is useful for remote branch office scenarios where security might not be tight.

. Group Policy central store—Administrative templates for group policies are stored in the SYSVOL on the PDC emulator in Windows Server 2008 R2, resulting in reduced replication and reduced SYSVOL size.

. DFS-R Replication of the SYSVOL—A Windows Server 2008 RTM/R2 functional domain uses the improved Distributed File System Replication (DFS-R) technology rather than the older, problematic File Replication Service (FRS) to replicate the SYSVOL.

. Active Directory database mounting tool (DSAMain)—The Active Directory database mounting tool (DSAMain.exe) allows administrators to view snapshots of data within an AD DS or AD LDS database. This can be used to compare data within databases, which can be useful when performing AD DS data restores.

. GlobalNames DNS zone—Windows Server 2008 R2 DNS allows for creation of the concept of the GlobalNames DNS zone. This type of DNS zone allows for a global namespace to be spread across multiple subdomains. For example, a client in the asia.companyabc.com subdomain would resolve the DNS name portal.asia.companyabc.com to the same IP address as a client in a different subdomain resolving portal. europe.companyabc.com. This can improve DNS resolution in multizone environments.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Reviewing Additional Active Directory Services

Five separate technologies in Windows Server 2008 R2 now contain the Active Directory moniker in their title. Some of the technologies previously existed as separate products, but they have all come under the global AD umbrella. These technologies are as follows:

. Active Directory Lightweight Directory Services (AD LDS)—AD LDS, previously referred to as Active Directory in Application Mode (ADAM), is a smaller-scale directory service that can be used by applications that require a separate directory. It can be used in situations when a separate directory is needed, but the overhead and cost of setting up a separate AD DS forest is not warranted.

. Active Directory Federation Services (AD FS)—AD FS in Windows Server 2008 R2 is an improvement to the older standalone versions of the ADFS product previously offered by Microsoft. AD FS provides for Single Sign-On technology to allow for a user logon to be passed to multiple web applications within a single session.

. Active Directory Certificate Services (AD CS)—AD CS refers to the latest version of Windows Certificate Services. AD CS provides for the ability to create a Public Key Infrastructure (PKI) environment and assign PKI certificates to AD users and machines. These certificates can be used for encryption of traffic, content, or logon credentials.

. Active Directory Rights Management Services (AD RMS)—AD RMS is the evolution of the older Windows Rights Management Server technology. AD RMS is a service that protects confidential information from data leakage by controlling what can be done to that data. For example, restrictions can be placed on documents, disallowing them from being printed or programmatically accessed (such as by cutting/pasting of content).

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Auditing Changes Made to AD Objects

Another important change to Active Directory that can be enabled in a Windows Server 2008 or Windows Server 2008 R2 functional domain is the concept of auditing changes made to Active Directory objects. Previously, it was difficult to tell when changes were made, and AD-specific auditing logs were not available. Windows Server 2008 RTM/R2 allows administrators to be able to determine when AD objects were modified, moved, or deleted.

To enable AD object auditing on a Windows Server 2008 RTM/R2 domain controller, perform the following steps:

1. From a member server or domain controller, click Start, All Programs, Administrative Tools, Group Policy Management.

2. Navigate to , Domains, , Domain Controllers, Default Domain Controllers Policy.

3. Click Edit.

4. In the GPO window, navigate to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Audit Policy.

5. Under the Audit Policy setting, right-click on Audit Directory Service Access, and click Properties.

6. Check the Define These Policy Settings check box, and then check the Success and Failure check boxes, as shown in Figure 4.15.

7. Click OK to save the settings.

Global AD DS auditing on all DCs will subsequently be turned on. Audit event IDs will be displayed as Event ID 5136, 5137, 5138, 5139, or 5141, depending on if the operation is a modify, create, undelete, move, or delete respectively.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Implementing Multiple Password Policies per Domain

Another Windows Server 2008 addition to AD DS is the ability to implement granular password policies across a single domain. Previously, this was only an option with thirdparty password change utilities installed on the domain controllers in a forest. With Windows Server 2008 or Windows Server 2008 R2, administrators can define which users have more complex password policies, and which will be able to use more lenient policies.

There are a few key points to this technology that must be understood before implementing it. These points are listed as follows:

. Domain mode must be set to Windows Server 2008 or Windows Server 2008 R2 level, which means that all DCs in the domain must be running Windows Server 2008 R2 or RTM.

. Fine-grained password policies always win over a domain password policy.

. Password policies can be applied to groups, but they must be global security groups.

. Fine-grained password policies applied to a user always win over settings applied to a group.

. The Password Settings Objects (PSOs) are stored in the Password Settings Container in AD (that is, CN=Password Settings Container,CN=System,DC=companyabc,DC=com).

. Only one set of password policies can apply to a user. If multiple password policies
are applied, the policy with the lower number precedence wins.

To create a custom password policy for a specific user, a Password Settings Object (PSO) must be created using the ADSIEdit tool, which is used for low-level changes to AD DS or AD LDS directory objects and attributes.

The version of ADSIEdit included with Windows Server 2008 RTM/R2 provides for a crude wizard that allows for PSOs to be created. The wizard automates the creation of a PSO, and allows for specific attributes to be set on the PSO that are related to password policies. All attributes in this table must be entered in the proper format for a PSO to be created. Note that only the final attribute in this list msDS-PSOAppliesTo is not prompted by the wizard, and must be entered in manually.

To create a new PSO, open ADSIEdit from the Administrative Tools menu and point it to the fully qualified domain name (FQDN) of the domain where the PSO will be created.
After ADSIEdit has been invoked, perform the following steps to create a PSO:

1. Under the container for the domain, navigate to CN=System, CN=Password Settings Container.

2. Right-click on the CN=Password Settings Container, and choose New, Object.

3. Select msDS-PasswordSettings, and click Next to continue.

4. From the Create Object dialog box, enter in the attributes.

5. When on the final screen of the wizard, click the More Attributes button.

6. Click the Select a Property to View drop-down list arrow, and then select msDSPSOAppliesTo.

7. In the Edit Attribute field, enter the DN of the group or user to which the PSO will apply. Be sure to click the Add button, or the setting will not be applied. The value should be displayed.

8. Click OK and then click Finish.

After creation, the PSO policy will appear in the details pane. Any of the attributes can be subsequently modified using ADSIEdit by rightclicking the individual PSO and choosing Properties. This includes changing the scope of which users the policy applies to.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Restarting AD DS on a Domain Controller

Windows Server 2008 originally introduced new capabilities to start or stop directory services running on a domain controller without having to shut it down. This allows administrators to perform maintenance or recovery on the Active Directory database without having to reboot into Directory Services Restore Mode.

In addition to allowing for maintenance and recovery, turning off the domain controller functionality on an AD DC essentially turns that domain controller into a member server, allowing for a server to be quickly brought out of DC mode if necessary. Microsoft has also removed the need for local Administrators on the DC to have Domain Admin rights as well, which improves overall security in places where administration of the DC server is required, but full Domain Admin rights are not needed.

To take a Windows Server 2008 R2 DC offline, perform the following steps:

1. Open up the Services MMC (Start, All Programs, Administrative Tools, Services).

2. From the Services MMC, select the Active Directory Domain Services service. Right-click it and choose Stop.

3. When prompted that stopping AD DS will stop other associated services such as DNS, DFS, Kerberos, and Intersite Messaging, choose Yes to continue.

4. To restart AD DS, right-click the AD DS service and choose Start. Start the Intersite Messaging Service and Kerberos Key Distribution Center service as well.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Recovering Deleted Items Using the AD Recycle Bin

Deleted objects can be restored using the LDP.exe utility, or they can be recovered using Windows PowerShell. PowerShell offers a much more straightforward approach to recovery of deleted items, and is recommended in most cases.

To recover a deleted object, use the Get-ADObject cmdlet from the Active Directory Module for Windows PowerShell, being sure to open the module using the Run As Administrator option. Get-ADObject can be used to find objects, which can then be recovered using the Restore-ADObject cmdlet. For example, the following syntax, recovers a deleted user account for user Zachary Sefanov:

Get-ADObject –Filter {displayName –eq “Zachary Sefanov”} –IncludeDeletedObjects | Restore-ADObject

For more information about these cmdlets, type Get-Help Get-AdObject of Get-Help
Restore-ADObject from PowerShell.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Outlining AD DS Changes in Windows Server 2008 R2

Improvements in the functionality and reliability of AD DS are of key importance to the development team at Microsoft. It is, therefore, no small surprise that Windows Server 2008 R2 introduces improvements in AD DS. From the ability to have multiple password policies in a domain to improvements in domain controller deployment with the RODC role, the changes made to the structure of AD DS warrant a closer look.

Windows Server 2008 itself introduced multiple changes to AD DS functionality above and beyond the Windows Server 2003 and Windows Server 2003 R2 Active Directory versions. Windows Server 2008 R2 then introduced additional features and functionalities above those introduced with the RTM version of Windows Server 2008. The Windows Server 2008 R2 enhancements include the following:

. Active Directory Recycle Bin—Provides for the ability to restore deleted AD DS objects

. Offline Domain Join—Allows for prestaging of the act of joining a workstation to the AD DS domain

. Managed Service Accounts—Provides a mechanism for controlling and managing AD DS service accounts

. Authentication Mechanism Assurance—Allows for administrators to grant access to resources differently based on whether a user logs on with a smart card or multifactor authentication source or whether they log on via traditional techniques

. Enhanced Administrative Tools—Includes newly designed and powerful utilities such as Active Directory Web Services, Active Directory Administrative Center, Active Directory Best Practice Analyzer, a new AD DS Management Pack, and an Active Directory Module for Windows PowerShell

The previous version of AD DS introduced with the release of Windows Server 2008 included the following key features that are still available with Windows Server 2008 R2. If upgrading from any of the Windows Server 2003 versions of Active Directory or Windows 2000 Active Directory, all of these new features will be made available:

. Ability to create multiple fine-grained password policies per domain—Lifts the restrictions of a single password policy per domain

. Ability to restart AD DS on a domain controller—Allows for maintenance of an AD DS database without shutting the machine down

. Enhanced AD DS auditing capabilities—Provides useful and detailed item-level auditing capabilities in AD DS without an overwhelming number of logs generated

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Outlining AD DS Security

The security built around Active Directory was designed to protect valuable network assets. Development of Windows Server 2008 R2 security has also been affected by the Trustworthy Computing initiative by Microsoft, which changed the primary focus of Microsoft products to security. In a nutshell, Microsoft is more focused than ever before on the security of its products, and all new features must pass a security litmus test before they can be released. This initiative has affected the development of Windows Server 2008 R2 and is evident in the security features.

Understanding Kerberos Authentication
Kerberos was originally designed at MIT as a secure method of authenticating users without actually sending a user password across the network, encrypted or not. Being able to send a password this way greatly reduces the threat of password theft because malicious users are no longer able to seize a copy of the password as it crosses the network and run brute-force attacks on the information to decrypt it.

The actual functionality of Kerberos is complicated, but essentially what happens is the computer sends an information packet to the client that requires authentication. This packet contains a “riddle” of sorts that can be answered only by the user’s proper credentials. The user applies the “answer” to the riddle and sends it back to the server. If the proper password was applied to the answer, the user is authenticated. Although used in Windows Server 2008 R2, this form of authentication is not proprietary to Microsoft, and is available as an Internet standard. For a greater understanding of Kerberos security.

Taking Additional Security Precautions
AD DS implementations are, in essence, as secure as the Windows Server 2008 R2 environment in which they run. The security of the AD DS structure can be increased through the utilization of additional security precautions, such as secured server-to-server communications using IPSec or the use of smart cards or other encryption techniques. In addition, the user environment can be secured through the use of group policies that can set parameter changes such as user password restrictions, domain security, and logon access privileges.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Outlining the Role of DNS in AD DS

When Microsoft began development on AD DS, full compatibility with the domain name system (DNS) was a critical priority. AD DS was built from the ground up not just to be fully compatible with DNS but to be so integrated with it that one cannot exist without the other. Microsoft’s direction in this case did not just happen by chance, but because of the central role that DNS plays in Internet name resolution and Microsoft’s desire to make its product lines embrace the Internet.

While fully conforming to the standards established for DNS, AD DS can expand upon the standard feature set of DNS and offer some new capabilities such as AD-integrated DNS, which greatly eases the administration required for DNS environments. In addition, AD DS can easily adapt to exist in a foreign DNS environment, such as UNIX BIND, as long as the BIND version is 8.2.x or higher.

Given the importance of DNS in Windows Server 2008 R2’s AD DS, a thorough understanding of DNS is a must. Chapter 10, “Domain Name System and IPv6,” goes into greater detail on DNS in Windows Server 2008 R2.

Examining DNS Namespace Concepts
A DNS namespace, simply defined, is the bounded logical area formed by a DNS name and its subdomains. For example, europe.companyabc.com, asia.companyabc.com, and companyabc.com are all part of the same contiguous DNS namespace. A DNS namespace in AD DS can be published on the Internet, such as microsoft.com or msn.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.

. External (published) namespaces—A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace was previously common for organizations that wanted the full convenience of having their commonly used Internet domain name represent their AD DS structure. Best practices have evolved to make this model less attractive, however, as security becomes a concern and DNS must be set up as “split brain” because it is generally ill-advised to have internal AD DNS zones accessible from the Internet.

. Internal (hidden) namespaces—For many organizations, publication of their internal domain structure is too high a security risk. These organizations can easily define their AD DS with an internal namespace that is not readable from the Internet. For example, a company might have an external DNS namespace of cco.com but decide that its AD DS structure will correspond to cco.internal or any namespace it wants. Bear in mind that any combination will work for internal namespaces because there is no limitation on using .com, .net, .gov, and so on when dealing with a namespace that is not published. For all intents and purposes, you could name your domain ilovemydomain.verymuch if you want (although it’s not recommended, of course). For practical reasons, however, the .internal namespace has been specifically reserved for private name addressing, and using it is a best-practice approach in many cases.

Comprehending Dynamic DNS
Dynamic DNS (DDNS) was developed as an answer to the problem of DNS tables having to be manually updated when changes were made. DDNS in Windows Server 2008 R2 automatically updates the DNS table based on registrations, and can work in conjunction with DHCP to automatically process DNS changes as clients are added and removed from the network infrastructure. DDNS is not required for AD DS to function properly, but it makes administration much easier than previous manual methods.

Comparing Standard DNS Zones and AD-Integrated DNS Zones
Standard DNS essentially stores all name records in a text file and keeps it updated via dynamic updates. If you are accustomed to using UNIX BIND DNS or other standard forms of DNS, this is essentially what Standard DNS is in Windows Server 2008 R2. AD DS expands upon other implementations of DNS by allowing administrators to integrate DNS into AD DS. By doing this, the DNS zones themselves exist as objects in the AD
DS, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off AD DS traffic, and the DNS records are stored as objects in the directory. In Windows Server 2008 R2’s implementation of AD DS, AD-integrated DNS zones are opti mized by being stored in the application partition, thus reducing replication traffic and improving performance.

Understanding How AD DS DNS Works with Foreign DNS
Often, some local administrators might be hesitant to deploy AD DS because of their desire to maintain their own foreign DNS implementation, usually UNIX BIND. If this is the case, it is possible for Windows Server 2008 R2 DNS to coexist in this type of environment, as long as the DNS supports dynamic updates and SRV records (BIND 8.2.x or higher). These situations occur more often than not, as political situations within IT departments are often divided into pro-Microsoft and pro-UNIX groups, each of which has its own ideology and plans. The ability of Windows Server 2008 R2 to coexist peacefully in these types of environments is, therefore, key.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Explaining AD DS Replication

Replication in AD DS is a critical function that is necessary to fulfill the functionality of a multimaster environment. The ability to make changes on any domain controller in a forest and then have those changes replicate to the other domain controllers is key. Consequently, a robust method of distributing this information was a major consideration for the development team at Microsoft. AD DS replication is independent of the forest, tree, or domain structure, and it is this flexibility that is central to AD’s success.

Sites, Site Links, and Site Link Bridgeheads
For purposes of replication, AD DS logically organizes groups of servers into a concept known as sites. Typically speaking, a single site should be composed of servers that are
connected to each other via high-speed connections. The links that are established to connect two or more locations connected potentially through slower-speed connections are known as site links. Sites are created with site links connecting the locations together to enable the administrator to specify the bandwidth used to replicate information between sites.

Rather than having information replicated immediately between servers within a highspeed connected site, the administrator can specify to replicate information between two sites only once per night or at a time when network demands are low, allowing more bandwidth availability to replicate AD DS information.

Servers that funnel intersite replication through themselves are known as site link bridgeheads. The site structure is completely modifiable, and should roughly follow the WAN structure of an organization. By default, only a single site is created in AD DS, and administrators must manually create additional sites to be able to optimize replication.

Understanding Originating Writes
Replication of objects between domain controllers is accomplished through the use of a property known as Originating Writes. As changes are made to an object, this property is incrementally increased in value. A domain controller compares its own version of this value with the one received during a replication request. If it is lower, the change is applied; if not, it is discarded. This simplistic approach to replication is also extremely reliable and efficient and allows for effective object synchronization. For more information on replication, including a detailed analysis of Originating Writes and its other key components.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Outlining the Role of Groups in an AD DS Environment

The AD DS group structure, although not new in AD DS, provides an efficient mechanism for managing security on large numbers of users. Without groups to logically organize users, permissions on each object in a network would have to be set up manually on a per-user basis. This means that if an entire department needed access to a printer, each user would need to be manually entered into the permissions list of that printer. These tasks would make administration of security daunting.

The concept of groups was therefore devised to ease administration. If a large department needed access to that same printer, the department’s group need only be supplied the necessary permissions. This greatly eases security-based administration and has the added advantage of providing for ease of transition if specific users leave the company or are transferred to a different department. For example, imagine an administrator in charge of printing and her user account is a member of a group named Printer Admins, which has full administrative privilege to the printers. Now, if this user transfers to become an email administrator, for example, reassigning permissions to a new print administrator is as simple as adding that new user to the Printer Admins group. This capability greatly simplifies these types of situations.

Groups in AD DS work in the way that previous group structures, particularly in Windows NT, have worked, but with a few modifications to their design. Groups are divided into two categories: group type and group scope. There are two group types in AD DS: security and distribution. Essentially, a security group can be used to apply permissions to objects for the members of the group. A distribution group, on the other hand, cannot be used for permissions but is used instead to send mail to members of the group. Group scope in AD DS is likewise divided into several components, defined as follows:

. Machine local groups—Machine local groups, also known as simply “local groups,” can theoretically contain members from any trusted location. Users and groups in the local domain, as well as in other trusted domains and forests, can be included in this type of group. However, it is important to note that local groups allow resources to be accessed only on the machine where they are located, which greatly reduces their usability.

. Domain local groups—Domain local groups are essentially the same thing as local groups in Windows NT, and are used to administer resources located only on their own domain. They can contain users and groups from any other trusted domain. Most typically, these types of groups are used to grant access to resources for groups in different domains.

. Global groups—Global groups are on the opposite side from domain local groups. They can contain users only in the domain in which they exist but are used to grant access to resources in other trusted domains. These types of groups are best used to supply security membership to user accounts that share a similar function, such as the sales global group.

. Universal groups—Universal groups can contain users and groups from any domain in the forest and can grant access to any resource in the forest. Along with this added power come a few caveats. First, universal groups are available only in domains with a functional level of Windows 2000 Native or later. Second, all members of each universal group are stored in the global catalog, increasing the replication load. It is important to note, however, that universal group membership replication has been noticeably streamlined and optimized in Windows Server 2008 R2 because the membership is incrementally replicated.

Choosing Between OUs and Groups
Whereas OUs are primarily used to segregate administrative function, groups are useful for logical organization of security functions. Translated, OUs are created if there is a need for a department or physical location to have some certain type of administrative control over its own environment. For example, an organization with offices in Japan could organize its Japanese users into a separate OU and give a local administrator password-change and account-creation privileges for that OU. Groups, however, can be used to organize users to more easily apply security permissions. For example, you can create a group named Japanese Office Users that contains all the users from the office in Japan. Security permissions can then be established on objects in AD DS using that group. They could, for example, be given privileges to folders in the main corporate location, something that could not be done at the OU level.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Examining the Key Features of Active Directory Domain Services

Five key components are central to AD DS’s functionality. As compatibility with Internet standards has become required for new directory services, the existing implementations have adjusted and focused on these areas:

. TCP/IP compatibility—Unlike some of the original proprietary protocols such as
IPX/SPX and NetBEUI, the Transmission Control Protocol/Internet Protocol (TCP/IP) was designed to be cross-platform. The subsequent adoption of TCP/IP as an Internet standard for computer communications has propelled it to the forefront of the protocol world and essentially made it a requirement for enterprise operating systems. AD DS and Windows Server 2008 R2 utilize the TCP/IP protocol stack as their primary method of communications.

. Lightweight Directory Access Protocol support—The Lightweight Directory Access Protocol (LDAP) has emerged as the standard Internet directory protocol and is used to update and query data within the directory. AD DS directly supports LDAP.

. Domain name system (DNS) support—DNS was created out of a need to translate simplified names that can be understood by humans (such as www.cco.com) into an IP address that is understood by a computer (such as The AD DS structure supports and effectively requires DNS to function properly.

. Security support—Internet standards-based security support is vital to the smooth functioning of an environment that is essentially connected to millions of computers around the world. Lack of strong security is an invitation to be hacked, and Windows Server 2008 R2 and AD DS have taken security to greater levels. Support for IP Security (IPSec), Kerberos, Certificate Authorities, and Secure Sockets Layer (SSL) encryption is built in to Windows Server 2008 R2 and AD DS.

. Ease of administration—Although often overlooked in powerful directory services implementations, the ease in which the environment is administered and configured directly affects the overall costs associated with its use. AD DS and Windows Server 2008 R2 are specifically designed for ease of use to lessen the learning curve associated with the use of a new environment. Windows Server 2008 R2 also enhanced AD DS administration with the introduction of the Active Directory Administration Center, Active Directory Web Services, and an Active Directory module for Windows PowerShell command-line administration.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Examining the Evolution of Directory Services

Directory services have existed in one form or another since the early days of computing to provide basic lookup and authentication functionality for enterprise network implementations. A directory service provides detailed information about a user or object in a network, much in the same way that a phone book is used to look up a telephone number for a provided name. For example, a user object in a directory service can store the phone number, email address, department name, and as many other attributes as an administrator desires.

Directory services are commonly referred to as the white pages of a network. They provide user and object definition and administration. Early electronic directories were developed soon after the invention of the digital computer and were used for user authentication and to control access to resources. With the growth of the Internet and the increase in the use of computers for collaboration, the use of directories expanded to include basic contact information about users. Examples of early directories included MVS PROFS (IBM), Grapevine’s Registration Database, and WHOIS. Application-specific directory services soon arose to address the specific addressing and contact lookup needs of each product. These directories were accessible only via proprietary access methods and were limited in scope. Applications utilizing these types of directories were programs such as Novell GroupWise, Lotus Notes, and the UNIX sendmail /etc/aliases file.

The further development of large-scale enterprise directory services was spearheaded by Novell with the release of Novell Directory Services (NDS) in the early 1990s. It was adopted by NetWare organizations and eventually was expanded to include support for mixed NetWare/NT environments. The flat, unwieldy structure of NT domains and the lack of synchronization and collaboration between the two environments led many organizations to adopt NDS as a directory service implementation. It was these specific deficiencies in NT that Microsoft addressed with the introduction of AD DS.

The development of the Lightweight Directory Access Protocol (LDAP) corresponded with the growth of the Internet and a need for greater collaboration and standardization. This nonproprietary method of accessing and modifying directory information that fully utilized TCP/IP was determined to be robust and functional, and new directory services implementations were written to utilize this protocol. AD DS itself was specifically designed to conform to the LDAP standard.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Windows Server 2008 R2 Running Add-in Applications Server Functions

Although some of the newer, built-in server application functions in Windows Server 2008 R2—such as Network Policy Server, server virtualization, Remote Desktop Services Web Access, Media Server, and so on—provide key areas for organizations to select as initial areas to implement Windows Server 2008 R2 technologies, other organizations might find add-in applications as being the key areas that drive an initial implementation of Windows Server 2008 R2. Some of the add-in applications come from Microsoft, such as the Microsoft Exchange Server 2010 messaging system or Microsoft SQL Server 2008 database system. Other add-ins to Windows Server 2008 R2 are provided by companies that provide human resource management applications; accounting software; document management tools; fax or voicemail add-ins; or other business, industry, or user productivity capabilities.

In earlier Windows Server operating systems, the core operating system provided simple logon and network connectivity functions; however, with Windows Server 2008 R2, the operating system includes many core capabilities built in to the Windows Server 2008 R2 operating environment. With integrated fault tolerance, data recovery, server security, remote access connectivity, web access technologies, and similar capabilities, organizations creating add-ins to Windows Server 2008 R2 can focus on business functions and capabilities, not on core infrastructure reliability, security, and mobile access functionality. This off-loading of the requirement of third-party add-in organizations to implement basic networking technologies into their applications enables these developers to focus on improving the business productivity and functionality of their applications. Additionally, consolidating information routing, security, remote management, and so on into the core operating system provides a common method of communication, authentication, and access to users without having to load up special drivers, add-ins, or tools to support each and every new application.

Much of the shift from application-focused infrastructure components to core operating system-focused functionality was built in to Windows 2000 and then later enhanced in Windows 2003 and Windows Server 2008. There were many challenges to earlier versions of the Windows operating system; however, after being on the market for many years now, Windows Server 2008 R2 add-ins have had several revisions to work through system functionality and component reliability between application and operating system. Fortunately, Windows Server 2008 R2 uses the same application/operating system technology used in Windows 2003 and Windows Server 2008, so applications written for Windows 2003 and Windows Server 2008 typically need just a simple service pack update to be able to run on Windows Server 2008 R2, if anything at all.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Windows Server 2008 R2 Running Built-in Application Server Functions

As much as many administrators think of Active Directory as one of the key areas to upgrade when a new release of the operating system becomes available, in reality, Active Directory tends to not be the first thing updated. Instead, the real business drivers for migrating to Windows Server 2008 R2 typically come from the built-in application server programs that are available on Windows Server 2008 R2.

Windows Server 2008 R2 comes with several programs and utilities to provide robust networking capabilities. Windows Server 2008 R2 can provide name resolution for the network and enable high availability through clustering and fault tolerance, connectivity for mobile users, web services functions, and dozens of other application server functions.

When convincing management that an upgrade to Windows Server 2008 R2 is important, the IT professional needs to sift through the technologies built in to Windows Server 2008 R2 and pick those services that help an organization use technology to achieve its business initiatives. When planning the implementation of Windows Server 2008 R2, a network architect needs to consider which of the server services are desired, how they will be combined on servers, and how they will be made redundant across multiple servers for business continuity failover.

For a small organization, the choice to combine several server functions to a single system or to just a few systems is one of economics. However, an organization might distribute server services to multiple servers to improve performance.

Some of the built-in application server functions in Windows Server 2008 R2 include the following:

. Domain controller—Like in previous versions of the Windows operating system, the domain controller enables users to authenticate to the domain for access to network resources.

. Global catalog server—The global catalog server is a domain controller that also stores a subset of AD DS objects from other domains in the forest. When an internal or external user with appropriate security rights wants to look at a list of Active Directory users in the forest, the global catalog server provides the list.

. DNS server—The domain name system (DNS) maintains a list of network servers and systems and their associated IP addresses, so a DNS server provides information about the devices connected to the network.

. DHCP server—The Dynamic Host Configuration Protocol (DHCP) assigns IPv4 and/or IPv6 network addresses to devices on the network. Windows Server 2008 R2 provides the service function to facilitate DHCP addresses to network devices.

. Cluster server—When fault tolerance is important to an organization, clustering provides failover from one system to another. Windows Server 2008 R2 provides the ability to link systems together so that when one system fails, another system takes over.

. Network Policy Server—NPS is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy. NPS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections. NPS routes authentication and accounting messages to other RADIUS servers. It also acts as a health evaluation server for Network Access Protection (NAP).

. Remote Desktop server—Instead of having a full desktop or laptop computer for each user on the network, organizations have the option of setting up simple, lowcost thin terminals for users to gain access to network resources. Windows Server 2008 R2 Remote Desktop Services allows a single server to host network system access for dozens of users.

. Remote access server—When a remote user has a desktop or laptop system and needs access to network services, Windows Server 2008 R2 provides remote access services that allow the remote systems to establish a secure remote connection.

. Web server—As more and more technologies become web-aware and are hosted on web servers, Windows Server 2008 R2 provides the technology to host these applications for browser-based access.

. Media server—With information extending beyond text-based word processing documents and spreadsheets into rich media such as video and audio, Windows Server 2008 R2 provides a source for hosting and publishing video and audio content.

. Virtualization server—Windows Server 2008 R2 provides the core capabilities to do server virtualization, providing the capability for an organization to consolidate physical servers into fewer host server systems, thus decreasing the total cost of IT operations.

. Distributed File System (DFS) server—For the past decade, data files have been stored on file servers all around an organization. Windows Server 2008 R2 provides Distributed File Systems that allow an organization to take control of distributed files into a common unified namespace.

These plus several other functions provide robust networking services that help organizations leverage the Windows Server 2008 R2 technologies into solutions that solve business needs.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Windows Server 2008 R2 Core to an Active Directory Environment Migration

For an organization that does not have Windows Active Directory already in place, that is
one place to start because Active Directory Domain Services is key to application and user authentication. For organizations that already have a fully operational Active Directory running on Windows 2003 or Windows 2008, upgrading to Active Directory Domain Services on Windows Server 2008 R2 might be something that is addressed a little later in the upgrade cycle when AD DS 2008 R2 functionality is needed. To get a lot of the Windows Server 2008 R2 server functionality like 2008 R2 DFS, SharePoint Services, Hyper-V virtualization, and so on, an organization can still run on an older Active Directory environment (typically Active Directory 2003 native mode). However, the point is that Active Directory 2008 R2 is not a prerequisite to get Windows Server 2008 R2 server role functionality.

Because Active Directory is more than a simple list of users and passwords for authentication into a network, but rather a directory that Microsoft has embedded into the policy based security, remote access security, and certificate-based security enhancements in Windows Server 2008 R2, AD DS 2008 implementation does occur earlier in the migration cycle for organizations wanting to implement many of the new Active Directory 2008 R2 technologies, such as Active Directory Recycle Bin, Offline Domain Join, Managed Service Accounts, and the ability to use PowerShell cmdlets within a Group Policy Object.

Windows Server 2008 R2 extends the capabilities of the Active Directory by creating better management tools, provides for more robust directory replication across a global enterprise, and allows for better scalability and redundancy to improve directory operations. Windows Server 2008 R2 effectively adds in more reliability, faster performance, and better management tools to a system that can be leveraged as a true enterprise directory provisioning, resource tracking, and resource management tool. Because of the importance of Active Directory to the Windows Server 2008 R2 operating system, plus the breadth of capabilities that Active Directory can facilitate.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements in Server Roles in Windows Server 2008 R2

The introduction of Windows Server 2008 R2 added new server roles to Windows as well as enhanced existing roles based on feedback Microsoft received from organizations on features and function wish lists. Server roles are no longer installed by default on a Windows Server 2008 R2 server and have to be selected for installation after the initial installation of the Windows operating system.

Some of the new or improved server roles in Windows Server 2008 R2 include Internet Information Services 7.5, SharePoint Services, Rights Management Service, and Windows virtualization.

Introducing Internet Information Services 7.5
Internet Information Services 7.5 (IIS) is the seventh-generation web server service from Microsoft. Microsoft completely redesigned IIS 7.0 in Windows Server 2008 rather than just adding more functions and capabilities to the exact same IIS infrastructure as they have done for the past several years. The good part of the new IIS 7.x is that it now provides organizations with the ability to manage multiple web servers from a single console, rather than having to install components and configure each web server individually. This requires organizations to rethink and redesign their web management tasks from pushing the same content to dozens of servers individually to a process where information is pushed to a Shared Configuration store, where common information is posted and shared across all IIS 7.x servers. Organizations can continue to post information the old way by pushing information individually to each server; however, to gain the advantage of the new IIS 7.x services, redesigning how information gets posted should be changed to meet the new model.

The advantage of the new model of content posting is that information is stored, edited, and managed in a single location. At a designated time, the information in the single location is posted to each of the servers in the shared application hosting farm. This is a significant improvement for organizations managing and administering a lot of IIS web servers. This ensures that all servers in a farm are using the same content, have been updated simultaneously, and any changes are ensured to be propagated to the servers in the farm. Web administrators no longer have to worry that they forgot a server to update, or to stage an update at a time when each individual server could be updated in a fast enough sequence that the experience of all users was going to occur at around the same time.

Windows SharePoint Services
A significant update provided as part of the Windows Server 2008 client access license
(CAL) is the ability to load and run Windows SharePoint Services. Now in its third generation, Windows SharePoint Services (WSS) is a document-storage management application that provides organizations with the capability to better manage, organize, and share documents, as well as provide teams of users the ability to collaborate on information. Windows SharePoint Services sets the framework from which the Microsoft Office SharePoint Services 2007 (MOSS) is built. MOSS leverages the core functionality of WSS and extends the capability into enterprise environments. WSS is the basis of document sharing and communications for organizations in the evolution of file and information communications.

Windows Rights Management Services
Windows Rights Management Services (RMS) was available as a downloadable feature pack in Windows 2003 and is now included as an installable server role in Windows Server 2008 R2. Windows Rights Management Services sets the framework for secured information sharing of data by encrypting content and setting a policy on the content that
protects the file and the information stored in the file.

Organizations have been shifting to RMS rather than the old secured file folder primarily because users who should be saving sensitive information into a file folder frequently forget to save files in the folder, and thus sensitive information becomes public information. By encrypting the content of the file itself, even if a file with sensitive information is stored in the wrong place, the file cannot be opened, and the information in the file cannot be accessed without proper security credentials to access the file.

Additionally, RMS allows the individual saving the file to set specific attributes regarding what the person would like to be secured about the file. As an example, a secured file in RMS can be set to not be edited, meaning that a person receiving the file can read the file, but he or she cannot select content in the file, copy the content, or edit the content. This prevents individuals from taking a secured file, cutting and pasting the content into a different file, and then saving the new file without encryption or security.

RMS also provides attributes to enable the person creating a file to prevent others from printing the file. The file itself can have an expiration date, so that after a given period of time, the contents of the file expire and the entire file is inaccessible.

Windows Server Virtualization
A new technology that wasn’t quite available at the time Windows Server 2008 shipped in 2008, but has since been released and available on the original Windows Server 2008 R2 DVD, is Windows server virtualization known as Hyper-V. Hyper-V provides an organization with the ability to create guest operating system sessions, on a Windows Server 2008 R2 server to get rid of physical servers, and instead make the servers available as virtual server sessions.

Instead of purchasing a new physical server every time a new server system needs to be placed on the network, a virtual server can be created that has all the same operations and functions as the physical server itself. Or, for organizations that are putting in place disaster recovery centers and server clustering for better server reliability and redundancy, virtualization allows the addition of these additional servers within the guest operating system space of a single server system.

Virtualization in Windows Server 2008 R2 supports 64-bit and 32-bit guest sessions; has a built-in tool that allows a snapshot of a virtual session so that the session can be protected or rolled back in the event of a guest image failure or corruption; and has virtual sessions that can span terabytes of disk storage and use 16GB, 32GB, or more of memory per guest session. Windows Server 2008 R2 Hyper-V supports “live migrations,” which allows for a faster failover and recovery of a virtual guest session across host servers.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Addition of Migration Tools

Beyond the standard migration tools that help administrators migrate from one version of Active Directory to another, or to perform an in-place upgrade from one version of Windows to another, Windows Server 2008 R2 has migration tools to help administrators move entire server roles from one system to another. These new tools provide migration paths from physical servers to virtual servers, or from virtual servers to physical servers. Other tools allow for the migration of DHCP configuration and lease information from one server to another. These tools and the prescriptive guidance help administrators migrate servers more easily than ever before.

Operating System Migration Tools
Windows Server 2008 R2 provides tools that help administrators migrate from older versions of the Windows Server operating system to Windows Server 2008 R2. The supported migration paths are as follows:

. Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2—These operating systems can be migrated to Windows Server 2008 R2 using the operating system migration tools and guidance documentation. . x86 and x64—Servers can be migrated from x86 to x64 and from x64 to x64 with limitations. Because Windows Server 2008 R2 is an x64 operating system only, there is no in-place upgrade support from x86 to x64, so the upgrade path is a server-toserver transition, not in-place. However, x64 to x64 in-place is supported as long as any applications sitting on the server can be upgraded from one x64 platform to the Windows Server 2008 R2 x64 platform.

. Full Server and ServerCore—Operating system migration from Full Server to ServerCore and from ServerCore to Full Server are supported typically as a server toserver migration because in-place migrations between Full Server and ServerCore have limitations. The GUI needs to be added or removed and, thus, applications are typically migrated rather than complete operating system migrations between the platforms.

. Physical and virtual—Virtualization of guest sessions is the de facto standard in data centers these days and the implementation of applications on virtual guest sessions is the norm. As such, organizations wanting to migrate from physical server configurations to virtual guest sessions can leverage the migration tools and guidance available in performing server and application migrations to virtual server roles.

Server Role Migrations
Included in Windows Server 2008 R2 are tools and guidance that help administrators migrate server roles to Windows Server 2008 R2 server systems. The supported migration paths are as follows:

. Active Directory Domain Services—The migration from Active Directory 2003 and Active Directory 2008 to Active Directory 2008 R2 is fully supported.

. DNS and DHCP migrations—New migration tools are available that help administrators migrate their DNS and DHCP servers from running on previous versions of Windows to servers running Windows Server 2008 R2, and not only just the service configurations but also DNS and DHCP data. In the past, the migration of DHCP to a new server usually meant the loss of DHCP lease information. With the new migration tools in Windows Server 2008 R2, an administrator can now migrate the server configuration as well as the lease data, including lease expiration data, as part of the migration process.

. File and print migrations—Included in the migration tools for Windows Server 2008 R2 are features that migrate file data, included file permissions, and the migration of print server configurations and settings from older servers to new Windows Server 2008 R2 configurations. These migration tools help simplify the process of updating servers from old server systems to new systems with the least amount of impact on the organization and drastically simplify the process of migration for domain administrators.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Restoring Deleted AD DS Objects Using the Active Directory Recycle Bin

One of the most significant additions to Windows Server 2008 R2’s implementation of AD DS is the Active Directory Recycle Bin. A Windows Server 2008 R2 Active Directory forest and domain now allows for the recovery of deleted OUs, users, groups, or other AD objects. There are a few prerequisites that must be satisfied, however, before the AD Recycle Bin can be enabled:

. The AD DS forest and domain must be in Windows Server 2008 R2 functional level.

. When restoring objects, the OU in which they previously existed must first be restored. If the object resided in a nested OU structure, the top-level OU must first be restored, followed by the next-highest child OU, and so on.

. Membership in the Enterprise Administrators group is required to enable the AD Recycle Bin.

. The process of enabling the AD Recycle Bin is nonreversible.

Enabling the AD Recycle Bin
To enable the Active Directory Recycle Bin, perform the following steps:

1. Click Start, All Programs, Administrative Tools. Right-click on Active Directory Module for Windows PowerShell and then click Run As Administrator.

2. From the PowerShell prompt, type the following command.

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional
Features,CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=companyabc,DC=com’ –Scope
ForestOrConfigurationSet –Target ‘companyabc.com’

Replace companyabc.com and DC=companyabc,DC=com with the appropriate name of the domain where the AD Recycle Bin will be enabled.

3. When prompted, type Y to confirm and press Enter.

4. To validate that the Recycle Bin is enabled, go to the CN=Partitions container, using an editor such as ADSIEdit. In the details pane, find the msDS-EnabledFeature attribute, and confirm that the value includes the Recycle Bin target domain name that you typed in step 2.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements in Clustering and Storage Area Network Support

Although clustering of servers has been around for a long time in Windows (dating back to Windows NT 4.0, when it was available, but really didn’t work), clustering in Windows Server 2008 R2 now not only works, but also provides a series of significant improvements that actually make clustering work a whole lot better. Note that there are often Newegg coupons available for Windows products.

As IT administrators are tasked with the responsibility of keeping the network operational 24 hours a day, 7 days a week, it becomes even more important that clustering works. Fortunately, the cost of hardware that supports clustering has gotten significantly less expensive; in fact, any server that meets the required specifications to run Windows Server 2008 R2, Enterprise Edition can typically support Windows clustering. The basic standard for a server that is used for enterprise networking has the technologies built in to the system for high availability. Windows Server 2008 R2, Enterprise Edition or Datacenter Edition is required to run Windows Server 2008 R2 clustering services.

No Single Point of Failure in Clustering
Clustering by definition should provide redundancy and high availability of server systems; however, in previous versions of Windows clustering, a “quorum drive” was required for the cluster systems to connect to as the point of validation for cluster operations. If at any point the quorum drive failed, the cluster would not be able to failover from one system to another. Windows Server 2008 and Windows Server 2008 R2 clustering removed this requirement of a static quorum drive. Two major technologies facilitate this elimination of a single or central point of failure, which include majority-based cluster membership verification and witness-based quorum validation.

The majority-based cluster membership enables the IT administrator to define what devices in the cluster get a vote to determine whether a cluster node is in a failed state and the cluster needs to failover to another node. Rather than assuming that the disk will always be available as in the previous quorum disk model, now nodes of the cluster and shared storage devices participate in the new enhanced quorum model in Windows Server 2008 R2. Effectively, Windows Server 2008 R2 server clusters have better information to determine whether it is appropriate to failover a cluster in the event of a system or device failure.

The witness-based quorum eliminates the single quorum disk from the cluster operation validation model. Instead, a completely separate node or file share can be set as the file share witness. In the case of a GeoCluster where cluster nodes are in completely different locations, the ability to place the file share in a third site and even enable that file share to serve as the witness for multiple clusters becomes a benefit for both organizations with distributed data centers and also provides more resiliency in the cluster operations components.

Stretched Clusters
Windows Server 2008 R2 also introduced the concept of stretched clusters to provide better server and site server redundancy. Effectively, Microsoft has eliminated the need to have cluster servers remain on the same subnet, as has been the case in Windows clustering in the past. Although organizations have used virtual local area networks (VLANs) to stretch a subnet across multiple locations, this was not always easy to do and, in many cases, technologically not the right thing to do in IP networking design.

By allowing cluster nodes to reside on different subnets, plus with the addition of a configurable heartbeat timeout, clusters can now be set up in ways that match an organization’s disaster failover and recovery strategy.

Improved Support for Storage Area Networks
Windows Server 2008 R2 also has improved its support for storage area networks (SANs) by providing enhanced mechanisms for connecting to SANs as well as switching between SAN nodes. In the past, a connection to a SAN was a static connection, meaning that a server was connected to a SAN just as if the server was physically connected to a direct attached storage system. However, the concept of a SAN is that if a SAN fails, the server should reconnect to a SAN device that is now online. This could not be easily done with Windows 2003 or prior. SCSI bus resets were required to disconnect a server from one SAN device to another.

With Windows Server 2008 R2, a server can be associated with a SAN with a persistent reservation to access a specific shared disk; however, in the event that the SAN fails, the server session can be logically connected to another SAN target system without having to script device resets that have been complicated and disruptive in disaster recovery scenarios.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements for Thin Client Remote Desktop Services

Windows Server 2008 R2 has seen significant improvements in the Terminal Services (now called Remote Desktop Services [RDS]) capabilities for thin client access for remote users and managed users in the enterprise. What used to require third-party add-ons to make the basic Windows 2000 or 2003 Terminal Services functional, Microsoft included those technologies into Windows Server 2008 and further enhanced them in Windows Server 2008 R2. These technologies include things such as the ability to access Remote Desktop Services using a standard Port 443 SSL port rather than the proprietary Port 3389, or the ability to publish just specific programs instead of the entire desktop, and improvements in allowing a client to have a larger remote access screen, multiple screens, or to more easily print to remote print devices.

These improvements in Windows Server 2008 R2 Remote Desktop Services have made RDS one of the easiest components to add to an existing Windows 2003 Active Directory to test out the new Windows Server 2008 R2 capabilities, especially because the installation of a Windows Server 2008 R2 Remote Desktop Services system is just the addition of a member server to the domain and can easily be removed at any time.

Improvements in RDP v6.x for Better Client Capabilities
The first area of significant improvement in Windows Server 2008 Terminal Services was addressed in the update to the Remote Desktop Protocol (RDP) v6.x client.

The RDP client with Windows Server 2008 provided the following:
. Video support up to 4,096 x 2,048—Users can now use very large monitors across an RDP connection to view data off a Windows Server 2008 Terminal Services system. With Windows Server 2008 R2 Remote Desktop Services, the latest support has been extended to support DirectX 9, 10, and 11 redirection.

. Multimonitor support—Users can also have multiple (up to 10) monitors supported off a single RDP connection. For applications like computer-aided design (CAD), graphical arts, or publishing, users can view graphical information on one screen and text information on another screen at the same time.

. Secured connections—The new RDP client now provides for a highly encrypted remote connection to a Remote Desktop Services system through the use of Windows Server 2008 R2 security. Organizations that need to ensure their data is protected and employee privacy is ensured can implement a highly secured encrypted connection between a Windows Server 2008 R2 Remote Desktop Services system and the remote client.

Remote Desktop Services Web Access
Also new to Windows Server 2008 and extended in Windows Server 2008 R2 Remote
Desktop Services is a new role called Remote Desktop Services Web Access. Remote
Desktop Services Web Access allows a remote client to access a Remote Desktop Services session without having to launch the RDP 6.x client, but instead connect to a web page that then allows the user to log on and access their session off the web page. This simplifies the access method for users where they can just set a browser favorite to link them to a web URL that provides them with Terminal Services access.

Remote Desktop Services Web Access still requires the client system to be a Windows XP, Windows Vista, Windows 7, Windows 2003, Windows Server 2008, or Windows Server 2008 R2 server system to connect to a Remote Desktop Services session. A browser user cannot be running from an Apple Macintosh or Linux system and access Remote Desktop Services Web Access. For non-Windows-based web clients, third-party vendors like Citrix Systems provide connector support for these types of devices.

Remote Desktop Services Gateway
Remote Desktop Services Gateway is an update to Windows Server 2008 R2 Remote Desktop Services and provides the connectivity to a Remote Desktop Services session over a standard Port 443 SSL connection. In the past, users could only connect to Windows Remote Desktop Services using a proprietary Port 3389 connection. Unfortunately, most organizations block nonstandard port connections for security purposes, and, thus, if a user was connected to an Internet connection at a hotel, airport, coffee shop, or other location that blocked nonstandard ports, the user could not access Terminal Services.

Now with Remote Desktop Services Gateway, the remote user to the Remote Desktop Services Gateway connection goes over Port 443 just like surfing a secured web page. Because of the use of SSL in web page access (anytime someone accesses a web page with https://), effectively now a user can access Windows Server 2008 R2 Remote Desktop Services from any location.

Remote Desktop Services RemoteApps
Another new server role added to Windows Server 2008 and updated in Windows Server 2008 R2 is called Remote Desktop Services RemoteApps. Remote Desktop Services RemoteApps allows administrators to “publish” certain applications for users to access. These applications could be things like Microsoft Outlook, Microsoft Word, the company’s time sheet tracking software, or a customer relationship management (CRM) program. Instead of giving users full access to a full desktop session complete with a Start button and access to all applications on the session, an organization can just publish a handful of applications that it allows for access.

Leveraging group policies and Network Policy Server, along with Remote Desktop Services RemoteApps, the administrators of a network can publish different groups of applications for different users. So, some users might get just Outlook and Word, whereas other users would get Outlook, Word, and the CRM application. Add in to the policy component the ability to leverage network location awareness, the administrators of the network can allow different applications to be available to users depending on whether the user is logging on to the network on the LAN or from a remote location. Beyond just limiting users to only the programs they should have access to by policy, Remote Desktop Services RemoteApps minimizes the overhead for each user connection because the user no longer has a full desktop running, but only a handful of applications deemed necessary for the remote user’s access.

Remote Desktop Services Connection Broker
Formerly called the Session Broker in Windows Terminal Services, the Remote Desktop Services Connection Broker is a system that manages Remote Desktop sessions to ensure that if users are disconnected from a Remote Desktop server, the users can reestablish a connection to their session without loss of the session state. Without a Connection Broker, users who attempt to reconnect to Remote Desktop Services after a session disconnect might end up logging on to a completely different Remote Desktop server and have to go back to where they last saved data to pick up where they left off.

Other than the name change from Session Broker to Connection Broker, new to Windows Server 2008 R2 Connection Broker is the ability to cluster this role. In the past, this role was a single server instance. In the event that this server session was down, the connection states would not be preserved and the Session Broker would not do its job. By clustering the Connection Broker role, an organization can now add redundancy to a critical role for an organization that has several Remote Desktop servers and wants to provide users with the ability to reconnect back to their session after a temporary disconnect.

Virtual Desktop Infrastructure (VDI)
Lastly, a completely new role added to Windows Server 2008 R2 is the Virtual Desktop Infrastructure, or VDI role. Instead of Remote Desktop Services that provides a one to many experience, where effectively a single server instance is shared across multiple users, VDI provides a one-to-one virtual guest session relationship between the server and remote client. When a VDI client user logs on to a guest session, a dedicated guest session is made available to the user with a separate client boot-up shell, separate memory pool allocated, and complete isolation of the guest session from other guest sessions on the host server.

Windows Server 2008 R2 VDI provides two different VDI modes. One mode is a personalized desktop and the other is a pooled desktop. The personalized desktop is a dedicated guest session that users have access to each and every time they log on to the VDI server. It is basically a dedicated guest session where the image the guest uses is the same every time. A pooled desktop is a guest session where the user settings (favorites, background, and application configuration settings) are saved and reloaded on logon to a standard template. Actual guest session resources are not permanently allocated but rather allocated and dedicated at the time of logon.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements in Windows Server 2008 R2 for Better Branch Office Support

Windows Server 2008 R2 has greatly enhanced the technology offerings that provide better IT services to organizations with remote offices or branch offices. Typically, a remote or branch office has limited IT support or at least the site needs to have the same functionality and reliability as the main corporate or business office, but without the budget, to have lots of redundant hardware and devices for full operational support. With the new Windows Server 2008 R2 branch office resources, a remote location can now have high security, high performance, access to data without significant latency, and operational capabilities, even if the remote site is dropped off the network due to a WAN or Internet connection problem.

The tools and technologies new or improved in Windows Server 2008 R2 include Read Only Domain Controllers, BitLocker Drive Encryption, distributed file server data replication, and distributed administration.

Read-Only Domain Controllers for the Branch Office
The RODC provides a copy of the Active Directory global catalog for logon authentication of select users and communications with the Active Directory tree without having the security exposure of a full global catalog server in the remote location. Many organizations concerned with distributed global catalog servers chose to not place a server in a remote location, but rather kept their global catalog and domain controllers centralized. What this meant for remote and branch offices is that all logon authentication had to go across the WAN or Internet connection, which could be very slow. And in the event of a WAN or Internet connection failure, the remote or branch office would be offline because users could not authenticate to the network and access network resources until the WAN or Internet connection was restored.

Read-Only Domain Controllers provide a way for organizations to distribute authentication and Active Directory access without increasing their security risk caused by the distribution of directory services.

BranchCache File Access
New to Windows Server 2008 R2 is a role called BranchCache. BranchCache is a technology that provides users with better access to files across a wide area network (WAN). Normally, if one user accesses a file, the file is transferred across the WAN for the user, and then when another user accesses the same file, the same file is again transferred across the WAN for the other user. BranchCache acknowledges that a file has been transferred across the WAN by a previous user, and instead of retrieving the file across the WAN, the file is accessed locally by the subsequent user.

BranchCache requires Windows 7 on the client side and can be set up so that the file is effectively retrieved in a peer-to-peer manner from another Windows 7 client that had previously accessed a file. Or, a Windows Server 2008 R2 server with the BranchCache server role can be set up in the remote location where remotely accessed files are temporarily cached for other Windows 7 client users to seamlessly access the files locally instead of being downloaded across the WAN.

BranchCache does not require the user to do anything differently. Users simply accesses files as they normally do (either off a Windows file system or from a SharePoint document library), and the combination of Windows 7 and Windows Server 2008 R2 does all the caching automatically. BranchCache has proven to improve access time on average 30%–45% for remote users, thus increasing user experience and potentially user productivity by having faster access to information in remote locations.

BitLocker for Server Security
BitLocker is a technology first introduced with Windows Vista that provides an organization with the ability to do a full partition encryption of all files, documents, and information stored on the encrypted partition. When BitLocker was first introduced in Windows Server 2008 as a server tool, it was hard to understand why a server would need to have its drive volume encrypted. It made sense that a laptop would be encrypted in the event the laptop is stolen—so that no one could get access to the data on the laptop hard drive. However, when considering that servers are placed in remote locations—many times not in a locked server rack in a locked computer room but rather sitting in a closet or even under a cash register in the situation of a retail store with a server acting as the point-ofsale system—servers with sensitive data are prevalent in enterprise environments.

So, BitLocker provides encryption of the volume of a Windows Server 2008 R2 server; for organizations that are concerned that the server might be physically compromised by the theft of the server or physical attack of the system, BitLocker is a great component to implement on the server system.

Distributed File System Replication
Introduced in Windows 2000, improved in Windows 2003, and now a core component of the branch office offerings in Windows Server 2008 R2, Distributed File System Replication (DFSR) allows files to be replicated between servers, effectively providing duplicate information in multiple locations. Windows Server 2008 R2 has a much improved Distributed File System than what was available in Windows 2000/2003. In most organizations, files are distributed across multiple servers throughout the enterprise. Users access file shares that are geographically distributed but also can access file shares sitting on several servers in a site within the organization. In many organizations, when file shares were originally created years ago, server performance, server disk capacity, and the workgroup nature of file and print server distribution created environments in which those organizations had a file share for every department and every site. Thus, files have typically been distributed throughout an entire organization across multiple servers.

Windows Server 2008 R2 Distributed File System Replication enables an organization to combine file shares to fewer servers and create a file directory tree not based on a serverby-server or share-by-share basis, but rather an enterprisewide directory tree. This allows an organization to have a single directory spanning files from multiple servers throughout the enterprise.

Because the DFSR directory is a logical directory that spans the entire organization with links back to physical data, the actual physical data can be moved without having to make changes to the way the users see the logical DFS directory. This enables an organization to add or delete servers, or move and consolidate information, however it works best within the organization.

For branch office locations, DFSR allows for data stored on a file server in a remote location to be trickled back to the home office for nightly backup. Instead of having the remote location responsible for data backup, or the requirement of an organization to have tape drives in each of its branch offices, any data saved on the branch office can be trickle replicated back to a share at the main office for backup and recovery.

If the main office has data that it wants to push out to all remote offices, whether that is template files, company policy documents, standard company materials, or even shared data that a workgroup of users needs to access and collaborate on, DFSR provides the ability to push out data to other servers on the network. Users with access rights to the data no longer have to go across a WAN connection to access common data. The information is pushed out to a server that is more local to the user, and the user accesses the local copy of the information. If any changes are made to remote or centralized copies of data, those changes are automatically redistributed back to all volumes storing a copy of the data.

One of the enhancements made in Windows Server 2008 R2 specific to DFS-R is the ability for an administrator to set a DFS replica to be read-only. In the past, DFS replicas were all read/write replicas so that a user in a remote location could accidentally overwrite files that then replicate to all replicas in the environment. Administrators have compensated for this potential issue by setting file-level permissions across files and folders; however, for many remote branch offices, if the administrator could simply make the entire replica read-only, it would simplify the security task dramatically. Thus, read-only replicas can now be set so that an entire server or branch of a DFS tree can be set to replicate to a remote server on a read-only basis.

Improvements in Distributed Administration
Finally, for remote or branch offices that do have IT personnel in the remote locations, administration and management tasks have been challenging to distribute proper security rights. Either remote IT personnel were given full domain administrator rights when they should only be limited to rights specific to their site, or administrators were not given any administrative rights because it was too difficult to apply a more limiting role.

Windows Server 2008 R2 Active Directory has now defined a set of rights specific to branch office and remote site administrators. Very similar to site administrators back in the old Exchange Server 5.5 days—where an administrator was able to add users, contacts, and administer local Exchange servers—now network administrators in Active Directory can be delegated rights based on a branch or remote site role. This provides those administrators with the ability to make changes specific to their branch location. This, along with all the other tools in Windows Server 2008 R2 specific to branch office and remote office locations, now provides better IT services to organizations with multiple offices in the enterprise.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements in Mobile Computing in Windows Server 2008 R2

As organizations find their workforce becoming more and more mobile, Microsoft has made significant improvements to mobility in Windows Server 2008 R2. New technologies provide a more seamless experience for users with laptops to move from office, to home, to Internet Wi-Fi hot spots and maintain connectivity to network resources. These improvements do require mobile users to run the latest Windows 7 client operating system on their laptop system to gain access to these new services; however, once implemented, users find the functionality to greatly support easier access to network resources no matter where the user resides.

Windows Server 2008 R2 DirectAccess
One of the significant remote access enhancements in Windows Server 2008 R2 is the DirectAccess technology. DirectAccess provides a remote user the ability to access network resources such as file shares, SharePoint shares, and the like without having to launch a virtual private network (VPN) to gain access into the network.

DirectAccess is an amazing technology that combines sophisticated security technology and policy-based access technology to provide remote access to a network; however, organizations do find it challenging to get up to speed with all the technology components necessary to make DirectAccess work. So, although many organizations will seek to achieve DirectAccess capabilities, it might be months or a couple of years before all the technologies are in place for the organization to easily enable DirectAccess in their enterprise environment.

Some of the technologies required to make DirectAccess work include the following:

. PKI certificates—DirectAccess leverages PKI certificates as a method of identification of the remote device as well as the basis for encrypted communications from the remote device and the network. Thus, an organization needs to have a good certificate infrastructure in place for server and client certificate-based encrypted communications.

. Windows 7 clients—DirectAccess only works with clients that are running Windows 7. The client component for encryption, encapsulation, and policy control depend on Windows 7 to make all the components work together.

. IPSec—The policy control used in DirectAccess leverages IPSec to identify the destination resources that a remote user should have access to. IPSec can be endpoint to endpoint (that is, from the client system all the way to the application server) or IPSec can be simplified from the client system to a DirectAccess proxy server where the actual endpoint application servers do not need to be IPSec enabled. In any case, IPSec is a part of the security and policy structure that ensures the remote client system is only accessing server resources that by policy the remote client should have access to as part of the DirectAccess session connection.

. IPv6—Lastly, DirectAccess uses IPv6 as the IP session identifier. Although most organizations have not implemented IPv6 yet and most on-ramps to the Internet are still IPv6, tunneling of IPv6 is fully supported in Windows 7 and Windows Server 2008 R2 and can be used in the interim until IPv6 is fully adopted. For now, IPv6 is a requirement of DirectAccess and is used as part of the remote access solution.

Windows 7 VPN Reconnect
VPN Reconnect is not a Windows Server 2008 R2–specific feature but rather a Windows 7 client feature; however, with the simultaneous release of the Windows 7 client and Windows Server 2008 R2, it is worth noting this feature because Microsoft will be touting the technology and network administrators will want to know what they need to do to implement the technology. VPN Reconnect is simply an update to the VPN client in Windows 7 that reestablishes a VPN session on a client system in the event that the client system’s VPN session is disconnected.

VPN Reconnect effectively acknowledges that a client VPN session has been disconnected and reestablishes the session. Many longtime administrators might wonder why this is new because client systems in the past (Windows XP, Vista, and so forth) have always had the ability to retry a VPN session upon disconnect. However, the difference is that instead of simply retrying the VPN session and establishing a new VPN session, the VPN Reconnect feature of Windows 7 reestablishes a VPN session with the exact same session identification, effectively allowing a session to pick up exactly where it left off.

For example, a Windows 7 client user can be transferring a file on a wired VPN connected session and then switch midstream to a Wi-Fi VPN-connected session, and the file transfer will continue uninterrupted.

VPN Reconnect utilizes the IKE v2 protocol on the client and on the Windows Server 2008 R2 side with an established session identification so that upon reconnect, the session ID remains the same.

Windows 7 Mobile Broadband
Another Windows 7–specific technology for mobile users is Windows 7 Mobile Broadband. Again, something that has nothing to do specifically with Windows Server 2008 R2, Windows 7 Mobile Broadband is an update to the carrier-based (for example, AT&T, Sprint, Verizon) mobile connection devices and services in Windows 7.

In the past, a user plugged in a Mobile Broadband card to their Windows XP or Vista system and then had to launch an application such as the AT&T Connection Manager. With Windows 7 and the latest Mobile Broadband drivers for the device and for Windows 7, the insertion of the Mobile Broadband card into a mobile system automatically connects the user to the Internet. Just like if the user turns on a Wi-Fi adapter in a system and automatically establishes a connection to a Wi-Fi access point, Mobile Broadband automatically connects the user to the Internet.

When the Windows 7 Mobile Broadband adapter is disconnected from the user’s system, the Mobile Broadband session disconnects, and if the system has a Wi-Fi or wired Ethernet connection available, the user’s system automatically connects to an alternate connection point. Combine Mobile Broadband with VPN Reconnect or with DirectAccess and a mobile user has seamless connection access back into their organization’s network.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Improvements in Security in Windows Server 2008 R2

Significantly more than just cosmetic updates are the security enhancements added to
Windows Server 2008 R2. As organizations are struggling to ensure that their environments are secure, employees can depend on information privacy, and content is protected for regulatory compliance reasons; having the tools to secure the environment is critical.

Enhancing the Windows Server 2008 R2 Security Subsystem
Windows Server 2008 R2 includes the basics of server hardening, patching, and updating but also extends into new server security areas added to Windows Server 2008 R2, such as device control level security, wireless access security, and Active Directory Rights Management Services (RMS). Windows Server 2008 R2 has continued the “secure by default” theme at Microsoft and no longer installs components like Internet Information Services (IIS) by default. The good part about it is that components that are not core to the operation of a server are not installed on the system; however, it means every time you install software, you need to add basic components and features. Getting to remember what has to be installed, configured, or made operational is important as servers are being built and added to a Windows Active Directory environment.

Transport Security Using IPSec and Certificate Services
“Transport-Level Security,” addresses site-to-site and server-to-server security, addressed through the implementation of IPSec encryption. Not new to Windows, IPSec has finally gotten several new Group Policy management components added to aid in the implementation and management of IPSec in the enterprise. Also not new to Windows, but something that has been greatly enhanced, is Microsoft’s offering around Public Key Infrastructure (PKI), specifically Certificate Services. It seems like everything security related is somehow connected to certificates, whether that is file encryption using Encrypting File System (EFS), email encryption using S/MIME, remote mobile device synchronization using certificate access, or transport security using IPSec. Everything needs a certificate, and the ability of an organization to easily create and manage certificates.

Security Policies, Policy Management, and Supporting Tools for Policy Enforcement
Completely new to Windows Server 2008, updated in Windows Server 2008 R2, and a major focus for organizations are security policies and policy management around security systems. It used to be we would just lock down systems, make sure they were secure by default, and use our best judgment and best effort to secure a network. However, with laws and regulations, or even human resource departments getting involved in information security, the root of all IT security practices fall on having set security policies defined so that IT can implement technologies to address the organization policies around information security.

Tools like the Network Policy Server in Windows Server 2008 R2 allow policies to be defined, and the Network Policy Server enforces those policies, specifically around remote logon access, access over wireless network connections, or the integration of Network Access Protection (NAP) in querying a device and making sure the device (desktop, laptop, or mobile device) has the latest patches, updates, and antivirus software dictated by management to ensure a device is secure.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Cloud storage is for blocks too, not just files

One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...