Thursday, July 31, 2014

Changes in Functionality from Windows Server 2008 to Windows Server 2008 R2

The Windows Server® 2008 R2 operating system includes changes to Windows Server® 2008 features and technologies that help improve the security of computers running Windows Server 2008 R2, increase productivity, and reduce administrative overhead. The following topics describe some of these features and technologies.
For a downloadable version of this document, see Changes in Functionality in Windows Server 2008 R2 in the Microsoft Download Center.

Wednesday, July 30, 2014

File Services

Topics collected here are installed with server roles, services, and technologies associated with File Services in Windows Server 2008 R2.
The following topics provide information about using File Services snap-ins.

Overview of Advanced Group Policy Management

Abstract
By providing change control, offline editing, and role-based delegation, Microsoft® Advanced Group Policy Management (AGPM) can help you better manage Group Policy objects (GPOs) in your environment. AGPM is a key component of the Microsoft Desktop Optimization Pack (MDOP). AGPM 4.0 introduces support for searching, cross-forest management, and the latest Windows® operating systems. This white paper offers an overview of AGPM: its benefits, how it works, and how to evaluate it.

Contents

Imagine a tool that could help you take control of Group Policy. What would this tool do? It could help you delegate who can review, edit, approve, and deploy Group Policy objects (GPOs). It might help prevent widespread failures that can result from editing GPOs in production environments. You could use it to track each version of each GPO, just as developers use version control to track source code. Any tool that provided these capabilities, cost little, and was easy to deploy would certainly be worth a closer look.
Such a tool indeed exists, and it is an integral part of the Microsoft® Desktop Optimization Pack (MDOP) for Software Assurance. MDOP can help organizations reduce the cost of deploying applications, deliver applications as services, and better manage desktop configurations. Together, the MDOP applications shown in Figure 1 can give Software Assurance customers a highly cost-effective and flexible solution for managing desktop computers.
Figure 1. MDOP applications
Microsoft Advanced Group Policy Management (AGPM) is the MDOP application that can help customers overcome the challenges that can affect Group Policy management in any organization, particularly those with complex information technology (IT) environments. A robust delegation model, role-based administration, and change-request approval provide granular administrative control. For example, you can delegate Reviewer, Editor, and Approver roles to other users—even users who do not typically have access to production GPOs. (Editors can edit GPOs but cannot deploy them; Approvers can deploy GPO changes.)
AGPM can also help reduce the risk of widespread failures. You can use AGPM to edit GPOs offline, outside of the production environment, and then audit changes and easily find differences between GPO versions. In addition, AGPM supports effective change control by providing version tracking, history capture, and quick rollback of deployed GPO changes. It even supports a management workflow by allowing you to create GPO template libraries and send GPO change e-mail notifications.
This white paper describes the key features of AGPM, such as change control and role-based delegation. The paper then describes how Software Assurance customers can begin evaluating AGPM today.
The AGPM archive provides offline storage for GPOs. As Figure 2 shows, changes that you make to GPOs in the archive do not affect the production environment until you deploy the GPOs. By limiting changes to the archive, you can edit GPOs and test them in a safe environment, without affecting the production environment. After reviewing and approving the changes, you can then deploy them with the knowledge that you can quickly roll them back if they have an undesired effect.
Figure 2. Offline editing
AGPM has a server component (the AGPM Service) and a client component (the AGPM snap-in), each of which you install separately. First, you install Microsoft Advanced Group Policy Management - Server on a system that has access to the policies that you want to manage. Then, you install the Microsoft Advanced Group Policy Management - Client on any system from which Group Policy administrators will review, edit, and deploy GPOs.
The AGPM snap-in integrates completely with the Group Policy Management Console (GPMC), as Figure 3 shows. Click Change Control in the console tree to open AGPM in the details pane and to manage the AGPM archive on the Contents tab. Here, you can review, edit, and deploy controlled GPOs (that is, GPOs in the archive). You can also take control of uncontrolled GPOs (that is, GPOs that are not in the archive), approve pending changes, and manage GPO templates. On the Domain Delegation tab, AGPM Administrators (Full Control) delegate roles to AGPM users and configure e-mail notifications. Configure the AGPM Server connection on the AGPM Server tab. AGPM 3.0 introduced the Production Delegation tab, which AGPM Administrators can use to delegate permission to edit GPOs in the production environment.
Figure 3. AGPM integration with the GPMC
AGPM provides advanced change control features that can help you manage the lifecycle of GPOs. Many of the AGPM change control concepts will be familiar to administrators who have experience using common version-control tools, such as the version control feature in Microsoft Office SharePoint® Server 2007. The following steps are necessary to change and deploy a GPO:
1.      Check out the GPO from the archive.
2.      Edit the GPO as necessary.
3.      Check in the GPO to the archive.
4.      Deploy the GPO to production.
Change control means more than locking a GPO to prevent multiple users from changing it at the same time. AGPM keeps a history of changes for each GPO, as shown in Figure 4. You can deploy any version of a GPO to production, so you can quickly roll back a GPO to an earlier version if necessary. AGPM can also compare different versions of a GPO, showing added, changed, or deleted settings. Therefore, you can easily review changes before approving and deploying them to the production environment. In addition, a complete history of each GPO enables you to audit not only changes but also all activities related to that GPO.
Figure 4. GPO history
Group Policy already provides a rich delegation model that allows you to delegate administration to regional and task-oriented administrators. However, Group Policy also lets administrators approve their own changes. In contrast, AGPM provides a role-based delegation model that adds a review and approval step to the workflow, as shown in Figure 5.
Figure 5. Role-based delegation
An AGPM Administrator has full control of the AGPM archive. In addition to the AGPM Administrator role, AGPM defines three special roles to support its delegation model:
·        Reviewer. Reviewers can view and compare GPOs. They cannot edit or deploy GPOs.
·        Editor. Editors can view and compare GPOs. They can also check out GPOs from the archive, edit GPOs, and check in GPOs to the archive. Editors can request deployment of a GPO.
·        Approver. Approvers can approve the creation and deployment of GPOs. (When Approvers create or deploy a GPO, approval is automatic.)
As an AGPM Administrator, you can delegate these roles to users and groups for all controlled GPOs within the domain (domain delegation). For example, you can delegate the Reviewer role to users, allowing them to review any controlled GPO in the domain. You can also delegate these roles to users for individual controlled GPOs. Rather than allow users to edit any controlled GPO in the domain, for example, you can give them permission to edit a specific controlled GPO by delegating the Editor role for that GPO only.
AGPM 4.0 introduces the ability to filter the list of GPOs that it displays. For example, you can filter the list by name, status, or comment. You can even filter the list to show GPOs that were changed by a particular user or on a specific date. AGPM displays partial matches, and searches are not case sensitive.
AGPM supports complex search strings using the format column: string, where column is the name of the column by which to search and string is the string to match. For example, to display GPOs that were checked in by Jerry, type state: “checked in” changed by: Jerry in the Search box. Figure 6 shows another example. You can also filter the list by GPO attributes by using the format attribute: string, where attribute is the name of the GPO attribute to match. To display all GPOs that use the Windows® Management Instrumentation (WMI) filter called MyWMIFilter, type wmi filter: mywmifilter in the Search box.
Figure 6. Search example
When searching for GPOs, you can use special terms to search by date, dynamically. These special terms are the same terms that you can use when using Windows Explorer to search for files. For example, you can filter the list to display GPOs that were changed today, yesterday, this week, last week, and so on.
In addition to filtering, AGPM 4.0 also introduces cross-forest management. You can use the following process to copy a controlled GPO from a domain in one forest to a domain in a second forest:
1.      Export the GPO from a domain in the first forest to a CAB file, by using AGPM (Figure 7).
Figure 7. GPO export
2.      On a computer in a domain in the first forest, copy the CAB file to a portable storage device.
3.      Insert the portable storage device into a computer in a domain in the second forest.
4.      Import the GPO into the archive in a domain in the second forest, by using AGPM.
When you import the GPO into the second forest, you can import it as a new controlled GPO. You can also import it to replace the settings of an existing GPO that is checked out of the archive.
The obvious benefit of cross-forest management is testing. Combined with offline editing and change control, cross-forest management enables you to test GPOs in a controlled test environment (the first forest). After verifying the GPO, you can move it into the production environment (the second forest).
Three versions of AGPM are available: AGPM 2.5, AGPM 3.0, and AGPM 4.0. Each is incompatible with the others and supports different Windows operating systems. For more information about choosing the right version of AGPM for your environment and about the Windows operating systems that each supports, see Choosing Which Version of AGPM to Install.
AGPM 4.0 introduces support for Windows 7 and Windows Server® 2008 R2. Additionally, AGPM 4.0 still supports Windows Vista® with Service Pack 1 (SP1) and Windows Server 2008. Table 1 describes limitations in mixed environments that include newer and older Windows operating systems.
Table 1. Limitations in Mixed Environments
If the AGPM Server 4.0 runs on:
And the AGPM Client 4.0 runs on:
AGPM 4.0 is:
Windows Server 2008 R2 or Windows 7
Windows Server 2008 R2 or Windows 7
Supported
Windows Server 2008 R2 or Windows 7
Windows Server 2008 or
Windows Vista with SP1
Supported, but cannot edit policy settings or preference items that exist only in Windows Server 2008 R2 or Windows 7
Windows Server 2008 or
Windows Vista with SP1
Windows Server 2008 R2 or Windows 7
Unsupported
Windows Server 2008 or
Windows Vista with SP1
Windows Server 2008 or
Windows Vista with SP1
Supported, but cannot report or edit policy settings or preference items that exist only in Windows Server 2008 R2 or Windows 7
Forsyth County covers the Winston-Salem, North Carolina, metropolitan area. The county’s population of nearly 325,000 is located in a 410-square-mile area. The county’s IT department supports approximately 1,400 users and 1,650 desktop computers.
Forsyth County needed a solution for managing desktop computers—a solution that did not compromise server security, helped the County nimbly update desktop computer configurations, and provided a rich history of changes. Michael Wilcox, MIS client services supervisor, said, “I attended a seminar on Group Policy and learned about Microsoft Advanced Group Policy Management. I was impressed with how it could enhance the delegation capabilities for administrators.” Forsyth County went on to implement AGPM.
After deploying AGPM, Forsyth County immediately began realizing benefits. “It’s amazing. Managing our desktop configurations is so much easier. We’d be floundering without it,” Wilcox said. Using AGPM, the county can easily and safely build GPOs. It can create and change GPOs without affecting the production environment. Importantly, administrators at Forsyth County don’t need to manually document their changes, because AGPM keeps a rich history of such changes. According to Wilcox, “Advanced Group Policy Management has been like a magic bullet for us. Its automated change management and workflow-enabled delegation capabilities are impressive. I wouldn’t be able to manage GPOs without it.”
AGPM is an add-on license available only to Software Assurance customers. Begin your evaluation today:
·        Download and evaluate AGPM as part of MDOP
MDOP is available to Volume Licensing customers, Microsoft Development Network (MSDN®) subscribers, and Microsoft TechNet subscribers. The evaluation includes a step-by-step guide that walks you through most AGPM capabilities.
·        See Microsoft Desktop Optimization Pack on Microsoft.com
To learn how AGPM and MDOP for Software Assurance can help you better manage GPOs, see http://go.microsoft.com/fwlink/?LinkId=160297.
·        See Microsoft Desktop Optimization Pack on TechNet

