RODC FeaturesRead-only domain controllers (RODCs) address some of the problems that might be caused by branch office locations that either have no domaincontroller or that have a writable domain controller but not the physical security, network bandwidth, and local expertise to support it. Thefollowing characteristics of RODCs help to solve these problems: Read-only Active Directory database RODC filtered attribute set Unidirectional replication Credential caching Administrator role separation Read-only Domain Name SystemRead-only Active Directory databaseExcept for account passwords and other filtered attributes, an RODC holds the same user accounts and attributes that a writable domain controllerholds. Clients, however, are not able to write changes directly to the RODC. Local applications that request Read access to the directory obtainaccess, whereas Lightweight Directory Access Protocol (LDAP) applications that perform a Write operation are referred to a writable domaincontroller in a hub site.RODC filtered attribute setSome applications that use AD DS as a data store may have credential-like data (such as passwords, credentials, or encryption keys) that you donot want to be stored on an RODC in case the RODC is stolen or compromised. For this type of application, you can take the following steps tohelp prevent unnecessary exposure of such attributes: Add the attribute to the RODC filtered attribute set to prevent it from replicating to RODCs in the forest. Mark the attribute as confidential, which removes the ability to read the data for members of the Authenticated Users group (including any RODCs).Adding attributes to the RODC filtered attribute setThe RODC filtered attribute set is a dynamic set of attributes that is not replicated to any RODCs in the forest. You can configure the RODCfiltered attribute set on a schema master that runs Windows Server 2008. When the attributes are prevented from replicating to RODCs, that datacannot be exposed unnecessarily if an RODC is stolen or compromised.A malicious user who compromises an RODC can attempt to configure it in such a way that it tries to replicate attributes that are defined in theRODC filtered attribute set. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, thereplication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is runningWindows Server 2003, the replication request could succeed.Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan to configure the RODC filteredattribute set. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner becausedomain controllers that are running Windows Server 2003 are not allowed in the forest.You cannot add system-critical attributes to the RODC filtered attribute set. An attribute is system critical if it is required for AD DS, LocalSecurity Authority (LSA), Security Accounts Manager (SAM), and any of Microsoft-specific Security Service Providers, such as the Kerberosauthentication protocol, to function properly. A system-critical attribute has a schemaFlagsEx attribute value of (schemaFlagsEx attribute value& 0x1 = TRUE).
Make sure that the schema operations master is running Windows Server 2008 when you add attributes to the RODC filtered attribute set so thatthe attributes are verified to not be system critical. If you try to add a system-critical attribute to the RODC filtered set while the schema master isrunning Windows Server 2008, the server returns an LDAP error "unwillingToPerform" (0x35). The Windows Server 2003 operating systemdoes not use the RODC filtered attribute set. If you try to add a system-critical attribute to the RODC filtered attribute set while the schemamaster is running Windows Server 2003, the operation will appear to succeed but the attribute will not actually be added to the set.Marking attributes as confidentialIn addition, we recommend that you also mark as confidential any attributes that you configure as part of the RODC filtered attribute set. To markan attribute as confidential, you have to remove the Read permission for the attribute for the Authenticated Users group. Marking the attribute asconfidential provides an additional safeguard against an RODC that is compromised by removing the permissions that are necessary to read thecredential-like data.Before you mark an attribute as confidential, thoroughly test the effect that this action might have on your applications. For more informationabout marking attributes as confidential, see article 922836 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=99814).Default RODC filtered attribute setThe following attributes are configured as part of the RODC filtered attribute set. They are marked as confidential by default to supportCredential Roaming and BitLocker Drive Encryption in Windows Server 2008: ms-PKI-DPAPIMasterKeys ms-PKI-AccountCredentials ms-PKI-RoamingTimeStamp ms-FVE-KeyPackage ms-FVE-RecoveryPassword ms-TPM-OwnerInformationFor procedures that describe how to add an attribute to the RODC filtered attribute set, see Appendix D: Steps to Add an Attribute to the RODCFiltered Attribute Set.Unidirectional replicationBecause no changes are written directly to the RODC and therefore do not originate locally, writable domain controllers that are replicationpartners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make at branchlocations cannot replicate from the RODC to the rest of the forest. This also reduces the workload of bridgehead servers in the hub site and theeffort required to monitor replication.RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. The RODC performsnormal inbound replication for AD DS and SYSVOL changes.NoteAny other share resources on an RODC that you configure to replicate using DFS Replication are bidirectional.Credential cachingCredential caching is the storage of user account or computer account credentials. Account credentials consist of a small set of attributes that areassociated with security principals. For more information about the attributes that make up account credentials, see “User and computercredentials” in Appendix A: Technical Reference Topics (http://go.microsoft.com/fwlink/?LinkID=128273).
By default, an RODC does not store account credentials, except for its own computer account and a special krbtgt account for that RODC. Youmust explicitly allow any other credentials to be cached on that RODC, including the appropriate user, computer, and service accounts, to allowthe RODC to satisfy authentication and service ticket requests locally.When only users from the branch are encompassed by the Allow List, the RODC is not able to satisfy requests for service tickets locally, and itrelies on access to a writable domain controller to do so. In a wide area network (WAN) offline scenario, this condition probably leads to aservice outage.The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and passwordthan the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests. This provides cryptographicisolation between KDCs in different branches, which prevents a compromised RODC from issuing service tickets to resources in other branchesor a hub site.After an account is successfully authenticated, the RODC attempts to contact and pull the user credentials or computer credentials from a writabledomain controller that is running Windows Server 2008 at the hub site. The hub site can be any Active Directory site where writable domaincontrollers running Windows Server 2008 are securely deployed.The Password Replication Policy (PRP) that is enforced at the writable domain controller determines whether the credentials of an account can bereplicated from the writable domain controller to the RODC. If the PRP allows it, the RODC replicates the credentials from the writable domaincontroller and the RODC caches them. After the credentials are cached on the RODC, the RODC can directly service logon requests for thataccount until the credentials change.By limiting credential caching to only accounts that have authenticated to the RODC and for which the PRP allows credentials to be cached, thepotential exposure of credentials by a stolen RODC is also limited. This is because, typically, only a small subset of domain users and computershas credentials cached on any given RODC. Therefore, if the RODC is stolen, only those credentials that are cached can potentially becompromised.Administrator role separationAdministrator role separation specifies that any domain user or security group can be delegated to be the local administrator of an RODC withoutgranting that user or group any rights for the domain or other domain controllers. Accordingly, a delegated administrator can log on to an RODCto perform maintenance work, such as upgrading a driver, on the server. But the delegated administrator is not able to log on to any other domaincontroller or perform any other administrative task in the domain. In this way, a security group that comprises branch users, rather than membersof the Domain Admins group, can be delegated the ability to effectively manage the RODC in the branch office, without compromising thesecurity of the rest of the domain.Read-only Domain Name SystemYou can install the Domain Name System (DNS) Server service on an RODC. An RODC is able to replicate all the application directorypartitions that DNS uses, including ForestDNSZones and DomainDNSZones. If a DNS server is installed on an RODC, clients can query it forname resolution as they might query any other DNS server.However, the DNS server on an RODC does not support client updates directly. When a client attempts to update its DNS records against anRODC, the server returns a referral. The client then attempts the update against the DNS server that is provided in the referral. In the background,the DNS server on the RODC attempts to replicate the updated record from the DNS server that made the update. This replication request is onlyfor a single object (the DNS record). The entire list of changed zone or domain data is not replicated during this special, replicate-single-objectrequest.Whats New in Hyper-V in Windows Server2008 R218 out of 23 rated this helpful - Rate this topic
Updated: October 19, 2011Applies To: Windows Server 2008 R2What are the major changes?The Hyper-V™ role enables you to create and manage a virtualized server computingenvironment by using a technology that is part of Windows Server® 2008 R2. Theimprovements to Hyper-V include new live migration functionality, support for dynamic virtualmachine storage, and enhancements to processor and networking support.NoteFor information about new features in Hyper-V in Windows Server® 2012, seehttp://go.microsoft.com/fwlink/p/?LinkId=234786.The following changes are available in Windows Server 2008 R2: Live migration Dynamic virtual machine storage Enhanced processor support Enhanced networking supportWhat does Hyper-V do?Hyper-V is a role in Windows Server 2008 R2 that provides you with the tools and services youcan use to create a virtualized server computing environment. This virtualized environment canbe used to address a variety of business goals aimed at improving efficiency and reducing costs.This type of environment is useful because you can create and manage virtual machines, whichallows you to run multiple operating systems on one physical computer and isolate the operatingsystems from each other.Who will be interested in this feature?The Hyper-V role is used by IT professionals who need to create a virtualized server computingenvironment.
What new functionality does Hyper-V provide?Improvements to Hyper-V include new live migration functionality.Live migrationLive migration allows you to transparently move running virtual machines from one node of thefailover cluster to another node in the same cluster without a dropped network connection orperceived downtime. Live migration requires the failover clustering role to be added andconfigured on the servers running Hyper-V. In addition, failover clustering requires sharedstorage for the cluster nodes. This can include an iSCSI or Fiber-Channel Storage Area Network(SAN). All virtual machines are stored in the shared storage area, and the running virtualmachine state is managed by one of the nodes.On a given server running Hyper-V, only one live migration (to or from the server) can be inprogress at a given time. This means that you cannot use live migration to move multiple virtualmachines simultaneously.We recommend using the new Cluster Shared Volumes (CSV) feature of Failover Clustering inWindows Server 2008 R2 with live migration. CSV provides increased reliability when usedwith live migration and virtual machines, and also provides a single, consistent file namespace sothat all servers running Windows Server 2008 R2 see the same storage.Why is this change important?Live migration does the following to facilitate greater flexibility and value: Provides better agility. Datacenters with multiple servers running Hyper-V can move running virtual machines to the best physical computer for performance, scaling, or optimal consolidation without affecting users. Reduces costs. Datacenters with multiple servers running Hyper-V can service their servers without causing virtual machine downtime or the need to schedule a maintenance window. Datacenters will also be able to reduce power consumption by dynamically increasing consolidation ratios and turning off unused servers during times of lower demand. Increases productivity. It is possible to keep virtual machines online, even during maintenance, which increases productivity for both users and server administrators.Are there any dependencies?
Live migration requires the failover clustering role to be added and configured on the serversrunning Hyper-V.What existing functionality is changing?The following list briefly summarizes the improvements to existing functionality in Hyper-V: Dynamic virtual machine storage. Improvements to virtual machine storage include support for hot plug-in and hot removal of the storage on a SCSI controller of the virtual machine. By supporting the addition or removal of virtual hard disks and physical disks while a virtual machine is running, it is possible to quickly reconfigure virtual machines to meet changing requirements. Hot plug-in and removal of storage requires the installation of Hyper-V integration services (included in Windows Server 2008 R2) on the guest operating system. Enhanced processor support. You can now have up to 64 physical processor cores. The increased processor support makes it possible to run even more demanding workloads on a single host. In addition, there is support for Second-Level Address Translation (SLAT) and CPU Core Parking. CPU Core Parking enables Windows and Hyper-V to consolidate processing onto the fewest number of possible processor cores, and suspends inactive processor cores. SLAT adds a second level of paging below the architectural x86/x64 paging tables in x86/x64 processors. It provides an indirection layer from virtual machine memory access to the physical memory access. In virtualization scenarios, hardware-based SLAT support improves performance. On Intel-based processors, this is called Extended Page Tables (EPT), and on AMD- based processors, it is called Rapid Virtualization Indexing (RVI), and was previously called nested paging tables (NPT). Enhanced networking support. Support for jumbo frames, which was previously available in nonvirtual environments, has been extended to be available on virtual machines. This feature enables virtual machines to use jumbo frames up to 9,014 bytes in size, if the underlying physical network supports it.Which editions include this role?This role is available in all editions of Windows Server 2008 R2, except for WindowsServer® 2008 R2 for Itanium-Based Systems and Windows® Web Server 2008 R2.Whats New in Failover Clusters4 out of 7 rated this helpful - Rate this topicUpdated: February 10, 2009Applies To: Windows Server 2008 R2
What are the major changes?In Windows Server® 2008 R2 Enterprise and Windows Server® 2008 R2 Datacenter, thechanges in failover clusters include the following: Improvements to the validation process for a new or existing cluster. Improvements in functionality for clustered virtual machines (which run with the Hyper-V feature). These improvements help to increase the uptime and simplify the management of clustered virtual machines. The addition of a Windows PowerShell interface. Additional options for migrating settings from one cluster to another.NoteThe failover cluster feature is not available in Windows® Web Server 2008 R2 or WindowsServer® 2008 R2 Standard.The sections that follow provide more detail about these changes.What does a failover cluster do?A failover cluster is a group of independent computers that work together to increase theavailability of applications and services. The clustered servers (called nodes) are connected byphysical cables and by software. If one of the cluster nodes fails, another node begins to provideservice (a process known as failover). Users experience a minimum of disruptions in service.Who will be interested in failover clustering?Failover clusters are used by IT professionals who need to provide high availability for servicesor applications.Are there any special considerations?Microsoft supports a failover cluster solution only if all the hardware components are marked as"Certified for Windows Server 2008 R2." In addition, the complete configuration (servers,
network, and storage) must pass all tests in the Validate a Configuration wizard, which isincluded in the Failover Cluster Manager snap-in.Note that this policy differs from the support policy for server clusters in Windows Server 2003,which required the entire cluster solution to be listed in the Windows Server Catalog underCluster Solutions.What new functionality does failover clustering provide? Windows PowerShell cmdlets for failover clusters. Windows PowerShell is a new command-line shell and scripting technology that uses consistent syntax and naming patterns across the roles and features in Windows Server 2008 R2. The new cmdlets for failover clusters provide powerful ways to script cluster configuration and management tasks. Windows PowerShell cmdlets will eventually replace the Cluster.exe command-line interface. If you use the Server Core installation option of Windows Server 2008 R2 for your failover cluster, the Windows PowerShell cmdlets for failover clusters simplify the local management of the cluster. Read-only permissions option. You can assign read-only permission to a user or group who might need to see the cluster but not change the configuration of the cluster. Cluster Shared Volumes. With Cluster Shared Volumes, the configuration of clustered virtual machines (supported by the Hyper-V feature) is much simpler than before. With Cluster Shared Volumes: o You can reduce the number of LUNs (disks) required for your virtual machines, instead of having to manage one LUN per virtual machine. (Previously, the recommended configuration was one LUN per virtual machine, because the LUN was the unit of failover.) Many virtual machines can use a single LUN and can fail over without causing the other virtual machines on the same LUN to also fail over. o You can make better use of disk space, because you do not need to place each Virtual Hard Disk (VHD) file on a separate disk with extra free space set aside just for that VHD file. Instead, the free space on a Cluster Shared Volume can be used by any VHD file on that LUN. o You can more easily track the paths to VHD files and other files used by virtual machines. You can specify the path names, instead of identifying disks by drive letters (limited to the number of letters in the alphabet) or identifiers called GUIDs (which are hard to use and remember). With Cluster Shared Volumes, the path appears to be on the system drive of the node, under the ClusterStorage folder. However, this path is the same when viewed from any node in the cluster. o If you use a few Cluster Shared Volumes to create a configuration that supports many clustered virtual machines, you can perform validation more quickly than you could with
a configuration that uses many LUNs to support many clustered virtual machines. With fewer LUNs, validation runs more quickly. (You perform validation by running the Validate a Configuration Wizard in the snap-in for failover clusters.) o There are no special hardware requirements beyond what is already required for storage in a failover cluster (although Cluster Shared Volumes require NTFS). o Resiliency is increased, because the cluster can respond correctly even if connectivity between one node and the SAN is interrupted, or part of a network is down. The cluster will re-route the Cluster Shared Volumes traffic through an intact part of the SAN or network.What existing functionality is changing?The following list briefly summarizes the improvements in failover clusters: Additional tests in cluster validation. With the additional tests built into the Cluster Validation Wizard in the failover cluster snap-in, you can fine-tune your cluster configuration, track the configuration, and identify potential cluster configuration issues before they cause downtime. Support for additional clustered services. In addition to the services and applications you could previously configure in a cluster, you can now cluster Distributed File System (DFS) Replication member servers and a Remote Desktop Connection Broker (formerly Terminal Services Session Broker). Additional options for migrating settings from one cluster to another. The Migration Wizard built into the failover cluster snap-in can migrate settings from clusters running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, not just from clusters running Windows Server 2003 as was previously the case. The wizard can also migrate the settings for additional types of resources and resource groups. Options for moving a virtual machine to another node with little or no interruption for clients. Windows Server 2008 R2 includes live migration, an option for moving a virtual machine to another node in a way that usually leaves the clients connected to the virtual machine. It also includes quick migration and moving of virtual machines, which are options similar to what was available in clusters running Windows Server 2008.Additional tests in cluster validationThe cluster validation wizard previously included tests that helped you test a set of servers, theirnetworks, and the attached storage before you brought them together in a cluster. The tests werealso useful for re-testing a cluster after you made a change, for example, a change to the storageconfiguration. These tests continue to be available, with an additional set of tests. The new testsare called the Cluster Configuration tests, and they help you to check settings that are specifiedwithin the cluster, such as the settings that affect how the cluster communicates across theavailable networks. These tests analyze your current configuration down to the private properties
of clustered resources to see if best practices are employed. You can also use the ClusterConfiguration tests to review and archive the configurations of your clustered services andapplications (including settings for the resources within each clustered service or application).With these tests, you can fine-tune your cluster configuration, track the configuration, andidentify potential cluster configuration issues before they cause downtime. This can help youoptimize your configuration and compare it against the best practices that you have identified foryour organization.Support for additional clustered servicesIn addition to the services and applications you could previously configure in a failover cluster,you can now configure the following: Remote Desktop Connection Broker (formerly Terminal Services Session Broker): Remote Desktop Connection Broker supports session load balancing and session reconnection in a load- balanced remote desktop server farm. RD Connection Broker is also used to provide users access to RemoteApp programs and virtual desktops through RemoteApp and Desktop Connection. DFS Replication: DFS Replication is an efficient, multiple-master replication engine that you can use to keep folders synchronized between servers across limited bandwidth network connections. You can cluster any member server in the replication group.Additional options for migrating settings from one cluster to anotherThe Migration Wizard built into the failover cluster snap-in can migrate settings from clustersrunning Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, not justfrom a cluster running Windows Server 2003 as was previously the case. As before, the wizardcan migrate settings from the following resource groups: File server Dynamic Host Configuration Protocol (DHCP) Generic Application Generic Script Generic Service WINS ServerIn Windows Server 2008 R2, the Migration Wizard can also migrate settings from the followingresource groups:
Distributed File System Namespace (DFS-N) Distributed Transaction Coordinator (DTC) Internet Storage Name Service (iSNS) Server Message Queuing (also called MSMQ) Network File System (NFS) Other Server (client access point and storage only) Remote Desktop Connection BrokerNote that other migration processes exist for additional clustered servers, such as clustered printservers.Options for moving a virtual machine to another node with little or no interruption for clientsFailover clusters in Windows Server 2008 R2 provide multiple ways to move a virtual machinefrom one cluster node to another: Live migration: When you initiate live migration, the cluster copies the memory being used by the virtual machine from the current node to another node, so that when the transition to the other node actually takes place, the memory and state information is already in place for the virtual machine. The transition is usually fast enough that a client using the virtual machine does not lose the network connection. If you are using Cluster Shared Volumes, live migration is almost instantaneous, because no transfer of disk ownership is needed. A live migration can be used for planned maintenance but not for an unplanned failover. On a given server running Hyper-V, only one live migration (to or from the server) can be in progress at a given time. For example, if you have a four-node cluster, up to two live migrations can occur simultaneously if each live migration involves different nodes. Quick migration: When you initiate quick migration, the cluster copies the memory being used by the virtual machine to a disk in storage, so that when the transition to another node actually takes place, the memory and state information needed by the virtual machine can quickly be read from the disk by the node that is taking over ownership. A quick migration can be used for planned maintenance but not for an unplanned failover. You can use quick migration to move multiple virtual machines simultaneously. Moving: When you initiate a move, the cluster prepares to take the virtual machine offline by performing an action that you have specified in the cluster configuration for the virtual machine resource:
o Save (the default) saves the state of the virtual machine, so that the state can be restored when bringing the virtual machine back online. o Shut down performs an orderly shutdown of the operating system (waiting for all processes to close) on the virtual machine before taking the virtual machine offline. o Shut down (forced) shuts down the operating system on the virtual machine without waiting for slower processes to finish, and then takes the virtual machine offline. o Turn off is like turning off the power to the virtual machine, which means that data loss may occur. The setting that you specify for the offline action does not affect live migration, quick migration, or unplanned failover. It affects only moving (or taking the resource offline through the action of Windows PowerShell or an application).Do I need to change any existing code or scripts to work with Windows Server 2008 R2?If an application or service ran on a cluster with Windows Server 2008, you do not need tochange the code to run the application or service on a cluster with Windows Server 2008 R2. Ifyou have scripts based on Cluster.exe, you can continue to use them in WindowsServer 2008 R2, but we recommend that you rewrite them with Windows PowerShell cmdlets. Infuture releases, Windows PowerShell will be the only command-line interface available forfailover clusters.How should I prepare to deploy this feature?Carefully review the hardware on which you plan to deploy a failover cluster to ensure that it iscompatible with Windows Server 2008 R2. This is especially necessary if you are currentlyusing that hardware for a server cluster running Windows Server 2003. Hardware that supports aserver cluster running Windows Server 2003 may not necessarily support a failover clusterrunning Windows Server 2008 R2. For more information, see Are there any specialconsiderations?, earlier in this topic.NoteYou cannot perform a rolling upgrade from a cluster running Windows Server 2003 or WindowsServer 2008 to a cluster running Windows Server 2008 R2. However, after you create a failover clusterrunning Windows Server 2008 R2, you can use a wizard to migrate certain resource settings to it from anexisting cluster.
If you are planning to use Cluster Shared Volumes, set up the operating system of each server inyour cluster so that it boots from the same drive letter as all other servers in the cluster. In otherwords, if one server boots from drive letter C, all servers in the cluster should boot from driveletter C.Which editions include failover clustering?The failover cluster feature is available in Windows Server 2008 R2 Enterprise and WindowsServer 2008 R2 Datacenter. The feature is not available in Windows Web Server 2008 R2 orWindows Server 2008 R2 Standard.