For technical information about AGPM and MDOP for Software Assurance, see http://www.microsoft.com/technet/mdop on TechNet.

Overview of Windows System Resource Manager

Applies To: Windows Server 2008 R2
With Windows System Resource Manager for the Windows Server® 2008 R2 operating system, you can manage server processor and memory usage with standard or custom resource policies. Managing your resources can help ensure that all the services provided by a single server are available on an equal basis or that your resources will always be available to high-priority applications, services, or users.
Windows System Resource Manager only manages processor resources when the combined processor load is greater than 70 percent. This means that it does not actively limit the resources that can be used by each consumer when processor load is low. When there is contention for processor resources, resource allocation policies help ensure minimum resource availability based on the management profile that you define.

Features of Windows System Resource Manager

You can use Windows System Resource Manager to:
  • Manage system resources (processor and memory) with preconfigured policies, or create custom policies that allocate resources per process, per user, per Remote Desktop Services session, or per Internet Information Services (IIS) application pool.
  • Use calendar rules to apply different policies at different times without manual intervention or reconfiguration.
  • Automatically select resource policies that are based on server properties and events (such as cluster events or conditions) or changes to installed physical memory or number of processors.
  • Collect resource usage data locally or in a custom SQL database. Resource usage data from multiple servers can be consolidated on a single computer running Windows System Resource Manager.
  • Create a computer group to help organize Remote Desktop Session Host (RD Session Host) servers that you want to manage. Policies can easily be exported or modified for an entire computer group.

Benefits of resource management

Because Windows Server 2008 R2 is designed to give as many resources as possible to non-operating system tasks, a server running a single role usually does not require resource management. However, when multiple applications and services are installed on a single server, they are not aware of competing processes. An unmanaged application or service will typically use all available resources to complete a task. Thus, it is important to use a tool such as Windows System Resource Manager to manage system resources on multipurpose servers. Using Windows System Resource Manager provides two key benefits:
  • More services can run on a single server because service availability can be improved through dynamically managed resources.
  • High-priority users or system administrators can access the system even during times of maximum resource load.

Methods of resource management

Windows System Resource Manager includes five built-in resource management policies that you can use to quickly implement management. In addition, you can create custom resource management policies to meet your specific needs.

Built-in resource management policies

You can enable built-in resource management policies by selecting the type of policy to use. No further configuration is required.

 

Policy Description
Equal per process
When the Equal_Per_Process resource allocation policy is managing the system, each running process is given equal treatment. For example, if a server that is running ten processes reaches 70 percent processor utilization, Windows System Resource Manager will limit each process to using 10 percent of the processor resources while they are in contention. Note that resources not used by low utilization processes will be allocated to other processes.
Equal per user
When the Equal_Per_User resource allocation policy is managing the system, processes are grouped according to the user account that is running them, and each of these process groups is given equal treatment. For example, if four users are running processes on the server, each user will be allocated 25 percent of the system resources to complete those processes. A user running a single application is allocated the same resources as a user running several applications. This policy is especially useful for application servers.
Equal per session
When the Equal_Per_Session resource allocation policy is managing the system, resources are allocated on an equal basis for each session connected to the system. This policy is for use with RD Session Host servers.
Equal per IIS application pool
When the Equal_Per_IISAppPool resource allocation policy is managing the system, each running IIS application pool is given equal treatment, and applications that are not in an IIS application pool can only use resources that are not being consumed by IIS application pools.
Weighted Remote Sessions
When the Weighted_Remote_Sessions resource allocation policy is managing the system, the processes are grouped according to the priority assigned with the user account. For example, if three users are remotely connected, the user assigned Premium priority will receive highest priority access to the CPU, the user assigned Standard priority will receive second priority to the CPU, and the user assigned Basic priority will receive lowest priority to the CPU. This policy is for use with RD Session Host servers.
noteNote
When Weighted_Remote_Sessions is set as the managing policy, system management is delegated to the Windows Server 2008 R2 scheduler, and Windows System Resource Manager only profiles the system. Setting or removing Weighted_Remote_Sessions as the managing policy requires a restart of the computer imposed by the kernel.

Custom resource management

You can use custom resource management methods to identify resource users and allocate resources to them based on your own criteria.

 

Feature Description
Process matching criteria
Enable you to select services or applications to be managed by resource allocation policy rules. You can choose by file name or command, or you can specify users or groups. For example, you could create a process matching criterion that applies management to the application iexplore.exe when it is run by the user Administrator.
Resource allocation policies
Allocate processor and memory resources to processes that are specified by the process matching criteria that you create.
Exclusion lists
Exclude applications, services, users, or groups from management by Windows System Resource Manager.
noteNote
You can also use command-line path matching in a resource allocation policy to exclude an application from management by only that policy.

Scheduling
Use a calendar interface to control one-time events or recurring changes to resource allocation. Different resource allocation policies can be active at different times of day, on different days of the week, or according to other scheduling paradigms.
Conditional policy application
Automatically switch resource allocation policies in response to certain system events (such as installing new memory or additional processors, starting or stopping a node, or changing the availability of a resource group in a cluster).

Additional references

Backing Up BitLocker and TPM Recovery Information to AD DS

Applies To: Windows 7, Windows Server 2008 R2
You can configure BitLocker Drive Encryption to back up recovery information for BitLocker-protected drives and the Trusted Platform Module (TPM) to Active Directory Domain Services (AD DS). Recovery information includes the recovery password for each BitLocker-protected drive, the TPM owner password, and the information required to identify which computers and drives the recovery information applies to. Optionally, you can also save a package containing the actual keys used to encrypt the data as well as the recovery password required to access those keys.

Using AD DS to store BitLocker recovery information

Backing up recovery passwords for a BitLocker-protected drive allows administrators to recover the drive if it is locked. This ensures that encrypted data belonging to the enterprise can always be accessed by authorized users.
Backing up the TPM owner information for a computer allows administrators to locally and remotely configure the TPM security hardware on that computer. As an example, an administrator might want to reset the TPM to factory defaults when decommissioning or repurposing computers.
In a default BitLocker installation, recovery information is not backed up and local users must be responsible for keeping a copy of the recovery password or recovery key. If the user loses that information or neglects to decrypt the drive before leaving the organization, the administrator cannot easily get access to the drive. To mitigate this situation, administrators can configure Group Policy settings to enable backup of BitLocker and TPM recovery information. Before configuring these settings, as a domain administrator you must ensure that the Active Directory schema has the necessary storage locations and that access permissions have been granted to perform the backup.
You should also configure AD DS before configuring BitLocker on client computers. If BitLocker is enabled first, recovery information for those computers will not be automatically added to AD DS. If necessary, recovery information can be backed up to AD DS after BitLocker has been enabled by using either the Manage-bde command-line tool or the BitLocker Windows Management Instrumentation (WMI) provider. For more information about the WMI provider, see the MSDN topic BackupRecoveryInformationToActiveDirectory Method of the Win32_EncryptableVolume Class (http://go.microsoft.com/fwlink/?LinkId=167132).
ImportantImportant
You can save recovery information in AD DS if your domain controllers are running Windows Server 2003 with Service Pack 1 (SP1) or Service Pack 2 (SP2), Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2. You cannot save recovery information in AD DS if the domain controller is running a version of Windows Server earlier than Windows Server 2003 with SP1.

If you are running Windows Server 2008 R2 or Windows Server 2008, follow the same process described for Windows Server 2003 with SP1 or later, with one exception: you do not need to update the schema as described later in this document.
ImportantImportant
You should perform the steps described in the following topics in a test or pre-production environment prior to deploying to production environments.

Before you begin

Download and review the following sample scripts, which are used in the following procedures to configure AD DS for backing up BitLocker recovery information:
  • Add-TPMSelfWriteACE.vbs (http://go.microsoft.com/fwlink/?LinkId=167133)

    This script adds the access control entry (ACE) for the TPM to AD DS so that the computer can back up TPM recovery information in AD DS.
  • List-ACEs.vbs (http://go.microsoft.com/fwlink/?LinkId=167134)

    This script lists or removes the ACEs configured on BitLocker and TPM schema objects for the top-level domain so that you can verify that the expected ACEs have been added appropriately or to remove any ACEs related to BitLocker or the TPM if necessary.
  • Get-TPMOwnerInfo.vbs (http://go.microsoft.com/fwlink/?LinkId=167135)

    This script retrieves TPM recovery information from AD DS for a particular computer so that you can verify that only domain administrators (or delegated roles) can read backed up TPM recovery information and verify that the information is being backed up correctly.
  • Get-BitLockerRecoveryInfo.vbs (http://go.microsoft.com/fwlink/?LinkId=167136)

    This script retrieves BitLocker recovery information from AD DS for a particular computer so that you can verify that only domain administrators (or delegated roles) can read backed up BitLocker recovery information and verify that the information is being backed up correctly.
noteNote
If you will use a domain controller running Windows Server 2003 with SP1 or SP2, you will need to apply the schema extension (BitLockerTPMSchemaExtension.ldf) to store BitLocker and TPM passwords in Active Directory. This file can be downloaded from the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information download page.

This topic includes the following sections:

Storing BitLocker recovery information in AD DS

Backed up BitLocker recovery information is stored in a child object of the computer object. That is, the computer object is the container for a BitLocker recovery object.
Each BitLocker recovery object includes the recovery password and other recovery information. More than one BitLocker recovery object can exist under each computer object because multiple recovery passwords can be associated with a BitLocker-protected drive and multiple BitLocker-protected drives can be associated with a computer.
The name of the BitLocker recovery object incorporates a globally unique identifier (GUID) and date and time information, for a fixed length of 63 characters. The form is:

For example:
2005-09-30T17:08:23-08:00{063EA4E1-220C-4293-BA01-4754620A96E7}
The common name (CN) for the BitLocker recovery object is ms-FVE-RecoveryInformation. Each ms-FVE-RecoveryInformation object has the following attributes:
  • ms-FVE-RecoveryPassword

    This attribute contains the 48-digit recovery password used to recover a BitLocker-protected drive. Users enter this password to unlock a drive when BitLocker enters recovery mode.
  • ms-FVE-RecoveryGuid

    This attribute contains the GUID associated with a BitLocker recovery password. When in BitLocker's operating system drive recovery mode and when attempting to recover a data drive from within the operating system, this GUID is displayed to the user so that the correct recovery password can be located to unlock the drive. This GUID is also included in the name of the recovery object.
  • ms-FVE-VolumeGuid

    This attribute contains the GUID associated with a BitLocker-protected drive.

    While the password (stored in ms-FVE-RecoveryGuid) is unique for each recovery password, this drive identifier is unique for each BitLocker-protected drive.
  • ms-FVE-KeyPackage

    This attribute contains a drive's BitLocker encryption key secured by the corresponding recovery password.

    With this key package and the recovery password (stored in ms-FVE-RecoveryPassword), you can decrypt portions of a BitLocker-protected drive if the disk is corrupted. Each key package will work only for a drive that has the corresponding drive identifier (stored in ms-FVE-VolumeGuid). You must use the BitLocker Recovery Password Viewer to make use of this key package. For more information, see BitLocker Recovery Password Viewer for Active Directory.
If you want to verify that your AD DS (or Active Directory) schema has the required attributes to back up TPM and BitLocker recovery information, follow the instructions in Verify BitLocker and TPM Schema Objects.

Storing TPM recovery information in AD DS

There is only one TPM owner password per computer. When the TPM is initialized or when this password is changed, the hash of the TPM ownership password gets backed up as an attribute of the computer object.
The common name (CN) for the TPM attribute is ms-TPM-OwnerInformation.

Configuring AD DS

Complete the following tasks to configure AD DS to back up BitLocker and TPM recovery information.

Check general prerequisites

Ensure that the following prerequisites are met:
  1. All domain controllers accessible by BitLocker-capable client computers are running Windows Server 2003 with SP1 or SP2. On each domain controller, click Start, right-click My Computer, and then click the General tab.

    ImportantImportant
    If the General tab lists Windows Server 2003 but no service pack information, you need to install a service pack to be able to back up BitLocker recovery information to AD DS. For more information, see Windows Server 2003 Service Packs (http://go.microsoft.com/fwlink/?LinkID=43106).
    The BitLocker and TPM schema extension marks selected attributes as "confidential" by using the "searchFlags" property. The "confidential" flag is a feature available in Windows Server 2003 with SP1 and later. With this feature, only domain administrators and appropriate delegates have Read access to attributes marked with the confidential flag.
    BitLocker does not impose any requirements on domain or forest functional levels. However, domain controllers running operating systems earlier than Windows Server 2003 with SP1 should be removed from mixed-functional-level environments (or upgraded), because backed up BitLocker and TPM information will not be protected on those domain controllers.
  2. You have domain administrator privileges in the target forest or are using an account that has been granted appropriate permissions to extend the schema for the target forest. Members of the Schema Admins groups are examples of accounts that have the appropriate permissions.
  3. You have obtained the following files:

    • BitLockerTPMSchemaExtension.ldf if you need to extend the Active Directory schema.
    • Add-TPMSelfWriteACE.vbs to allow the computer account to back up the TPM owner information to AD DS.

Extend the schema (Windows Server 2003 domain controllers only)

The following procedure extends the schema to allow information to be saved in Active Directory.
ImportantImportant
If your domain controller is running Windows Server 2008 or Windows Server 2008 R2, you do not need to complete this procedure. These operating systems already include the necessary schema extensions.

To extend the Active Directory schema with BitLocker and TPM attributes

  1. Log on with a domain account in the Schema Admins group. This account must be used to extend the schema.
    By default, the built-in Administrator account in the forest root domain is part of the Schema Admins group. For more information, see the section "Granting access rights to make schema changes" in How the Active Directory Schema Works (http://go.microsoft.com/fwlink/?LinkID=79649).
  2. Verify that your Windows Server installation enables schema updates.
    In Windows Server 2003, Active Directory schema updates are enabled by default. For more information, including the steps required to enable schema updates, see article 285172 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=79644).
  3. Verify that you have access to the domain controller that is the schema operations master in the Active Directory forest. Schema updates can only be performed at the schema operations master.
  4. Download and review BitLockerTPMSchemaExtension.ldf from the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information download page. (http://go.microsoft.com/fwlink/?LinkID=167137). This file contains the schema extension.
    For reference information about schema extensions, see How the Active Directory Schema Works (http://go.microsoft.com/fwlink/?LinkId=79649).
  5. Use the Ldifde command-line tool to extend the schema on the domain controller that serves as the schema operations master. For example, to import the schema extension on a domain named nttest.microsoft.com, log on as a user in the Schema Admins group, and then type the following at a command prompt:
    ldifde -i -v -f BitLockerTPMSchemaExtension.ldf -c "DC=X" "DC=nttest,dc=microsoft,dc=com" -k -j .
    This command should be entered as one line. The trailing period (.) is part of the command.
    The use of -k suppresses "Object Already Exists" errors if the portions of the schema already exist. The use of -j . saves an extended log file to the current working directory.
For more information about Ldifde parameters, see article 237677 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=79650).

Set the required permissions for backing up TPM password information

The following procedure adds an access control entry (ACE) so that backing up TPM recovery information is possible.
A client computer running Windows 7 can back up BitLocker recovery information under the computer object's default permission. However, a client computer running Windows 7 cannot back up TPM owner information unless this additional ACE is added.
Review the topic Default AD DS Permissions for a Computer Object, in the appendices, to learn about the default AD DS permissions on the computer class object that contains the BitLocker recovery information class and the TPM owner information attribute.

To add an ACE to allow TPM recovery information to be backed up

  1. Download and review Add-TPMSelfWriteACE.vbs (http://go.microsoft.com/fwlink/?LinkId=167133) from the download page.
  2. Modify Add-TPMSelfWriteACE.vbs as appropriate for your environment.
  3. Type the following at a command prompt, and then press ENTER:
    cscript Add-TPMSelfWriteACE.vbs
This script adds a single ACE to the top-level domain object. The ACE is an inheritable permission that allows SELF (the computer itself) to write to the ms-TPM-OwnerInformation attribute for computer objects in the domain.
The sample script provided operates under the following assumptions:
  • You have domain administrator privileges to set permissions for the top-level domain object.
  • Your target domain is the same as the domain for the user account running the script.

    For example, running the script as TESTDOMAIN\admin will extend permissions for TESTDOMAIN. You might need to modify the sample script if you want to set permissions for multiple domains but do not have domain administrator accounts for each of those domains. Find the variable strPathToDomain in the script, and modify it for your target domain. The following is an example:

    "LDAP://DC=testdomain,DC=nttest,DC=microsoft,DC=com"
  • Your domain is configured so that permissions inherit from the top-level domain object to targeted computer objects.

    Permissions will not go into effect if any container in the hierarchy does not allow inherited permissions from the parent. By default, inheritance of permissions is set by AD DS. If you are not sure whether your configuration differs from this default, you can continue with the setup steps to set the permission. You can then verify your configuration as described later in this document, or by clicking the Effective Permissions button while viewing the properties of a computer object, to check that SELF can write the msTPM-OwnerInformation attribute.

Configure Group Policy to enable backup of BitLocker and TPM recovery information in AD DS

These instructions are for configuring the local policy on a client computer running Windows 7. In a production environment, you would likely edit a Group Policy object (GPO) that applies to computers in the domain instead.
For more information about configuring a GPO in a Windows Server 2008 domain, see the Group Policy Planning and Deployment Guide (http://go.microsoft.com/fwlink/?LinkID=147296).
noteNote
We recommend that you keep the default options when you enable each Group Policy setting. Be sure to read the Explain text before making any changes to understand the impact of the different options.

There are two separate procedures in this section: one for configuring the policy setting that is applied to computers running Windows Vista or Windows Server 2008 and the other for configuring the policy setting that is applied computers running Windows 7 or Windows Server 2008 R2.

To enable the local policy settings to back up BitLocker and TPM recovery information to AD DS from computers running Windows Vista or Windows Server 2008

  1. Log on to the computer with an account that has administrative credentials.
  2. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER to open the Local Group Policy Editor.
  3. In the console tree under Computer Configuration\Administrative Templates\Windows Components, click BitLocker Drive Encryption.
  4. In the details pane, double-click Store BitLocker recovery information in Active Directory (Windows Server 2008 and Windows Vista).
  5. Click Enabled, and then configure the following settings as appropriate for your environment:
    • Select Require BitLocker backup to AD DS if you want to prevent users from enabling BitLocker on computers that are not currently able to connect to a domain controller. If this setting is not selected, BitLocker will attempt to store recovery information in AD DS, but if it fails for any reason BitLocker will still be enabled and the recovery information will not be present in AD DS for that drive.
    • In Select BitLocker recovery information to store, select either Recovery passwords and key packages or Recovery passwords only. Key packages are used with the Repair-bde command-line tool to perform specialized recovery when the disk is damaged or corrupted. For more information, see the Repair-bde.exe Parameter Reference.
    • Click OK to apply the policy settings and close the dialog box.
  6. In the console tree under Computer Configuration\Administrative Templates\System, click Trusted Platform Module Services.
  7. In the details pane, double-click Turn on TPM backup to Active Directory Domain Services.
  8. Click Enabled.
  9. The Require TPM back to AD DS check box is selected by default. When this option is selected, the TPM owner password cannot be set or changed unless the computer is connected to the domain and AD DS backup succeeds.

To enable the local policy settings to back up BitLocker and TPM recovery information to AD DS from computers running Windows 7 or Windows Server 2008 R2

  1. Log on to the computer with an account that has administrative credentials.
  2. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER to open the Local Group Policy Editor.
  3. In the console tree under Computer Configuration\Administrative Templates\Windows Components, click BitLocker Drive Encryption.
  4. In the details pane, double-click the drive type subfolder—either Operating System Drive, Fixed Data Drive, or Removable Data Drive—for which you want to store recovery information in AD DS. Each drive type may have recovery information stored. The remainder of this procedure will use Fixed Data Drive as the example, but each drive type follows the same configuration steps and includes the same setting options.
  5. In the details pane, double-click Choose how BitLocker-protected fixed drives can be recovered.
  6. Click Enabled, and then configure the following settings as appropriate for your environment:
    • By default, Save BitLocker recovery information to Active Directory Domain Services is selected.
    • In Select BitLocker recovery information to store, select either Recovery passwords and key packages or Recovery passwords only. Key packages are used with the Repair-bde command-line tool to perform specialized recovery when the disk is damaged or corrupted. For more information, see the Repair-bde.exe Parameter Reference.
    • Select the Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When this setting is selected, a recovery password is automatically generated.
    • Click OK to apply the policy settings and close the dialog box.
  7. In the console tree under Computer Configuration\Administrative Templates\System, click Trusted Platform Module Services.
  8. Double-click Turn on TPM backup to Active Directory Domain Services.
  9. Click Enabled.
  10. The Require TPM back to AD DS check box is selected by default. When this option is selected, the TPM owner password cannot be set or changed unless the computer is connected to the domain and AD DS backup succeeds.

Testing your Active Directory configuration

By joining the Windows 7–based client computers to the domain that you just configured and enabling BitLocker, you can test whether BitLocker and TPM recovery information is backed up to AD DS successfully.
All user interfaces and programming interfaces within BitLocker and TPM Management features will adhere to your configured Group Policy settings. When these settings are enabled, recovery information (such as recovery passwords) will be automatically backed up to AD DS whenever this information is created and changed.
If you select the option to require backup, initializing the TPM or enabling BitLocker through any method is blocked until the backup succeeds. In that case, no one will be allowed to turn on BitLocker or initialize the TPM unless the domain controller is configured correctly, the client computer has network connectivity to the domain controller, and no other errors occur during the backup process.

Testing the backup with Windows 7

You should use a client computer running Windows 7 to test the backup process.
BitLocker recovery information is backed up when you:
  • Create a recovery password during BitLocker setup, using the wizard available through the Control Panel.
  • Create a recovery password after the disk has already been encrypted, using the Manage-bde.exe command-line tool.
TPM recovery information is backed up when you:
  • Set the TPM owner password during TPM initialization.
  • Change the TPM owner password.

Sample test scenario with Windows 7

This sample test scenario illustrates how to verify your Active Directory configuration by using Windows 7. It uses the BitLocker Deployment Sample Scripts that are available to download to assist in the test process.
ImportantImportant
You should perform additional tests as required to verify that everything is working correctly in your environment; do not assume that this scenario will completely test all aspects of your configuration.

Test scenarios can also vary based on your organization's policies. For example, in organizations where users are the Creator Owner of computer objects that they join to the domain, it might be possible for these users to read the TPM owner information for their own computer objects.

To perform the sample test

  1. Log on to a domain controller as a domain administrator.
  2. Copy the sample script files to a location accessible by both the domain controller and the client computers.
  3. Open a Command Prompt window, and change the default location to the location of the sample script files.
  4. At the command prompt, type the following:
    cscript List-ACEs.vbs
    Expected result: Assuming that the default Add-TPMSelfWriteACE.vbs was used and other deprecated ACEs have been removed, there is only one ACE related to BitLocker and the TPM. The following is an example of the output:
    Accessing

    > AceFlags: 10
    > AceType: 5
    > Flags: 3
    > AccessMask: 32
    > ObjectType: {AA4E1A6D-550D-4E05-8C35-4AFCB917A9FE}
    > InheritedObjectType: {BF967A86-0DE6-11D0-A285-00AA003049E2}
    > Trustee: NT AUTHORITY\SELF

    1 ACE(s) found in DC=nttest,DC=microsoft,DC=com related to BitLocker and TPM
  5. Log on as a local administrator (non-domain administrator) to a Windows 7–based client computer that is a member of the domain.
  6. Click Start, type tpm.msc in the Search programs and files box, and then press ENTER.
  7. Click either the Initialize TPM or Change Owner Password link.
  8. Set an owner password, and select the option to back up the information by printing or saving to a file as needed.
    Expected result: The action succeeds without an error message.
  9. Using this same account, open an elevated Command Prompt window, and then change to the folder in which you have saved a copy of the sample scripts provided with this document.
    noteNote
    To open an elevated Command Prompt window, click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  10. At the command prompt, type the following:
    cscript Get-TPMOwnerInfo.vbs
    Expected result: The error "Active Directory: The directory property cannot be found in the cache" appears. No information is displayed because a non-domain administrator should not be able to read the ms-TPM-OwnerInformation attribute.
    noteNote
    If users are the Creator Owner of computer objects that they join to the domain, it might be possible for these users to read the TPM owner information for their own computer objects.

  11. Log on as a domain administrator on the same client computer.
  12. Using this domain administrator account, open an elevated Command Prompt window, and change to the directory in which you have saved a copy of the sample scripts provided with this document.
  13. At the command prompt, type the following:
    cscript Get-TPMOwnerInfo.vbs
    Expected result: A string that is the hash of the password you created earlier is displayed.
    As a domain administrator, you should have Read access to the ms-TPM-OwnerInformation attribute.
  14. At the elevated command prompt, type the following to turn on BitLocker and create a recovery password:
    manage-bde -on C: -RecoveryPassword
    Expected result: The action succeeds without an error message.
  15. After the drive has completed encryption, at the command prompt, type the following to back up the recovery password to AD DS, replacing recoveryGUID with the full recovery key identification GUID of the recovery password you are storing in AD DS:
    manage-bde -protectors -adbackup C: -id { recoveryGUID }
    noteNote
    The full recovery key identification GUID is printed when you print the BitLocker recovery key.

  16. At the command prompt, type the following to read all BitLocker child objects of the client computer's Active Directory object:
    cscript Get-BitLockerRecoveryInfo.vbs
    Expected result: One or more recovery passwords is displayed, including the one created in the previous step.
    A non-domain administrator will not be able to read these passwords.
  17. Delete any created BitLocker recovery child objects by using Active Directory tools such as the Active Directory Users and Computers snap-in. By default, client computers running Windows 7 do not have permissions to delete BitLocker recovery passwords.

Troubleshooting common problems with AD DS backup

The following section discusses some potential problems and their solutions.

Access permission problems

If you are able to read backed up BitLocker and TPM recovery information by using a non–domain administrator account, check that you are running supported installations of Windows Server on all the domain controllers in your network.
ImportantImportant
Domain controllers must be running Windows Server 2003 SP1 or SP2 to support backing up BitLocker and TPM recovery information.

Script errors

You might receive an error message when you run a script. The following sections explain the causes of and solutions for the most frequent script errors.

Get-TPMOwnerInfo.vbs

When running Get-TPMOwnerInfo.vbs, if an error appears stating "Active Directory: The directory property cannot be found in the cache," it means that you are logged on with an account that does not have permission to read the TPM owner information attribute object in AD DS.

General

If an error appears stating "The specified domain either does not exist or could not be contacted," ensure that the computer is joined to the domain and that network connectivity is available.
If an error appears stating "There is no such object on the server," check that any computer specified by name on the command line is currently connected to the network.
If an error is accompanied by the line number in which the error occurred, consult the script source code to assist in troubleshooting the issue.

Thursday, July 24, 2014

Windows Search Service

Applies To: Windows Server 2008 R2
The Windows Search service collects detailed information about the files on your computer and stores this information in an index for use during searches.

Aspects

The following is a list of all aspects that are part of this managed entity:
Name Description
Search Indexer Performance Counter Availability
You can use the Search Indexer performance counters to monitor various aspects of the search and indexing services on your computer.
Windows Search Service Integrity
The Windows Search service indexes information about the contents of your hard disk to facilitate your searches, making them much faster and more accurate.

Related Management Information

Windows Search

Managing Network Boot Programs

Applies To: Windows Server 2008
This topic only applies to the initial release of Windows Server 2008.
A network boot program (NBP) is the first file that is downloaded and executed as part of the network boot process and it controls the beginning of the boot experience (for example, whether or not the user must press F12 to initiate a network boot). NBPs are specific to both the architecture and firmware of the client.

In This Topic

noteNote
For information about avoiding a boot loop, see Automating the Network Boot.

Configuring the Network Boot Program

You specify the default NBP for each architecture on the Boot tab of the server’s properties (right-click the server in the MMC snap-in, and click Properties). You can also override the default NBP on a per-client basis by running WDSUTIL /Set-Device /Device: /BootProgram:. For example, you may want to configure an NBP so that prestaged (or known) clients receive the default NBP (most commonly a NBP that requires users to press F12) and unknown clients receive a NBP that will cause them to perform a network boot automatically (without F12). This configuration is particularly useful in a lab environment where you want to deploy images to new computers, but you do not want existing computers to automatically boot to the network.

List of Network Boot Programs

The following table lists the available NBPs.

 

NBP Description Architecture Firmware
PXEboot.com
(Default) Requires the user to press the F12 key for a network boot to continue.
x86-based and x64-based
BIOS
PXEboot.n12
Does not require the user to press F12 and immediately begins a network boot.
x86-based and x64-based
BIOS
AbortPXE.com
Boots the computer by using the next boot item in the BIOS without waiting for a time-out.
x86-based and x64-based
BIOS
Hdlscom1.com and Hdlscom2.com
Causes computers that do not support firmware console redirection to display "Press space or F12 for network boot," using console redirection to serial port 1 or 2. Users can proceed with the boot process by pressing either key, or they can exit the boot process by not pressing either key.
x86-based and x64-based
BIOS
Hdlscom1.n12 and Hdlscom2.n12
Causes computers that support firmware console redirection will not display the prompt "Press space or F12 for network boot" and the computer will not wait for user input.
x86-based and x64-based
BIOS
Bootmgfw.efi
The equivalent of Bootmgr.exe for EFI-based computers. In EFI (Extensible Firmware Interface), the choice of whether or not to perform a network boot is handled within the EFI shell, and not by the NBP.
x64-based and Itanium-based
EFI
Wdsnbp.com
An NBP developed for Windows Deployment Services that serves the following general purposes:
1. Architecture detection
2. Pending computer scenarios. When the Auto-Add policy is enabled, this NBP is sent to pending computers to pause the network boot and report back the client computer's architecture to the server.
3. Network boot referral cases (including use of Dynamic Host Control Protocol (DHCP) options 66 and 67)
x86-based and x64-based
BIOS

Directing a Client to the Appropriate Network Boot Program

There are two methods that you can use to direct a client computer to the correct NBP:

Configuring Your Router to Forward Broadcasts (recommended)

You can update the routing tables for your networking equipment to make sure that DHCP traffic is directed correctly. For example, you can use the ip helper-address command if you have a Cisco router. When configured correctly, all DHCP broadcasts from the client computer will be directed to a DHCP server and a Windows Deployment Services server. (Note that the requirement is not to rebroadcast the packet onto other network segments, but rather to forward the packet to only the specified recipients.)
If the booting client, the DHCP server, and the Windows Deployment Services server are all located on the same network segment, you should not have to configure your router. The client’s DHCP broadcasts will reach both the DHCP server and the Windows Deployment Services server. However, if either the DHCP server or the Windows Deployment Services server are on a different network segment than the client (or if they are on the same network segment but the network is controlled by a switch or router), Microsoft recommends that you update your router. After the client computer has obtained its IP address, it contacts the Windows Deployment Services server directly (again using DHCP packets) to obtain the name and path of the NBP to be downloaded. The following are the specific changes that you need to make:
  • All DHCP broadcasts by client computers on User Data Protocol (UDP) port 67 should be forwarded directly to both the DHCP server and the Windows Deployment Services server.
  • If the router has a built in firewall, you need to allow traffic through UDP port 4011 (as well as any UDP ports used for TFTP and multicasting as specified on the Network Settings tab of server properties in the Windows Deployment Services MMC snap-in).

Using DHCP Options 60, 66, and 67

Although Microsoft does not recommend this method, you can use the following DHCP options to direct PXE clients to an appropriate NBP to download:
  • Option 60 = client identifier. You should set this to the string PXEClient. Note that this only applies if DHCP is on the same server as Windows Deployment Services.
  • Option 66 = boot server host name
  • Option 67 = boot file name
For instructions on configuring these options, see the "DHCP" section in How to Manage Your Server. Note that using DHCP options 66 and 67 is considered a network boot referral. Therefore, if you choose this method, ensure that your implementation meets the guidelines defined in the Implementing Network Boot Referrals section below.
If you configure these options, client computers will receive an IP address lease, information about the boot server, and information about the NBP directly from the DHCP server. Clients will not contact the Windows Deployment Services server by using DHCP, but they will download the NBP through Trivial File Transfer Protocol (TFTP) on UDP port 4011. Microsoft does not recommend this method for the following reasons:
  • Using DHCP options is not as reliable as configuring a router. In testing, clients have incorrectly parsed the DHCP options that were returned from the DHCP server and as a result, the client received a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name and attempts to download the NBP directly from the DHCP server.
  • If there are multiple Windows Deployment Services servers available to service client requests, specifying a specific server may prevent load-balancing. In contrast, using router forwarding tables you can forward the request to multiple servers.
  • Clients may be directed to a Windows Deployment Services server that is not available. Because the client does not have to contact a Windows Deployment Services server directly to determine the NBP to download, the DHCP server may direct clients to download a NBP that does not exist or to a server that is not currently available.
  • Clients may bypass the Windows Deployment Services server’s answer settings.

Implementing Network Boot Referrals

A network boot referral occurs when a client is directed to download an NBP from a different server than the one it was in communication with through DHCP. This referral may be initiated by either a Windows Deployment Services server or a DHCP server. The following topics are covered in this section:

When to Implement Network Boot Referrals

You might want to consider a network boot referrals in the following scenarios:
  • To direct a client to download a NBP that is located on a different computer or network location. This may be especially helpful when using DHCP options 66 and 67, because the client is typically answered directly by the DHCP server and is redirected to the Windows Deployment Services server.
  • To limit traffic to a server.

  • To support complex network and AD DS topologies. Sometimes the networking and AD DS topology do not line up. This could be because incoming network boot requests are answered over a wide area network (WAN), but you want a local server to provide the boot image.
  • To enable you to keep only one copy of an image and therefore reduce the overhead of keeping multiple images in sync .
Configuring network boot referrals involves two steps. First, you must configure the front-end and back-end servers. A front-end server is the server that will answer the client’s network boot request and direct the client to the correct server. A back-end server is the server that the client will download the NBP from. Second, you will need to prestage clients and direct them to a back-end server. This second step is required only if you are not using DHCP options 66 and 67 to redirect clients. To configure these settings, see How to Manage Your Server.

Requirements

  • If you are not using DHCP options 66 and 67, in order to configure a network boot referral, you must prestage the client and you must run WDSUTIL /Set-Device /Device: /ReferralServer: to specify the server that the client should use.
  • In environments that contain both Remote Installation Services (RIS) and Windows Deployment Services servers, only the Windows Deployment Services servers should act as referral servers. This enables the Windows Deployment Services server to control the referral process, correctly refer clients, and maintain backward compatibility for RIS servers. If a RIS server attempts to refer a client computer to a Windows Deployment Services server, the client computer will receive an incorrect network boot program, which may cause the client to fail to boot.

Referral Examples

Referrals are classified based on the number of jumps the client must make before it downloads and executes an NBP. The following table contains three examples of referrals. Each of these examples supports the referral of x86-based or x64 BIOS-based clients, but does not support the referral of Itanium-based and x64 EFI-based clients. In addition, in each example the NBP on the Windows Deployment Services server must be Wdsnbp.com.

 

Example Details
First order referral from a Windows Deployment Services server
ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server and a response from WDSServer1. ComputerA contacts WDSServer1 directly on port 4011. WDSServer1 refers ComputerA to download \boot\wdsnbp.com from WDSServer2. ComputerA downloads Wdsnbp.com from Server2.
First order referral using DHCP options
ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring the client to download the file \boot\ x86\wdsnbp.com from WDSServer1. The client computer downloads Wdsnbp.com from WDSServer1.
Second order referral using both DHCP options and Windows Deployment Services
ComputerA sends a DHCP broadcast packet and receives an IP address lease from a DHCP server. The lease also contains values for DHCP options 66 and 67, referring ComputerA to download the file \boot\ x86\wdsnbp.com from WDSServer1. ComputerA downloads Wdsnbp.com from WDSServer1. Wdsnbp.com contacts WDSServer1 on port 4011. WDSServer1 refers ComputerA to download the \boot\x86\wdsnbp.com from WDSServer2. ComputerA downloads Wdsnbp.com from WDSServer2.