Using Windows PowerShell with AD RMS... 7 About this guide... 7 In this guide... 7

Transcription

1 Contents Using Windows PowerShell with AD RMS... 7 About this guide... 7 In this guide... 7 Using Windows PowerShell to Deploy AD RMS... 8 Getting started Understanding the AD RMS Deployment Provider Namespace AD RMS Deployment Cmdlets Installing an AD RMS Cluster Creating an AD RMS Cluster Windows PowerShell Drive Setting Properties on Objects in the AD RMS Drive Namespace Setting the configuration database Specifying the Windows Internal Database Specifying a Remote Database Setting the service account Setting the cluster key storage Using a centrally managed cluster key Using a CSP to store the cluster key Setting the cluster Web site Setting the cluster address Setting the SLC name Registering the SCP Running the Install-ADRMS Cmdlet Joining an Existing Cluster Creating an AD RMS Server Windows PowerShell Drive

2 Setting Properties on Objects in the AD RMS Drive Namespace Setting the database server Setting the database name Setting the cluster key password Setting the service account Setting the cluster Web site Running the Install-ADRMS Cmdlet Adding or Removing Federated Identity Support Adding federated identity support Removing federated identity support Upgrading the AD RMS Server Role Removing the AD RMS Server Role Getting started Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Installing Microsoft Federation Gateway Support Adding Microsoft Federation Gateway Support Enrolling with the Microsoft Federation Gateway Configuring AD RMS Cluster Properties Changing the Intranet Licensing URL Adding an Extranet Cluster URL

3 Changing AD RMS Proxy Settings Registering a Service Connection Point Administering Certificates Exporting the Server Licensor Certificate Specifying the Rights Account Certificate Validity Duration Changing the Server Licensor Certificate Name Enabling Exclusion Policies Excluding Users Excluding Applications Excluding Lockboxes Establishing Trust Policies Configuring Federated Identity Support Settings Adding a Trusted User Domain Exporting a Trusted User Domain Adding a Trusted Publishing Domain Exporting a Trusted Publishing Domain Using Windows Live ID to Establish RACs for Users... 66

4 Configuring Microsoft Federation Gateway Support Updating a Microsoft Federation Gateway Support Certificate Granting the AD RMS Service Group Permission to the SSL Certificate Setting the Microsoft Federation Gateway RAC Validity Period Managing the Microsoft Federation Gateway Licensing Filter List Managing the Microsoft Federation Gateway Publishing Filter List Terminating the Federation Relationship Removing Microsoft Federation Gateway Support Managing AD RMS Databases Turning on or Turning off Logging Configuring Accounts Setting up a Super Users Group Resetting the AD RMS Cluster Key Password Changing the AD RMS Service Account Specifying the Administrative Contact Configuring Rights Policy Templates Specifying the Location of Rights Policy Templates... 79

5 Creating a New Rights Policy Template Editing a Rights Policy Template Modifying all settings with a single command Modifying individual settings Viewing a Summary of User Rights for a Rights Policy Template Archiving a Rights Policy Template Deleting a Rights Policy Template Adding a New Language to a Rights Policy Template Restoring a Rights Policy Template Copying a Rights Policy Template Working with Reports Creating a System Health Report Creating a User Request Report Creating a User Request Information Report Creating a Certificate Chain Report Creating a Certificate Information Report Creating a Child Certificate Report Creating an Issuance License Report

6 Exporting Report Definition Language Files Decommissioning AD RMS

7 Using Windows PowerShell with AD RMS Active Directory Rights Management Services (AD RMS) for the Windows Server 2008 R2 operating system is information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized use, both online and offline, and inside and outside of the firewall. In addition to such graphical user interface (GUI) tools as an installation wizard, a server-role page in Server Manager, and the AD RMS snap-in for Microsoft Management Console (MMC), you can use Windows PowerShell cmdlets to install, configure, and administer AD RMS. This guide provides information about using Windows PowerShell cmdlets to perform these tasks with AD RMS. About this guide This guide explains how to use the Windows PowerShell cmdlets that enable you to install, configure, and administer the AD RMS server role on a computer running Windows Server 2008 R2. It introduces the Windows PowerShell modules that implement AD RMS-specific cmdlets, describes the namespace that these cmdlets work in, and also shows how to use general-purpose cmdlets, such as Set-Itemproperty, to manipulate items in these namespaces that represent AD RMS settings. AD RMS cmdlets are implemented by two Windows PowerShell modules: The AD RMS deployment Windows PowerShell module (AdRmsInstall) and the AD RMS administrative Windows PowerShell module (AdRmsAdmin). To access cmdlets implemented by these modules, you must import their corresponding modules. To import the deployment module, at a Windows PowerShell prompt, type Import-Module AdRms. To import the administration module, type Import-Module AdRmsAdmin. You can also import these modules by importing all available Windows PowerShell modules. This document does not provide overview or introductory information about AD RMS or Windows PowerShell. To use this document, you should have enough experience with AD RMS that you can install, configure, and administer it by using GUI tools. You should also have basic experience running Windows PowerShell cmdlets. For general information about AD RMS, see the AD RMS TechCenter( For information about Windows PowerShell, see Scripting with Windows PowerShell( In this guide Using Windows PowerShell to Deploy AD RMS 7

8 Using Windows PowerShell to Deploy AD RMS The Active Directory Rights Management Services (AD RMS) Windows PowerShell deployment module gives you the ability to install and provision the AD RMS server role on a computer running Windows Server 2008 R2, to upgrade a server in an AD RMS cluster following a Windows upgrade, and to remove the AD RMS server role, all by using Windows PowerShell cmdlets. The module presents a drive namespace that consists of containers representing configuration settings you must make before installing the server role. Within this namespace, you manage cluster settings by creating and setting properties on items in the containers that are arranged hierarchically in the namespace, most often by using common Windows PowerShell cmdlets, such as New-Item and Set-ItemProperty. In some cases, the AD RMS Windows PowerShell deployment module implements special-purpose cmdlets to perform tasks that cannot be performed by using common cmdlets. Note To deploy AD RMS by using a Windows PowerShell session on a remote computer, you must enable the Credential Security Service Provider (CredSSP) and then specify - Authentication Credssp when creating the remote session. Note, however, that this practice increases the security risk of the remote operation because, if the remote computer is compromised, the credentials that are passed to it can be used to control the network session. For more information, type Get-Help Enable-WSManCredSSP -Full at a Windows PowerShell prompt. Getting started Before you can deploy AD RMS by using Windows PowerShell cmdlets, after starting Windows PowerShell, you must perform two tasks: 1. Import the AD RMS Windows PowerShell deployment cmdlet module. 2. Create a Windows PowerShell drive that represents the AD RMS cluster you want to create or join. The following procedures explain how to perform each of these tasks. Import the module At the Windows PowerShell prompt, type: Import-Module ADRMS Create the drive At the Windows PowerShell prompt, type: New-PSDrive -Name <drivename> -PsProvider AdRmsInstall -Root <installtype> 8

9 where <drivename> is the name you want to assign to the new drive, and <installtype> is the type of installation you want to perform: RootCluster installs the AD RMS server role as the first server in a root cluster. LicensingCluster installs the AD RMS server role as the first server in a licensingonly cluster. JoinCluster installs the AD RMS server role as a member server in an existing root or licensing-only cluster. For example, to create a drive named RC that represents the first server in a root cluster, type: New-PSDrive -Name RC -PsProvider AdRmsInstall -Root RootCluster Understanding the AD RMS Deployment Provider Namespace AD RMS Deployment Cmdlets Installing an AD RMS Cluster Joining an Existing Cluster Adding or Removing Federated Identity Support Upgrading the AD RMS Server Role Removing the AD RMS Server Role Understanding the AD RMS Deployment Provider Namespace The Active Directory Rights Management Services (AD RMS) Windows PowerShell deployment provider exposes a namespace that represents the various configuration settings that you can make to a server before installing AD RMS. You configure these settings by using Windows PowerShell cmdlets to traverse this namespace and then creating or deleting items in the namespace, or setting properties on those items. The namespace consists of a Windows PowerShell drive, which holds a root container and a number of additional subcontainers, depending on the type of drive representing the role the new server will play in an AD RMS cluster. For information about creating an AD RMS Windows PowerShell deployment provider drive, see Using Windows PowerShell to Deploy AD RMS. This topic lists the containers in the deployment namespace, explains what configuration settings each container represents, and lists the subcontainers or items that it can hold. <drive>:\ The root container of the deployment namespace represents the general properties of the server itself. You can work with these properties by using the Get-ItemProperty and Set-ItemProperty cmdlets to view and change the following properties for drives 9

10 that represent the first server in a cluster: ServiceAccount ClusterURL SLCName RegisterSCP (root cluster only) If <drive> represents a server that is being joined to an existing cluster, only the ServiceAccount property is available. <drive>:\adfssupport This container is not used in this version. Do not change any of the properties of this container. <drive>:\clusterdatabase This container represents the type and location of the cluster database used by the AD RMS cluster being created or joined. If <drive> represents the first server in a root or licensing cluster, use the Set-ItemProperty cmdlet to set the UseWindowsInternalDB, ServerName, and InstanceName properties to specify the location of the cluster database. If <drive> represents a server being joined to an existing cluster, you also set the DatabaseName property. <drive>:\clusterdatabase\databaseinstance This container holds items or containers representing the database instances hosted by the database server specified by the ServerName property of the parent container. If <drive> represents the first server in a cluster, this container holds items whose names are the names of database instances hosted by the server. You can use the name of one of these items to set the InstanceName property of the parent container. If <drive> represents a server that is being joined to an existing cluster, this container holds subcontainers that in turn hold items representing the databases hosted by those instances. <drive>:\clusterdatabase\databaseinstance\<instancename> If <drive> represents the first server in a cluster, this is an item representing an instance hosted by the database server. If <drive> represents a server being joined to an existing cluster, this is a container that holds items representing databases hosted by a database instance on the database server. You can use the name of one of these items to set the DatabaseName property of the \ClusterDatabase container. 10

11 <drive>:\clusterkey This container represents the AD RMS cluster key protection policy and holds a subcontainer that in turn holds subcontainers that represent the available cryptographic service providers (CSPs). If <drive> represents the first server in a cluster, you can use the Set-ItemProperty cmdlet to set the UseCentrallyManaged property of this container. If you set UseCentrallyManaged to TRUE (the default), you must also set the CentrallyManagedPassword property; if you set UseCentrallyManaged to FALSE, you must also set the CreateNewKeyPair property, or the UseExistingKeyPair and CSPName properties. Enumerate the contents of the CSP subcontainer to obtain the names of available CSPs. <drive>:\clusterkey\csp This container holds subcontainers that represent the available CSPs. This container has no properties. <drive>:\clusterkey\csp\<cspname> This container holds items that represent the key containers in the CSP identified by <CSPName>. <drive>:\clusterwebsite This container holds items representing the Web sites that the server hosts. You can use the Set-ItemProperty cmdlet to set the container s WebSiteName property to specify the cluster Web site name. Using Windows PowerShell to Deploy AD RMS AD RMS Deployment Cmdlets Installing an AD RMS Cluster Joining an Existing Cluster Adding or Removing Federated Identity Support Upgrading the AD RMS Server Role Removing the AD RMS Server Role 11

12 AD RMS Deployment Cmdlets The Active Directory Rights Management Services (AD RMS) Windows PowerShell deployment Windows PowerShell module gives you the ability to install, upgrade, or remove an AD RMS cluster by using Windows PowerShell cmdlets. The following describes these cmdlets. Install-ADRMS This cmdlet installs the Active Directory Rights Management Services (AD RMS) server role and, if necessary, any features required by AD RMS. Before running this cmdlet, prepare the server by setting properties on containers in the deployment provider namespace. You can also use this cmdlet to install federated identity support on an existing cluster. Uninstall-ADRMS This cmdlet removes the AD RMS server role. You can also use this cmdlet to remove identity federation support from a cluster. Update-ADRMS This cmdlet upgrades the AD RMS server role following an upgrade of the operating system to Windows Server 2008 R2. You can use the WhatIf parameter to view the actions that would be taken by the cmdlet without changing the system. For complete information about these cmdlets, see AD RMS Cmdlets in Windows PowerShell ( Using Windows PowerShell to Deploy AD RMS Understanding the AD RMS Deployment Provider Namespace Installing an AD RMS Cluster Joining an Existing Cluster Adding or Removing Federated Identity Support Upgrading the AD RMS Server Role Removing the AD RMS Server Role 12

13 Installing an AD RMS Cluster Before you can use Windows PowerShell cmdlets to install the Active Directory Rights Management Services (AD RMS) server role on a computer running Windows Server 2008 R2, you must start Windows PowerShell with administrator privileges after logging in with an account that meets the following requirements: The user account that you use to install AD RMS must not be the same account as the AD RMS service account. If you are registering the AD RMS service connection point (SCP) during installation, the user account that you use to install AD RMS must be a member of the Active Directory Domain Services (AD DS) Enterprise Admins group, or equivalent. If you are using an external database server for the AD RMS databases, the user account that you use to install AD RMS must have the right to create new databases. If Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is used, the user account must be a member of the System Administrators database role, or equivalent. The user account that you use to install AD RMS must have access to query the AD DS domain, such as a domain user account. The user account that you use to install AD RMS must be a member of the Administrators group, or equivalent, on the server. Important You cannot use Windows PowerShell to install AD RMS with a Web site other than the default Web site. If you need to use a different Web site to host AD RMS, you must use Server Manager to install and configure AD RMS. Installing and provisioning the first server in an AD RMS cluster consists of the following steps: 1. Create the Windows PowerShell drive to represent the server you are provisioning. For more information, see Creating an AD RMS Cluster Windows PowerShell Drive. 2. Set properties on objects in the drive namespace that represent required configuration settings. For more information, see Setting Properties on Objects in the AD RMS Drive Namespace. 3. Run the Install-ADRMS cmdlet. In addition to installing the AD RMS server role and provisioning the server, this cmdlet also installs other features required by AD RMS, such as Message Queuing, if necessary. For more information, see Running the Install-ADRMS Cmdlet. Using Windows PowerShell to Deploy AD RMS Understanding the AD RMS Deployment Provider Namespace Pre-installation Information for Active Directory Rights Management Services 13

14 Creating an AD RMS Cluster Windows PowerShell Drive By creating an Active Directory Rights Management Services (AD RMS) deployment Windows PowerShell provider drive, you create a namespace that contains items that represent configuration settings of the server you are installing and provisioning. To create the Windows PowerShell drive At a Windows PowerShell prompt, type: Import-Module ADRMS New-PSDrive -PSProvider ADRMSInstall -Name <drive> -Root <cluster_type> where <drive> is the name of the Windows PowerShell drive you are creating, and <drive_type> is the type of cluster you are installing: RootCluster or LicensingCluster. For example, to create a Windows PowerShell drive named RC to install and provision the first server in an AD RMS root cluster, type: New-PSDrive -PSProvider ADRMSInstall -Name RC -Root RootCluster To create a Windows PowerShell drive named LC to install and provision the first server in an AD RMS licensing-only cluster, type: New-PSDrive -PSProvider ADRMSInstall -Name LC -Root LicensingCluster After creating the drive, do not exit the Windows PowerShell command prompt until you have finished installing the AD RMS server role. Doing so will delete the drive and all property settings will be lost. Installing an AD RMS Cluster Setting Properties on Objects in the AD RMS Drive Namespace Running the Install-ADRMS Cmdlet Setting Properties on Objects in the AD RMS Drive Namespace Setting properties on objects in the drive namespace is similar to using a wizard to specify configuration settings when installing a server role. Before you can finish the installation by running the Install-ADRMS cmdlet, you must provide necessary information about the initial configuration of the server role. The following table lists the required settings and the properties that represent those settings in the drive namespace. 14

15 Setting name Property name Location Configuration database UseWindowsInternalDatabase <drive>:\clusterdatabase Service account ServiceAccount <drive>:\ Cluster key storage UseCentrallyManaged or UseCSP <drive>:\clusterkey Cluster Web site WebSiteName <drive>:\clusterwebsite Cluster address ClusterURL <drive>:\ Server licensor certificate (SLC) name Register service connection point (SCP) SLCName RegisterSCP <drive>:\ <drive>:\ Notes The RegisterSCP property is available only when you are installing a root cluster. Depending on how you set these properties, additional property settings may be required. For example, if you set the UseWindowsInternalDatabase property to False, you must also specify the name of a remote database server and database instance. The following sections describe the configuration settings you must specify by setting properties on objects in the Windows PowerShell drive namespace. Setting the configuration database When installing the AD RMS server role on the first server in a cluster, you must specify the location of the database that will be used to store configuration and other data. You can choose to use the Windows Internal Database on the server, or you can designate a database instance on a remote database server. You must use a separate database server if you intend to add servers to the cluster or to add identity federation support. Specifying the Windows Internal Database By default, the first server in an AD RMS cluster uses the Windows Internal Database as its configuration database. You can use the following command to verify that the drive namespace is configured to use the Windows Internal Database: Get-ItemProperty -Path <drive>:\clusterdatabase -Name UseWindowsInternalDatabase If the UseWindowsInternalDatabase property is set to False, you can use the following procedure to configure the server to use the Windows Internal Database. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. 15

16 To use the Windows Internal Database At the wps command prompt, type: Set-ItemProperty -Path <drive>:\clusterdatabase -Name UseWindowsInternalDatabase - Value $true Specifying a Remote Database You must use a database instance on a remote server if you plan to add servers to the cluster, or if you plan to use identity federation support. If you are using a named instance for the AD RMS configuration database, the SQL Server Browser service must be started on the database server before installing AD RMS. Otherwise, the AD RMS installation will not be able to locate the configuration database and the installation will not succeed. To perform this procedure, you must be logged on with a user account that is a member of the Administrators group of this server and that has the right to create a new database on the remote server. To use a remote database instance At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterdatabase -Name ServerName - Value <db_server> where <drive> is the name of the Windows PowerShell drive and <db_server> is the name of the remote server hosting the database. Unless you specify a named instance, the AD RMS server is configured to use the default database instance hosted by the specified server. If you want to use a named instance, use the following procedure to set the InstanceName property of the \ClusterDatabase container after setting the ServerName property. To use a named database instance 1. To enumerate the database instances hosted by the database server, at the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\clusterdatabase\databaseinstance where <drive> is the name of the Windows PowerShell drive. 2. To specify the database instance to be used by the cluster, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterdatabase -Name InstanceName - Value <db_instance> where <drive> is the name of the Windows PowerShell drive and <db_instance> is the name of the database instance hosted by the remote database server. 16

17 Back to top Setting the service account During installation, AD RMS creates the AD RMS Service Group on the local computer and grants it appropriate permissions on all of the resources that are required for AD RMS to operate. When you install the AD RMS server role, you must define a domain account for use as the AD RMS service account. That account is made a member of the AD RMS Service Group, and it is granted the permissions that are associated with this group. During routine operations, AD RMS runs under the AD RMS service account. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To set the AD RMS service account 1. At the Windows PowerShell command prompt, type: $svcacct = Get-Credential A dialog box appears. 2. In the dialog box, type the account domain and name (in the form <domain>\<account>) and password. 3. At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\ -Name ServiceAccount -Value $svcacct where <drive> is the name of the Windows PowerShell drive. Setting the cluster key storage You can protect the AD RMS cluster key by using a hardware- or software-based cryptographic service provider (CSP) or by storing the cluster key in the AD RMS configuration database. When using AD RMS to centrally manage the cluster key from the AD RMS configuration database, you should use a strong cluster key password. If you are upgrading from RMS to AD RMS and using a hardware-based CSP, ensure that the drivers are compatible with Windows Server 2008 R2 before proceeding with the upgrade. Note If there are multiple servers in the AD RMS cluster, and you are using either a softwareor hardware-based CSP to protect the cluster key, you must manually move the cluster key to the other computers before installing AD RMS. Consult the CSP documentation for procedures on moving the cluster key. 17

18 Using a centrally managed cluster key By default, the first server in an AD RMS cluster uses centrally managed key storage. However, if you choose to use this method to store the cluster key, you must provide a cluster key password before installing the AD RMS server role on the first server in the cluster. You can use the following command to verify that the drive namespace is configured to use the centrally managed cluster key storage: Get-ItemProperty -Path <drive>:\clusterkey -Name UseCentrallyManaged Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To set the centrally managed cluster key password 1. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterkey -Name UseCentrallyManaged -Value $true where <drive> is the name of the Windows PowerShell drive. 2. To securely store the cluster key password in a variable, at the Windows PowerShell command prompt, type: $password = Read-Host -AsSecureString -Prompt Password: 3. Type the cluster key password, and then press the ENTER key. 4. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterkey -Name CentrallyManagedPassword -Value $password where <drive> is the name of the Windows PowerShell drive. Using a CSP to store the cluster key When you configure the server to use a CSP to protect the cluster key, you must specify the key container name. You should also ensure that a new key pair will be created when the server is installed. To list the CSPs that are available on the server, at the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\clusterkey\csp -Name Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To specify a CSP to store the cluster key 1. To enable CSP key protection and specify the CSP to be used, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterkey -Name UseCSP -Value $true Set-ItemProperty -Path <drive>:\clusterkey -Name CSPName -Value <CSP> where <drive> is the name of the Windows PowerShell drive and <CSP> is the name of 18

19 the CSP to be used to protect the store key. 2. Do one of the following: To ensure that a new key pair will be created for the CSP when AD RMS is installed, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterkey -Name CreateNewKeyPair -Value $true To reuse an existing CSP key pair, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\clusterkey -Name UseExistingKeyPair -Value $true Set-ItemProperty -Path <drive>:\clusterkey -Name KeyContainerName - Value <KeyPairName> where <drive> is the name of the Windows PowerShell drive and <KeyPairName> is the name of a CSP key pair in the CSP container specified in the previous step. Back to top Setting the cluster Web site Before completing the installation of the AD RMS server role, you must specify the Web site where the AD RMS Web services will be installed if you are not using the default Web site. If you have installed the Internet Information Services (IIS) 6 Management Compatibility Service, you can get a listing of the Web sites hosted on the server by typing at a Windows PowerShell command prompt: Get-ChildItem -Path <drive>:\clusterwebsite where <drive> is the name of the Windows PowerShell drive. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To specify the cluster Web site At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\clusterwebsite -Name WebSiteName -Value <web_site> where <drive> is the name of the Windows PowerShell drive and <web_site> is the name of the Web site to be used to host the AD RMS Web services. Setting the cluster address AD RMS clients use the cluster address to communicate with the cluster over the network. As a best security practice, you should specify an SSL-encrypted connection (that is, a connection that 19

20 uses as the AD RMS cluster address. If you specify an SSL-encrypted connection, you must configure the server with a valid certificate for SSL encryption. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To specify the cluster address At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name ClusterURL -Value http[s] ://<cluster_url>:<port> where <drive> is the name of the Windows PowerShell drive, <cluster_url> is the URL of the AD RMS cluster, and <port> is the number of the port used to access the cluster URL. For example, to set the property on a drive named RC to specify an unencrypted connection to a URL named Cluster1 on the default port, type: Set-ItemProperty -Path RC:\ -Name ClusterURL -Value To specify an encrypted connection to the same URL, type: Set-ItemProperty -Path RC:\ -Name ClusterURL -Value Back to top Setting the SLC name When the AD RMS server role is installed and configured on the first server in the cluster, AD RMS generates a unique SLC for itself called self-enrollment that establishes its identity and that has a validity time of 250 years. This enables the archiving of rights-protected data for an extended period of time. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To specify the SLC name At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name SLCName -Value <SLC_name> where <drive> is the name of the Windows PowerShell drive and <SLC_Name> is the name you want to use to identify the SLC that will be created. Back to top Registering the SCP By default, the service connection point (SCP) for AD RMS is registered in Active Directory Domain Services when you install the AD RMS server role on the first server in a root cluster. The 20

21 SCP identifies the connection URL for the service to the AD RMS-enabled clients in your organization. After you register the SCP in Active Directory Domain Services (AD DS), clients will be able to discover the AD RMS cluster to request use licenses, publishing licenses, and rights account certificates (RACs). If you do not register the SCP when you install the first server in the root cluster, you can register the SCP from the cluster Properties sheet in the Active Directory Rights Management Services console. Note If you are registering an SCP from an AD RMS cluster in a child domain, you might receive an error stating that SCP registration failed. In many cases, the registration was successful, but the registration first takes place in the top-level domain and it takes time to replicate to the child domain where the AD RMS cluster checks for the SCP object. If this happens, allow enough time for the SCP to be replicated to all global catalog servers before attempting to re-register the SCP. To verify that the drive namespace is configured to register the SCP, at the Windows PowerShell command prompt, type: Get-ItemProperty -Path <drive>:\ -Name RegisterSCP If the RegisterSCP property is set to False, you can use the following procedure to register the SCP when the AD RMS server role is installed. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To register the SCP At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\ -Name RegisterSCP -Value $true where <drive> is the name of the Windows PowerShell drive. Installing an AD RMS Cluster Creating an AD RMS Cluster Windows PowerShell Drive Running the Install-ADRMS Cmdlet Running the Install-ADRMS Cmdlet After you create a Windows PowerShell drive and set properties on containers in the drive namespace, the final step in using Windows PowerShell cmdlets to install the first server in an Active Directory Rights Management Services (AD RMS) cluster is to run the Install-ADRMS cmdlet. 21

22 The Install-ADRMS cmdlet performs two principal functions: It installs any prerequisite features or services that are not yet installed on the server. It installs the AD RMS server role with the configuration settings represented by the properties set on containers in the drive namespace. To run the Install-ADRMS cmdlet At the Windows PowerShell command prompt, type: Set-Location <drive>:\ Install-ADRMS -Path. where <drive> is the name of the Windows PowerShell drive. You must set the current location to the root of the Windows PowerShell drive before running the Install-AD RMS cmdlet. The path supplied with the -Path parameter must be the same as the current location. Installing an AD RMS Cluster Creating an AD RMS Cluster Windows PowerShell Drive Setting Properties on Objects in the AD RMS Drive Namespace Joining an Existing Cluster For most purposes, joining one or more Active Directory Rights Management Services (AD RMS) servers to a root cluster is the best way to increase the availability and redundancy of your deployment. A root cluster can contain one or many servers that provide all services to AD RMS clients. You can also join an AD RMS server to a licensing-only cluster. When you install the AD RMS server role on a computer running Windows Server 2008 R2, you can choose the option to join the server to a cluster. When joining a server to a cluster, you must configure your load balancing software or hardware to work with the new cluster member. Before you can use Windows PowerShell cmdlets to install the AD RMS server role, you must start Windows PowerShell with administrator privileges after logging in with an account that meets the following requirements: Important The user account that you use to install AD RMS must not be the same account as the AD RMS service account. If you are using an external database server for the AD RMS databases, the user account that you use to install AD RMS must have the right to create new databases. If Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is used, the user account must be a member of the System Administrators database role, or equivalent. 22

23 The user account that you use to install AD RMS must have access to query the AD DS domain, such as a domain user account. The user account that you use to install AD RMS must be a member of the Administrators group, or equivalent, on the server. Installing and provisioning AD RMS as a member server in an existing AD RMS cluster consists of the following steps: 1. Create the Windows PowerShell drive to represent the server that you are provisioning. For more information, see Creating an AD RMS Server Windows PowerShell Drive. 2. Set properties on objects in the drive namespace that represent required configuration settings. For more information, see Setting Properties on Objects in the AD RMS Drive Namespace. 3. Run the Install-ADRMS cmdlet. In addition to installing the AD RMS server role and provisioning the server, this cmdlet also installs other features required by AD RMS, such as Message Queuing, if necessary. For more information, see Running the Install-ADRMS Cmdlet. Using Windows PowerShell to Deploy AD RMS Understanding the AD RMS Deployment Provider Namespace Creating an AD RMS Server Windows PowerShell Drive By creating an Active Directory Rights Management Services (AD RMS) deployment Windows PowerShell provider drive, you create a namespace that contains items that represent configuration settings of the server you are joining to an existing AD RMS cluster. To create the Windows PowerShell drive At a Windows PowerShell prompt, type: Import-Module ADRMS New-PSDrive -PSProvider ADRMSInstall -Name <drive> -Root JoinCluster where <drive> is the name of the Windows PowerShell drive you are creating. For example, to create a Windows PowerShell drive named NewSvr to install and provision a new server in an existing AD RMS cluster, type: New-PSDrive -PSProvider ADRMSInstall -Name NewSvr -Root JoinCluster 23

24 After creating the drive, do not exit the Windows PowerShell command prompt until you have finished installing the AD RMS server role. Doing so will delete the drive and all property settings will be lost. Joining an Existing Cluster Setting Properties on Objects in the AD RMS Drive Namespace Running the Install-ADRMS Cmdlet Setting Properties on Objects in the AD RMS Drive Namespace Setting properties on objects in the drive namespace is similar to using a wizard to specify configuration settings when installing a server role. Before you can finish the installation by running the Install-ADRMS cmdlet, you must provide necessary information about the initial configuration of the server role. The following table lists the required settings and the properties that represent those settings in the drive namespace. Setting name Property name Location Database server ServerName <drive>:\clusterdatabase Database name DatabaseName <drive>:\clusterdatabase Cluster key password CentrallyManagedPassword <drive>:\clusterkey Service account ServiceAccount <drive>:\ Cluster Web site WebSiteName <drive>:\clusterwebsite Note The CentrallyManagedPassword property is not available if you are using either a software- or hardware-based cryptographic service provider (CSP) to protect the cluster key. If you are using a CSP, you must manually move the cluster key to the other computers before installing AD RMS. Consult the CSP documentation for procedures on moving the cluster key. The following sections describe the configuration settings you must specify by setting properties on objects in the Windows PowerShell drive namespace when adding a server to an existing Active Directory Rights Management Services (AD RMS) cluster. 24

25 Setting the database server When an AD RMS server is provisioned as a member of an existing cluster, it must be configured to use the cluster database server. To set the cluster database server 1. At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\clusterdatabase -Name ServerName -Value <db_server> where <drive> is the name of the Windows PowerShell drive and <db_server> is the name of the cluster database server. Setting the database name When the AD RMS server role is installed on the first server in a cluster, AD RMS creates a database on the specified server that it uses to record configuration, logging, and other information. When another AD RMS server is joined to the cluster, it must be configured to use the same database. To set the cluster database name 1. To list the database instances hosted by the cluster database server, at the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\clusterdatabase\databaseinstance where <drive> is the name of the Windows PowerShell drive. 2. To list the databases hosted by a database instance, at the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\clusterdatabase\databaseinstance\<db_instance> where <drive> is the name of the Windows PowerShell drive and <db_instance> is the name of a database instance. 3. To set the database name, at the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\clusterdatabase -Name DatabaseName -Value <db_name> where <drive> is the name of the Windows PowerShell drive and <db_name> is the name of the cluster database. 25

26 Setting the cluster key password If you are using AD RMS to centrally manage the cluster key, you must set the cluster key password before you can add the server to the cluster. To set the centrally managed cluster key password 1. To securely store the cluster key password in a variable, at the Windows PowerShell command prompt, type: $password = Read-Host -AsSecureString -Prompt Password: 2. Type the cluster key password, and then press the ENTER key. 3. At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\clusterkey -Name CentrallyManagedPassword -Value $password where <drive> is the name of the Windows PowerShell drive. Setting the service account During installation, AD RMS creates the AD RMS Service Group on the local computer and grants it appropriate permissions on all of the resources that are required for AD RMS to operate. When you install the AD RMS server role, you must define a domain account for use as the AD RMS service account. That account is made a member of the AD RMS Service Group, and it is granted the permissions that are associated with this group. During routine operations, AD RMS runs under the AD RMS service account. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To set the AD RMS service account 1. At the Windows PowerShell command prompt, type: $svcacct = Get-Credential A dialog box appears. 2. In the dialog box, type the account domain and name (in the form <domain>\<account>) and password. 3. At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\ -Name ServiceAccount -Value $svcacct where <drive> is the name of the Windows PowerShell drive. 26

27 Setting the cluster Web site Before completing the installation of the AD RMS server role, you must specify the Web site where the AD RMS Web services will be installed if you are not using the default Web site. If you have installed the Internet Information Services (IIS) 6 Management Compatibility Service, you can get a listing of the Web sites hosted on the server by typing at a Windows PowerShell command prompt: Get-ChildItem -Path <drive>:\clusterwebsite where <drive> is the name of the Windows PowerShell drive. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To set the cluster Web site At the Windows PowerShell command prompt, type: Back to top Set-ItemProperty -Path <drive>:\clusterwebsite -Name WebSiteName -Value <web_site> where <drive> is the name of the Windows PowerShell drive and <web_site> is the name of the Web site to be used to host the AD RMS Web services. Joining an Existing Cluster Creating an AD RMS Server Windows PowerShell Drive Running the Install-ADRMS Cmdlet Running the Install-ADRMS Cmdlet After you create a Windows PowerShell drive and set properties on containers in the drive namespace, the final step in using Windows PowerShell cmdlets to add a server to an existing Active Directory Rights Management Services (AD RMS) cluster is to run the Install-ADRMS cmdlet. The Install-ADRMS cmdlet performs two principal functions: It installs any prerequisite features or services that are not yet installed on the server. It installs the AD RMS server role with the configuration settings represented by the properties set on containers in the drive namespace. To run the Install-ADRMS cmdlet At the Windows PowerShell command prompt, type: 27

28 Set-Location <drive>:\ Install-ADRMS -Path. where <drive> is the name of the Windows PowerShell drive. You must set the current location to the root of the Windows PowerShell drive before running the Install-AD RMS cmdlet. The path supplied with the Path parameter must be the same as the current location. Joining an Existing Cluster Creating an AD RMS Server Windows PowerShell Drive Setting Properties on Objects in the AD RMS Drive Namespace Adding or Removing Federated Identity Support After creating an Active Directory Rights Management Services (AD RMS) cluster, you can use Windows PowerShell cmdlets to add federated identity support to the cluster. You can also use Windows PowerShell cmdlets to remove federated identity support from a cluster without affecting other AD RMS settings. It is not necessary to create a Windows PowerShell drive in order to add or remove federated identity support. Before you add AD RMS federated identity support, you should ensure that the following conditions have been met: Important Ensure that you specified a secure cluster address when you installed AD RMS. Active Directory Federation Services (AD FS) requires secure communication between AD RMS and the AD FS resource server. Use the Local Security Policy console to assign the Generate Security Audits privilege to the AD RMS service account. Configure a federated trusted relationship before you add federated identity support. When you add federated identity support, you must specify the URL of the federation service. Ensure that the AD RMS extranet cluster URLs are accessible to the federated account partner. The following sections describe how to use Windows PowerShell cmdlets to add federated identity support to an existing cluster and to remove it when it is no longer needed. 28

29 Adding federated identity support Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To add federated identity support At a Windows PowerShell command prompt, type: Import-Module ADRMS Install-ADRMS -ADFSUrl where <federation_server> is the name of the federation server. Specify this name by using lowercase letters only. Removing federated identity support Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To remove federated identity support At a Windows PowerShell command prompt, type: Import-Module ADRMS Uninstall-ADRMS -ADFSOnly Using Windows PowerShell to Deploy AD RMS AD RMS Deployment Cmdlets Upgrading the AD RMS Server Role After you upgrade a server that is running Windows Rights Management Services SP2 on Windows Server 2003 or that is running the Active Directory Rights Management Services (AD RMS) server role on Windows Server 2008, you must upgrade the AD RMS server role. You can use Windows PowerShell cmdlets to perform this task. The cmdlets that you use depend on whether the AD RMS cluster that the server belongs to uses a cryptographic service provider (CSP) or the AD RMS configuration database to store the cluster key. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. 29

30 To upgrade the AD RMS server role on a cluster that uses a CSP 1. At a Windows PowerShell command prompt, type: Import-Module ADRMS $svcacct = Get-Credential 2. In the dialog box that appears, type the user name and password of the AD RMS service account. 3. At the Windows PowerShell command prompt, type: Update-ADRMS -ServiceAccount $svcacct To upgrade the AD RMS server role on a cluster that does not use a CSP 1. At a Windows PowerShell command prompt, type: Import-Module ADRMS $svcacct = Get-Credential 2. In the dialog box that appears, type the user name and password of the AD RMS service account. 3. At the Windows PowerShell command prompt, type: $pword = Read-Host -AsSecureString -Prompt Password: 4. Type the cluster key password, and then press the ENTER key. 5. At the Windows PowerShell command prompt, type: Update-ADRMS -ServiceAccount $svcacct -PrivateKeyPassword $pword Important If the Identify Federation Support role service was installed and configured before you performed the upgrade, you must remove and then reinstall Identity Federation Support after running the Update-AD RMS cmdlet. If you do not, federation support will stop functioning. For more information, see Adding or Removing Federated Identity Support. Using Windows PowerShell to Deploy AD RMS AD RMS Deployment Cmdlets Pre-installation Information for Active Directory Rights Management Services Removing the AD RMS Server Role You can use a Windows PowerShell cmdlet to remove the Active Directory Rights Management Services (AD RMS) server role from a server. 30

31 Important If you are removing every server in the AD RMS cluster, be sure to first decommission AD RMS and remove all protection from the content that is rights-protected by this AD RMS cluster. For more information, see Decommissioning AD RMS. If you are only removing one AD RMS server from the cluster, you do not need to decommission the AD RMS environment because other servers continue to issue certification and licensing requests to AD RMS users. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To remove the AD RMS server role At a Windows PowerShell command prompt, type: Import-Module ADRMS Uninstall-ADRMS Using Windows PowerShell to Deploy AD RMS AD RMS Deployment Cmdlets Installing an AD RMS Cluster Joining an Existing Cluster Adding or Removing Federated Identity Support Decommissioning AD RMS Removing an AD RMS Cluster Using Windows PowerShell to Administer AD RMS The Active Directory Rights Management Services (AD RMS) Windows PowerShell administration module gives you the ability to administer all aspects of an AD RMS cluster by using Windows PowerShell cmdlets. The provider in the administration module presents a drive namespace that is based on the organization of cluster settings that is shown by the AD RMS graphical user interface (GUI). Within this namespace, you manage cluster settings by creating and setting properties on items in the containers that are arranged hierarchically in the namespace, most often by using common Windows PowerShell cmdlets, such as New-Item and Set-ItemProperty. In some cases, the AD RMS Windows PowerShell administration module implements special-purpose cmdlets to perform tasks that cannot be performed by using common cmdlets. 31

32 Note The AD RMS Windows PowerShell administration module does not support the 32-bit version of Windows PowerShell. It can only be used on the 64-bit version. Getting started Before you can administer AD RMS by using Windows PowerShell cmdlets, after starting Windows PowerShell, you must perform three tasks: 1. Import the AD RMS Windows PowerShell administration module. 2. Create a Windows PowerShell drive that represents the AD RMS cluster you want to administer. 3. Set the current location to a container on the drive you created. The following procedures explain how to perform each of these tasks. Import the module At the Windows PowerShell prompt, type: Import-Module AdRmsAdmin Create the drive At the Windows PowerShell prompt, type: New-PSDrive -Name <drivename> -PsProvider AdRmsAdmin -Root <clusterurl> where <drivename> is the name you want to assign to the new drive, and <clusterurl> is the URL of the AD RMS cluster you want to administer. For example, to create a drive named AdrmsCluster that represents the AD RMS cluster hosted by the local computer, type: New-PSDrive -Name AdrmsCluster -PsProvider AdRmsAdmin -Root Set the current location At the Windows PowerShell command prompt, type: Set-Location <drivename>:\[<container>] where <drivename> is the name of the drive, and <container> is the optional path name of container within the drive. For information about how to use these containers, see Understanding the AD RMS Administration Provider Namespace. For example, to set the current location to the TrustPolicy\TrustedPublishingDomain container in the AdrmsCluster drive, type: Set-Location AdrmsCluster:\TrustPolicy\TrustedPublishingDomain 32

33 Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Installing Microsoft Federation Gateway Support Configuring AD RMS Cluster Properties Administering Certificates Enabling Exclusion Policies Establishing Trust Policies Managing AD RMS Databases Configuring Accounts Configuring Rights Policy Templates Working with Reports Decommissioning AD RMS Understanding the AD RMS Administration Provider Namespace The Active Directory Rights Management Services (AD RMS) Windows PowerShell administration provider exposes a namespace that represents the various configuration settings that you can make to a server running AD RMS. You configure these settings by using Windows PowerShell cmdlets to traverse this namespace and then create or delete items in the namespace, or set properties on those items. The namespace closely parallels the hierarchy of settings that are made available in the AD RMS graphical user interface (GUI) administration tools to make it easier to associate the items in the administration namespace with the corresponding settings exposed by the GUI tools. This topic lists the containers in the administration namespace, explains what configuration settings each container represents, and lists the subcontainers or items that it can hold. <drive>:\ The root container of the administration namespace represents the properties of the cluster itself. You can work with these properties by using the Get-ItemProperty and Set-ItemProperty cmdlets to view and change the following properties: IsDecommissioned AdministrativeContact IsLoggingEnabled IntranetLicensingUrl ExtranetCertificationUrl ExtranetLicensingUrl 33

34 SvrLicCertFriendlyName ScpUrl IsProxyRequired You can also use the Get-ItemProperty cmdlet to view these read-only properties: ClusterName ClusterType ClusterServerList LoggingDatabaseServer LoggingDatabaseName LoggingServiceName LoggingQueueName ConfigurationDatabaseServer ConfigurationDatabaseName IntranetCertificationUrl SvrLicCertHierarchy RegisteredServiceDomain <drive>:\exclusionpolicy This container holds containers that represent the application, lockbox, and user exclusion policies of the cluster. For more information about working with exclusion policies, see Enabling Exclusion Policies. <drive>:\exclusionpolicy\application This container holds items that represent excluded application versions. Use Set- ItemProperty to change the IsEnabled property of the container to enable or disable application exclusion. To control which application versions are excluded, use the New- Item and Remove-Item cmdlets. For more information, see Excluding Applications. <drive>:\exclusionpolicy\lockbox This container holds items that represent excluded application lockboxes. Use Set- ItemProperty to change the IsEnabled property of the container to enable or disable lockbox exclusion. To change the minimum lockbox version, set the LockBoxMinimumVersionproperty. For more information, see Excluding Lockboxes. <drive>:\exclusionpolicy\user This container holds items that represent excluded users. Use Set-ItemProperty to change the IsEnabled property of the container to enable or disable user exclusion. To 34

35 control which users are excluded, use the New-Item and Remove-Item cmdlets. For more information, see Excluding Users. <drive>:\issuancepolicy This container represents the rights account certificate issuance policy. Use the Set- ItemProperty cmdlet to set the StandardCertValidityPeriodInDays and TemporaryCertValidityPeriodInMinutes properties of the container to modify this policy. For more information, see Specifying the Rights Account Certificate Validity Duration. <drive>:\report This container gives you access to a set of cmdlets that query the cluster databases for different kinds of information. For more information, see Working with Reports. <drive>:\rightspolicytemplate This container holds subcontainers that represent rights policy templates. Use the Set- ItemProperty cmdlet to set the PublishUNCFilePath property of this container to specify where templates are published. To create a rights policy template, use the New- Item cmdlet, use the Copy-Item cmdlet to copy a template, and use the Remove-Item cmdlet to remove a template. For more information, see Configuring Rights Policy Templates and Creating a New Rights Policy Template. <drive>:\rightspolicytemplate\<templateid> This container represents the rights policy template identified by <templateid> and holds subcontainers that represent settings of the template. Use the Set-ItemProperty cmdlet to change the IsDistributed property of this container to distribute or archive the template. If the template is archived, you can also set the IsReadyOnly property. For more information, see Configuring Rights Policy Templates and Archiving a Rights Policy Template. <drive>:\rightspolicytemplate\<templateid>\expirationpolicy This container represents the expiration policy for the rights policy template identified by <templateid>. Use the Set-ItemProperty cmdlet to set the ContentExpiredOnDateInDaysOrNever and UseLicenseExpiredInDays properties of this container. For more information, see Editing a Rights Policy Template. <drive>:\ RightsPolicyTemplate\<templateID>\ExtendedPolicy This container represents the extended policy settings of the rights policy template 35

36 identified by <templateid> and contains items that represent application-specific policy name-value pairs. Use the Set-ItemProperty cmdlet to set the IsViewInTrustedBrowserEnabled and IsOnetimeLicenseEnabled properties of the container, and use the New-Item cmdlet to add a name-value pair. For more information, see Editing a Rights Policy Template. <drive>:\ RightsPolicyTemplate\<templateID>\IdentificationInfo This container holds items that represent the locale-specific information of the rights policy template identified by <templateid>. Use the New-Item cmdlet to add localespecific identification information to the template. For more information, see Editing a Rights Policy Template. <drive>:\ RightsPolicyTemplate\<templateID>\RevocationPolicy This container represents the revocation policy of the rights policy template identified by <templateid>. Use the Set-ItemProperty cmdlet to set the Location, RefreshPerDays, and PublicKeyFilePath properties of this container. For more information, see Editing a Rights Policy Template. <drive>:\ RightsPolicyTemplate\<templateID>\UserRight This container holds items representing users and the rights granted to them. Use the Set-ItemProperty cmdlet to set the RightsRequestUrl and CustomRightDefinitionList properties of the container. Use the New-Item cmdlet to add a user and assign rights to the user. For more information, see Editing a Rights Policy Template. <drive>:\securitypolicy This container holds subcontainers that represent the super-user and cluster key password settings of the cluster. <drive>:\securitypolicy\superuser This container represents the super-user security settings of the cluster. Use the Set- ItemProperty cmdlet to enable or disable the IsEnabled and the SuperUserGroup properties of the container. For more information, see Setting up a Super Users Group. <drive>:\securitypolicy\clusterkeypassword This container represents the cluster key password settings of the cluster. Use the Set- ItemProperty cmdlet to change the cluster key password. For more information, see 36

37 Resetting the AD RMS Cluster Key Password. <drive>:\trustpolicy This container holds items that represent the cluster s federated identity support and collections of trusted domains. For more information, see Establishing Trust Policies. <drive>:\trustpolicy\federatedidentitysupport This container represents the federated identity support policy of the cluster and is available only when federated identity support is installed. Use the Set-ItemProperty cmdlet to set the IsEnabled, CertificateValidityPeriod, CertificateServiceUrl, and IsProxy AddressAllowed properties of the container. For more information, see Configuring Federated Identity Support Settings. <drive>:\trustpolicy\trustedpublishingdomain This container holds items that represent the publishing domains trusted by the cluster. Use the Import-RmsTPD cmdlet to add a trusted publishing domain to this container and the Remove-Item cmdlet to remove a trusted publishing domain. You can also use the Export-RmsTPD cmdlet to export a trusted publishing domain to a file. For more information, see Adding a Trusted Publishing Domain and Exporting a Trusted Publishing Domain. <drive>:\trustpolicy\trusteduserdomain This container holds items that represent the user domains trusted by the cluster. Use the Import-RmsTUD cmdlet to add a trusted useer domain to this container and the Remove-Item cmdlet to remove a trusted user domain. You can also use the Export- RmsTUD cmdlet to export a trusted user domain to a file. For more information, see Adding a Trusted User Domain, Using Windows Live ID to Establish RACs for Users, and Exporting a Trusted User Domain. <drive>:\trustpolicy\trusteduserdomain\<domainid> This container represents a user domain trusted by the cluster. These user domains can include the internal trusted user domain (TUD), an external TUD that was previously imported, or Windows Live ID. Use the Set-ItemProperty cmdlet to set the IsLicensingToSIDEnabled property of an internal or external TUD, the Trusted Domain property of an external TUD or the Windows Live ID domain, or the IsADFederatedUserTrused property of an external TUD. 37

38 AD RMS Administration Cmdlets Administering Certificates Enabling Exclusion Policies Establishing Trust Policies Configuring Accounts Configuring Rights Policy Templates Working with Reports AD RMS Administration Cmdlets The Active Directory Rights Management Services (AD RMS) Windows PowerShell administration module gives you the ability to administer all aspects of an AD RMS cluster by using Windows PowerShell cmdlets. Most often, you will perform these tasks by using common Windows PowerShell cmdlets, such as New-Item and Set-ItemProperty, that manipulate objects in the AD RMS Windows PowerShell administration namespace. In cases where common cmdlets cannot provide the required functionality for AD RMS administration, the AD RMS Windows PowerShell administration module implements special-purpose cmdlets to perform tasks that cannot be performed by using common cmdlets. These cmdlets are available only when the current location or the Path parameter is set to a specific path in the AD RMS Windows PowerShell administration namespace. The following table briefly describes these cmdlets. For complete information about a cmdlet, at a Windows PowerShell prompt, type Get-Help <cmdlet_name> -full. Cmdlets that are marked with an asterisk (*) are available only on systems with Service Pack 1 (SP1) for Windows Server 2008 R2 installed. Path Cmdlet Description <drive>:\ Get-RmsSvcAccount The Get- RmsSvcAccoun t cmdlet gets service account credentials for an AD RMS cluster. Set-RmsSvcAccount The Set- RmsSvcAccoun t cmdlet sets the 38

39 Path Cmdlet Description service account for an AD RMS cluster. Update-RmsCluster Install-RmsMfgEnrollment* The Update- RmsCluster cmdlet updates the cluster information including the hierarchy of content that defines the cluster. You must set the current location to the root before running this cmdlet; the Path parameter is ignored. Enrolls the AD RMS cluster with the Microsoft Federation Gateway. Install-RmsMfgSupport* Adds Microsoft Federation Gateway Support to the AD RMS server. Uninstall-RmsMfgEnrollment* Removes the enrollment of the AD RMS cluster with the AD RMS. Uninstall-RmsMfgSupport* Removes Microsoft 39

40 Path Cmdlet Description Federation Gateway Support from the AD RMS server. <drive>:\report Update-RmsMfgEnrollment* Export- RmsReportDefinitionLangua ge Get-RmsCertChain Get-RmsCertInfo Updates one or both of the Microsoft Federation Gateway Support certificates. This cmdlet exports report definition (.rdl) files for this version of AD RMS. This cmdlet generates a report that contains information about the certificate chain of a particular user request on the AD RMS cluster. This cmdlet generates a report that contains information about a particular certificate used in a user request on the AD RMS cluster. 40

41 Path Cmdlet Description Get-RmsChildCert Get-RmsEncryptedIL Get-RmsRequestInfo This cmdlet returns all issuance licenses from a parent client licensor certificate (CLC) or all end-user licenses (EULs) from a parent issuance license used in a user request on the AD RMS cluster. This cmdlet generates a report containing information about an issuance license used in a user request on the AD RMS cluster. To use this cmdlet, you must be logged in as an Enterprise Administrator and XrML certificate logging must be enabled. See Creating an Issuance License Report for more information. This cmdlet generates a report that 41

42 Path Cmdlet Description contains detailed information about a particular user request on the AD RMS cluster. Get-RmsSystemHealthReport This cmdlet generates a report that contains information about the overall health of the AD RMS cluster. <drive>:\trustpolicy\trustedpublishingdom ain Get-RmsUserRequestReport Export-RmsTPD Import-RmsTPD This cmdlet generates a report that contains statistics about the request activity of a single user on the AD RMS cluster. This cmdlet exports a trusted publishing domain (TPD) to a file. This cmdlet imports a TPD from a file. <drive>:\trustpolicy\trusteduserdomain Export-RmsTUD This cmdlet exports a trusted user domain (TUD) to a file. Import-RmsTUD This cmdlet imports a TUD 42

43 Path Cmdlet Description from a file. For complete information about these cmdlets, see AD RMS Cmdlets in Windows PowerShell ( Installing Microsoft Federation Gateway Support The tasks in this section are designed to help you add Microsoft Federation Gateway Support to your Active Directory Rights Management Services (AD RMS) cluster. This section contains the following tasks: Adding Microsoft Federation Gateway Support Enrolling with the Microsoft Federation Gateway Installing an AD RMS Cluster Configuring Microsoft Federation Gateway Support Understanding the Microsoft Federation Gateway Checklist: Deploying AD RMS with Microsoft Federation Gateway Support Adding Microsoft Federation Gateway Support Windows Server 2008 R2 with Service Pack 1 (SP1) must be installed on every server in your Active Directory Rights Management Services (AD RMS) cluster before you can add Microsoft Federation Gateway Support to the servers in your cluster. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. Important Before adding Microsoft Federation Gateway Support, back up the AD RMS configuration database. To add Microsoft Federation Gateway Support 43

44 1. At the Windows PowerShell command prompt, type: Install-RmsMfgSupport Important Do not run this command if the AD RMS snap-in is open in the Microsoft Management Console (MMC). If you do, the command will not respond until you close the AD RMS MMC snap-in. 2. Repeat step 1 on all other servers in the AD RMS cluster. Caution Before uninstalling Service Pack 1 for Windows Server 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster. For more information, see Removing Microsoft Federation Gateway Support. Understanding the AD RMS Administration Provider Namespace Installing Microsoft Federation Gateway Support Configuring Microsoft Federation Gateway Support Enrolling with the Microsoft Federation Gateway In order to use the Microsoft Federation Gateway, after you add Microsoft Federation Gateway Support, you must enroll your Active Directory Rights Management Services (AD RMS) cluster with the Microsoft Federation Gateway. After this, you must configure and enable Microsoft Federation Gateway Support. The following procedure explains this process. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. To enroll the AD RMS cluster and enable Microsoft Federation Gateway Support 1. Do one of the following: To enroll by using the default AD RMS cluster certificate, at the Windows PowerShell command prompt, type: Install-RmsMfgEnrollment To enroll by using a different certificate, at the Windows PowerShell command prompt, type: 44

45 Install-RmsMfgEnrollment -CertificateThumbprint <thumbprint> where <thumbprint> is a string containing the thumbprint hash of the certificate being used to enroll with the Microsoft Federation Gateway. Important If you use a certificate that contains a subject alternate name (SAN), the last entry in the SAN list must be the fully qualified domain name of the domain you want to enroll with the Microsoft Federation Gateway. 2. On all servers in the AD RMS cluster, perform the task described in Granting the AD RMS Service Group Permission to the SSL Certificate. 3. Perform the following tasks, as needed: Setting the Microsoft Federation Gateway RAC Validity Period Managing the Microsoft Federation Gateway Licensing Filter List Managing the Microsoft Federation Gateway Publishing Filter List 4. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name IsEnabled -Value $true where <drive> is the name of the Windows PowerShell drive. To avoid conflicts, you should not enroll your AD RMS cluster with the Microsoft Federation Gateway by using the same URL that has been used to federate another resource with the Microsoft Federation Gateway. Other federated relationships to the Microsoft Federation Gateway can include (but are not limited to) federations to Microsoft Online and Microsoft Exchange Server. If you have already used the URL that your AD RMS cluster uses as its external URL to federate with the Microsoft Federation Gateway for another purpose, you must enroll the AD RMS cluster with the Microsoft Federation Gateway by creating and using a certificate that contains the AD RMS URL as the last entry in the SAN and with a common name (CN) that is not the same as the registered resource. For example, if the DNS name of your AD RMS server is resource.contoso.com, and if that name has already been used by another resource that has been federated to the Microsoft Federation Gateway, you can create a certificate in the following format to avoid federation conflicts: Subject: CN=adrmsservice.contoso.com SAN: DNS Name=adrmsservice.contoso.com DNS Name=resource.contoso.com Installing Microsoft Federation Gateway Support Understanding the AD RMS Administration Provider Namespace 45

46 Configuring Microsoft Federation Gateway Support Configuring AD RMS Cluster Properties The tasks in this section are designed to help you configure an Active Directory Rights Management Services (AD RMS) server cluster. This section contains the following tasks: Changing the Intranet Licensing URL Adding an Extranet Cluster URL Changing AD RMS Proxy Settings Registering a Service Connection Point Changing the Intranet Licensing URL The intranet licensing URL is used by Active Directory Rights Management Services (AD RMS) clients that are connected to your organization's private network to connect to licensing services in the AD RMS cluster. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To change the intranet licensing URL At the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Property IntranetLicensingURL -Value <URL> where <drive> is the name of the Windows PowerShell drive and <URL> is the new intranet licensing URL. For example, if you have created a Windows PowerShell drive named Z:, to set the intranet licensing URL to a secure sockets layer (SSL) URL for a server named rms.contoso.com, type: Set-ItemProperty -Path Z:\ -Name IntranetLicensingURL -Value Understanding the AD RMS Administration Provider Namespace 46

47 Configuring AD RMS Cluster Properties Adding an Extranet Cluster URL The extranet cluster URLs are used by Active Directory Rights Management Services (AD RMS) clients that are outside of your internal network to connect to the AD RMS cluster for licensing and certification. Be sure to register the URLs in your Domain Name System (DNS), and verify that they are available from the Internet. If you are adding extranet cluster URLs to an existing AD RMS cluster, new client licensor certificates (CLC) must be obtained by the current AD RMS clients. The extranet cluster URLs are added to the Extranet-License-Acquisition-URL field in the issuance license and used in AD RMS client service discovery. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To set the extranet cluster URLs At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name ExtranetLicensingUrl -Value <LicensingURL> Set-ItemProperty -Path <drive>:\ -Name ExtranetCertificationUrl - Value <CertificationURL> where <drive> is the name of the Windows PowerShell drive, <LicensingURL> is the extranet URL for licensing services, and <CertificationURL> is the extranet URL for certification services. For example, if you have created a Windows PowerShell drive named Z:, to set both extranet URLs to secure sockets layer (SSL) URLs for a server named rms.contoso.com, type: Set-ItemProperty -Path Z:\ -Name ExtranetLicensingURL -Value Set-ItemProperty -Path Z:\ -Name ExtranetCertificationURL -Value Understanding the AD RMS Administration Provider Namespace Configuring AD RMS Cluster Properties AD RMS Client Service Discovery 47

48 Changing AD RMS Proxy Settings If you control access to resources outside of the local forest by a Web proxy server, you may need to configure Active Directory Rights Management Services (AD RMS) to use the proxy in some scenarios. Situations that require this are the following: You are trusting rights account certificates (RACs) from Windows Live ID users. When you select to trust Windows Live ID sites and services as one of your trusted user domains, the AD RMS cluster needs to be able to validate the user against Windows Live ID sites and services. You have multiple forests in your organization that are separated by a Web proxy server, and you have established trusts across those forests. This is similar to the scenario with Windows Live ID in that the registry of user accounts that the AD RMS cluster must validate against is behind the Web proxy server. If your AD RMS cluster does not need to negotiate a connection through a proxy server, you do not need to configure these settings. If the proxy server authenticates users before allowing outbound access, you must provide a user account that AD RMS can use when challenged for credentials by the proxy server. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To change AD RMS proxy settings To require a proxy server and optionally set proxy settings, at the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsProxyRequired -Value $true - ProxyAddress <proxy_url> [-ProxyBypassLocalAddress $true] [-ProxyBypassFilter <filter_string> ] [-ProxyAuthenticationScheme <authentication_type> - ProxyAuthenticationCredential [[<domain>\]<user_name>]] where <drive> is the name of the Windows PowerShell drive. <proxy_url> is the address and port of the proxy server, for example, <filter_string> is a list of addresses that should not go through the proxy server. <authentication_type> is the authentication type used to connect to the proxy server and must be one of the following: Basic, Digest, or WindowsIntegrated. <domain> and <user_name> are the domain and user name of the account used to authenticate to the proxy server. If you specify -ProxyAuthenticationCredential with the domain and user name, you are prompted for the password of the account. If you specify -ProxyAuthenticationCredential without the domain and user name on the command line, you are prompted for the domain, user name, and password. The domain is not required if the authentication type is set to WindowsIntegrated. When IsProxyRequired is set to True, to allow or prevent addresses without fully- 48

49 qualified domain names (FQDNs) from connecting to the proxy server, at the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name ProxyBypassLocalAddress -Value {$true $false} where <drive> is the name of the Windows PowerShell drive. When IsProxyRequired is set to True, to specify addresses that should not go through the proxy server, at the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name ProxyBypassFilter -Value <filter_string> where <drive> is the name of the Windows PowerShell drive. <filter_string> is a list of addresses that should not go through the proxy server. When IsProxyRequired is set to True, to require proxy authentication, at the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsProxyAuthenticationRequired -Value $true - ProxyAuthenticationScheme <authentication_type> -ProxyAuthenticationCredential [[<domain>\]<user_name>]] where <drive> is the name of the Windows PowerShell drive. <authentication_type> is the authentication type used to connect to the proxy server and must be one of the following: Basic, Digest, or WindowsIntegrated. <domain> and <user_name> are the domain and user name of the account used to authenticate to the proxy server. If you specify -ProxyAuthenticationCredential with the domain and user name, you are prompted for the password of the account. If you specify -ProxyAuthenticationCredential without the domain and user name on the command line, you are prompted for the domain, user name, and password. The domain is not required if the authentication type is set to WindowsIntegrated. When IsProxyAuthenticationRequired is set to True, to specify the authentication type, at the Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name ProxyAuthenticationScheme - Value <authentication_type> -ProxyAuthenticationCredential [[<domain>\]<user_name>]] where <drive> is the name of the Windows PowerShell drive. <authentication_type> is the authentication type used to connect to the proxy server and must be one of the following: Basic, Digest, or WindowsIntegrated. <domain> and <user_name> are the domain and user name of the account used to authenticate to the proxy server. If you specify -ProxyAuthenticationCredential with the domain and user name, you are prompted for the password of the account. If you specify -ProxyAuthenticationCredential without the domain and user name on the command line, you are prompted for the domain, user name, and password. The domain is not required if the authentication type is set to WindowsIntegrated. When IsProxyRequired is set to True, to no longer require a proxy server, at the 49

50 Windows PowerShell prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsProxyRequired -Value $false where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace Configuring AD RMS Cluster Properties Registering a Service Connection Point The service connection point (SCP) for Active Directory Rights Management Services (AD RMS) identifies the connection URL for the service to the AD RMS-enabled clients in your organization. After you register the SCP in Active Directory Domain Services (AD DS), clients will be able to discover the AD RMS cluster to request use licenses, publishing licenses, or rights account certificates (RACs). When the AD RMS role is configured on your server, the installation attempts to register the AD RMS SCP, but if it is unable to do so, you can register or change the SCP from the cluster Properties sheet in the Active Directory Rights Management Services console. If you are registering a service connection point (SCP) from an AD RMS cluster in a child domain, you might receive an error stating that SCP registration failed. In many cases, the registration was successful, but the registration first takes place in the top-level domain and it takes time to replicate to the child domain where the AD RMS cluster checks for the SCP object. As soon as the SCP has been replicated to all global catalog servers in the forest, the message will no longer appear. Membership in the AD RMS Enterprise Administrators and the Enterprise Admins group in AD DS, or equivalent, is the minimum required to complete this procedure. To register a service connection point At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name ScpUrl -Value <SCP_address> where <drive> is the name of the Windows PowerShell drive, and <SCP_address> is the address of the service connection point being registered. For example, if you have created a Windows PowerShell drive named Z:, to register the SCP as a secure sockets layer (SSL) URL for a server named rms.contoso.com, type: Set-ItemProperty -Path Z:\ -Name ScpUrl -Value 50

51 Understanding the AD RMS Administration Provider Namespace Configuring AD RMS Cluster Properties AD RMS Client Service Discovery Administering Certificates The tasks in this section are designed to help you manage rights account certificates (RACs) and the server licensor certificate (SLC) in your Active Directory Rights Management Services (AD RMS) environment. This section contains the following tasks: Specifying the Rights Account Certificate Validity Duration Changing the Server Licensor Certificate Name Exporting the Server Licensor Certificate Exporting the Server Licensor Certificate Server licensor certificates (SLCs) are exported to be used in establishing trusted publishing domains and trusted user domains. The SLC is also the default user domain certificate, and so the procedure to export the SLC is the same as the procedure to export the default user domain certificate. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To export the server licensor certificate to a file 1. To determine the name of the SLC, at the Windows PowerShell command prompt, type: Get-ItemProperty Path <drive>:\ -Name SvrLicCertFriendlyName where <drive> is the name of the Windows PowerShell drive. Note the name of the SLC under the Value heading. 2. To determine the ID of the SLC, at the Windows PowerShell command prompt, type: Get-ChildItem <drive>:\trustpolicy\trusteduserdomain where <drive> is the name of the Windows PowerShell drive. Note the ID of the item 51

52 whose display name matches the SLC name that you found in the previous step. 3. To export the SLC, at the Windows PowerShell command prompt, type: Export-RmsTud -Path <drive>:\trustpolicy\trusteduserdomain\<license_id> - SavedFile <file_path> where <drive> is the name of the Windows PowerShell drive, <license_id> is the ID of the SLC that you found in the previous step, and <file_path> is the fully qualified path of the file to which the SLC is being exported. For example, to export the SLC to C:\MySLC.bin on a server with an AD RMS administration drive named Z and with a default trusted user domain that has an ID of 100, type: Export-RmsTud -Path Z:\TrustPolicy\TrustedUserDomain\100 -SavedFile C:\MySLC.bin Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Administering Certificates Understanding AD RMS Certificates Specifying the Rights Account Certificate Validity Duration You can specify the validity periods for both standard and temporary rights account certificates (RACs) provided by Active Directory Rights Management Services (AD RMS). By default, a standard RAC is valid for 365 days and a temporary RAC is valid for 15 minutes. After the end of these periods, users must acquire new certificates when they attempt to acquire publishing or use licenses. The manner in which the RAC is renewed depends on the AD RMS-enabled application. In some cases, it may be transparent; in others, the user may need to actively submit a request. Note If you are using Active Directory Federation Services (AD FS) with AD RMS, the rights account certificate validity duration is specified as an identity federation support setting. For more information, see Configuring Federated Identity Support Settings. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To specify the Rights Account Certificate Validity Duration for standard certificates At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\issuancepolicy -Name 52

53 StandardCertValidityPeriodInDays <days> where <drive> is the name of the Windows PowerShell drive, and <days> is a number that specifies how many days the standard RAC will remain valid. To specify the Rights Account Certificate Validity Duration for temporary certificates At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\issuancepolicy -Name TemporaryCertValidityPeriodInMinutes <minutes> where <drive> is the name of the Windows PowerShell drive, and <minutes> is a number that specifies how many minutes the temporary RAC will remain valid. Understanding the AD RMS Administration Provider Namespace Administering Certificates Understanding AD RMS Certificates Changing the Server Licensor Certificate Name You can change the server licensor certificate (SLC) friendly name, the name of the SLC associated with this cluster. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To change the server licensor certificate name Set-ItemProperty -Path <drive>:\ -Name SvrLicCertFriendlyName -Value <name> where <drive> is the name of the Windows PowerShell drive, and <name> is the new SLC name. Understanding the AD RMS Administration Provider Namespace Administering Certificates Understanding AD RMS Certificates 53

54 Enabling Exclusion Policies The procedures in this section are designed to help you define exclusion policies on your Active Directory Rights Management Services (AD RMS) cluster. This section contains the following tasks: Excluding Users Excluding Applications Excluding Lockboxes Excluding Users If you suspect that a user s rights account certificate (RAC) has been compromised, you can exclude the RAC associated with that user account from obtaining use licenses from an Active Directory Rights Management Services (AD RMS) cluster. You can exclude the RAC by specifying either the user's address or the public key string of the RAC associated with the user's RAC. When you do this, AD RMS denies new use license requests that involve that RAC. After you exclude a RAC, the next time that user attempts to acquire a use license for new content, the request will be denied. To acquire a use license, the user will have to retrieve a new RAC with a new key pair. If you add a user or RAC to the exclusion list of the AD RMS root cluster, you should also exclude the user or RAC on all licensing-only clusters in your organization. Each AD RMS cluster has independent exclusion lists. Note To permanently exclude a user from obtaining use licenses, modify the discretionary access control list (DACL) of the AD RMS cluster user certification pipeline (%systemdrive%\inetpub\wwwroot\_wmcs\certification\certification.asmx) to deny all access by the user. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To enable user RAC exclusion At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\exclusionpolicy\user -Name IsEnabled -Value $true 54

55 To exclude a user s RAC Do one of the following: To exclude a user s RAC by specifying the user s address, at the Windows PowerShell command prompt, type: New-Item -Path <drive>:\exclusionpolicy\user -Name <user_name>@<domain> where <drive> is the name of the Windows PowerShell drive, <user_name> is the user name of the user whose RAC is being excluded, and <domain> is the domain portion of the address of the user whose RAC is being excluded. To exclude a user s RAC by specifying the user s RAC public key, at the Windows PowerShell command prompt, type: New-Item -Path <drive>:\exclusionpolicy\user -PublicKey <key> where <drive> is the name of the Windows PowerShell drive, and <key> is the user s RAC public key. To stop excluding a user s RAC 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\exclusionpolicy\user where <drive> is the name of the Windows PowerShell drive. Note the ID of the user whose RAC you want to stop excluding. 2. At the Windows PowerShell command prompt, type: Remove-Item -Path <drive>:\exclusionpolicy\user\<user_id> where <drive> is the name of the Windows PowerShell drive, and <user_id> is the ID of the user you found in the previous step. Understanding the AD RMS Administration Provider Namespace Enabling Exclusion Policies Understanding AD RMS Exclusion Policies Excluding Applications You can specify the version of an AD RMS-enabled application that all licensing requests are checked against. Application exclusion stamps every use license with a condition that the license can bind only to the rights-protected content for which it is issued if the application that is requesting the license is not on the excluded list. 55

56 This can be useful, for example, when an enterprise deploys an update for an AD RMS-enabled application. System administrators can use their usual mechanism to cause client computers to install the update. They can then set application exclusion policies that are defined by using the version information of the application. This exclusion policy restricts AD RMS from issuing licenses to clients that are running previous versions of the software. As with other types of exclusion, you must configure application exclusion on each cluster for which you want it to take effect. When you apply this exclusion policy on your cluster, clients cannot use the excluded application to request and bind new use licenses to rights-protected content. However, clients can continue to use the excluded application to consume previously licensed files. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To enable application exclusion At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\exclusionpolicy\application -Name IsEnabled -Value $true To exclude an application At the Windows PowerShell command prompt, type: New-Item -Path <drive>:\exclusionpolicy\application -Name <application_name> - MinVersion <min_number> -MaxVersion <max_number> where <drive> is the name of the Windows PowerShell drive, <application_name> is the name of the application being excluded, <min_number> is the lowest version number of the application to be excluded, and <max_number> is the highest version number of the application to be excluded. Both version numbers must be expressed as a series of four numbers separated by three period (.) characters, for example, If the application uses fewer numbers to indicate its version level, append.0 as many times as necessary to produce four periodseparated numbers. For example, if you have created a Windows PowerShell drive named Z and want to exclude all versions of an application named viewer.exe prior to version 8, at the Windows PowerShell command prompt, type: New-Item -Path Z:\ExclusionPolicy\Application -Name viewer.exe -MinVersion MaxVersion To stop excluding an application 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\exclusionpolicy\application 56

57 where <drive> is the name of the Windows PowerShell drive. Note the ID of the application you want to stop excluding. 2. At the Windows PowerShell command prompt, type: Remove-Item -Path <drive>:\exclusionpolicy\application\<application_id> where <drive> is the name of the Windows PowerShell drive, and <application_id> is the ID of the application you found in the previous step. Understanding the AD RMS Administration Provider Namespace Enabling Exclusion Policies Understanding AD RMS Exclusion Policies Excluding Lockboxes Lockboxes are used to store a user's private key. If a vulnerability is found in a certain version of a lockbox, a new lockbox is released by Microsoft. You can ensure that clients use a minimum version of the Active Directory Rights Management Services (AD RMS) client software by using the lockbox version associated with the client to exclude the previous versions of the AD RMS client software. When you enable this feature, you specify the latest minimum lockbox version that was signed by the Microsoft Activation Service. You then enable lockbox exclusion on the each AD RMS cluster on which you want it to take effect. All certification and licensing requests are checked to make sure that the lockbox meets the minimum version criteria. If you have enabled an exclusion based on lockbox version, clients that are using a version of the lockbox software earlier than the specified version cannot acquire rights account certificates (RACs) or use licenses because their requests will be denied. These clients must install a new version of the AD RMS client software to acquire a new lockbox that uses the current version of the software. If a user who has an excluded lockbox was previously issued licenses for content, the user can still consume that content without acquiring a new lockbox. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To enable lockbox exclusion At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\exclusionpolicy\lockbox -Name IsEnabled -Value $true 57

58 To exclude lockbox versions At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\exclusionpolicy\lockbox -Name LockboxMinimumVersion -Value <version_number> where <drive> is the name of the Windows PowerShell drive and <version_number> is the lowest version number of the lockbox to be supported. The version number must be expressed as a series of four numbers separated by three period (.) characters, for example, Understanding the AD RMS Administration Provider Namespace Enabling Exclusion Policies Understanding AD RMS Exclusion Policies Establishing Trust Policies The tasks in this section are designed to help you establish a trust relationship between your Active Directory Rights Management Services (AD RMS) cluster and an AD RMS cluster in another domain or that is part of a different organization. This section contains the following tasks: Configuring Federated Identity Support Settings Adding a Trusted User Domain Exporting a Trusted User Domain Adding a Trusted Publishing Domain Exporting a Trusted Publishing Domain Using Windows Live ID to Establish RACs for Users Configuring Microsoft Federation Gateway Support 58

59 Configuring Federated Identity Support Settings Once enabled and configured, federated identity support allows user accounts to use credentials established by a federated trust relationship through Active Directory Federation Services (AD FS) as a basis for obtaining a rights account certificate (RAC) from an Active Directory Rights Management Services (AD RMS) cluster. This is an alternative to setting up trusted publishing domains or trusted user domains between entities that have previously established trust infrastructures, such that in most cases the cluster is supporting both users that are inside of the organization and users from a partner organization. When rights account certificates (RACs) are issued from a federated identity, the standard rights account certificate validity period does not apply. Instead, the RAC validity period is specified in the CertificateValidityPeriod property of the \TrustPolicy\FederatedIdentitySupport container. Users with federated identities do not use temporary rights account certificates. By default, federated trust relationships are not transitive. When a federated trust relationship is established between two organizations, any AD RMS trusted user domains that are established in either organization are not automatically trusted by the other organization. However, when you are importing a trusted user domain, there is an option to trust federated users of the imported domain. Great care should be taken when allowing proxy addresses through a federated trust. If proxy addresses through federation are allowed, it is possible for a malicious user to spoof an authorized user's credentials and access the user's rights-protected content. If proxy addresses through federation is a requirement of your organization, you should implement a claims transformation module that will examine a proxy address from a federated user and make sure that it matches the forest in which the request originated. The option to allow a proxy address from a federated user is turned off by default. Note Before you can enable and configure federated identity support, you must first add the support to the AD RMS cluster configuration. For more information, see Adding or Removing Federated Identity Support. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To enable and configure federated identity support settings 1. To enable federated identity support, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\federatedidentitysupport -Name IsEnabled $true where <drive> is the name of the Windows PowerShell drive. 2. To set the federated identity certificate validity period, at the Windows PowerShell 59

60 command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\federatedidentitysupport -Name CertificateValidityPeriodInDays -Value <number_days> where <drive> is the name of the Windows PowerShell drive and <number_days> is the number of days that federated rights account certificates will remain valid. 3. To set the federated identity certificate service URL, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\ FederatedIdentitySupport -Name CertificateServiceUrl -Value <certservice_url> where <drive> is the name of the Windows PowerShell drive and <certservice_url> is the address of the of certificate service on the root cluster that will provide RACs to external users. For example, for a Windows PowerShell drive named Z, to set the federated identity certificate service URL to point to a server named external.contoso.com, type: Set-ItemProperty -Path Z:\TrustPolicy\FederatedIdentitySupport -Name CertificateServiceUrl -Value 4. To allow proxy addresses to consume rights-protected content, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\federatedidentitysupport -Name IsProxy AddressAllowed -Value $true where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace Establishing Trust Policies Understanding AD RMS Trust Policies Configuring AD RMS Across Forests Adding a Trusted User Domain By default, Active Directory Rights Management Services (AD RMS) does not service requests from users whose rights account certificate (RAC) was issued by a different AD RMS installation. However, you can add user domains to the list of trusted user domains (TUDs), which allows AD RMS to process such requests. For each trusted user domain (TUD), you can also add and remove specific users or groups of users. In addition, you can remove a TUD; however, you cannot remove the root cluster for this Active Directory forest from the list of TUDs. Every AD RMS server trusts the root cluster in its own forest. 60

61 You can add TUDs as follows: To support external users in general, you can trust Windows Live ID. This allows an AD RMS cluster that is in your company to process licensing requests that include a RAC that was issued by Microsoft s online RMS service. For more information about trusting Windows Live ID in your organization, see Using Windows Live ID to Establish RACs for Users. To trust external users from another organization s AD RMS installation, you can add the organization to the list of TUDs. This allows an AD RMS cluster to process a licensing request that includes a RAC that was issued by an AD RMS server in the other organization. In the same manner, to process licensing requests from users within your own organization who reside in a different Active Directory forest, you can add the AD RMS installation in that forest to the list of TUDs. This allows an AD RMS cluster in the current forest to process a licensing request that includes a RAC that was issued by an AD RMS cluster in the other forest. For each TUD, you can specify which domains, including their child domains, are trusted. For trusted Windows Live ID sites and services, you can specify which users or domains are not trusted. Before you can add a trusted user domain, the server licensor certificate (SLC) of the domain to be trusted must be exported to a file. For more information, see Exporting a Trusted User Domain. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To add a trusted user domain At the Windows PowerShell command prompt, type: Import-RmsTUD -Path <drive>:\trustpolicy\trusteduserdomain -DisplayName <name> -SourceFile <file_path> [-TrustADFederatedUser] where <drive> is the name of the Windows PowerShell drive, <name> is a name to identify this trusted user domain, and <file_path> is the path to the exported server licensor certificate of the user domain to trust. Specify -TrustADFederatedUser to extend this trust to federated users. To specify properties of the trusted user domain 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\trustpolicy\trusteduserdomain where <drive> is the name of the Windows PowerShell drive. Note the ID of the TUD you want to modify. 2. To specify which domains within the trusted user domain are trusted, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> -Name Trusted Domain -Value <domain>[,<domain> ] where <drive> is the name of the Windows PowerShell drive, <TUD_ID> is the ID of the 61

62 TUD you found in the previous step, and <domain> is the domain you want to trust. You can specify more than one domain as a comma-separated list. For example, for a Windows PowerShell drive named Z, to configure the TUD with the ID of 101 to trust the domains fabrikam.com and fabrikam.net, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name Trusted Domain -Value fabrikam.com, fabrikam.net 3. To issue licenses to Active Directory Domain Services (AD DS) security identifiers (SIDs) rather than using just the address attribute in AD DS, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> -Name IsLicensingToSIDEnabled -Value $true where <drive> is the name of the Windows PowerShell drive, and <TUD_ID> is the ID of the TUD you found in the first step. To remove a trusted user domain 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\trustpolicy\trusteduserdomain where <drive> is the name of the Windows PowerShell drive. Note the ID of the TUD you want to remove. 2. To remove the trusted user domain, at the Windows PowerShell command prompt, type: Remove-Item -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> where <drive> is the name of the Windows PowerShell drive, and <TUD_ID> is the ID of the TUD you are removing. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Establishing Trust Policies Understanding AD RMS Trust Policies Exporting a Trusted User Domain Trusted user domains (TUDs) enable an Active Directory Rights Management Services (AD RMS) cluster to provide licenses to users whose rights account certificate (RAC) was granted by another server in an AD RMS cluster. Exporting a TUD and importing it into another AD RMS 62

63 cluster allows the cluster to process requests for use licenses from users whose RACs are in a different cluster. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To export a trusted user domain At the Windows PowerShell command prompt, type: Export-RmsTUD -Path <drive>:\trustpolicy\trusteduserdomain -SavedFile <file_path> where <drive> is the name of the Windows PowerShell drive, and <file_path> is the path of the file to receive the exported TUD certificate. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Establishing Trust Policies Adding a Trusted User Domain Understanding AD RMS Trust Policies Adding a Trusted Publishing Domain By default, servers in an Active Directory Rights Management Services (AD RMS) cluster can issue use licenses only against the publishing licenses that it, or another server in its cluster, issued. If you have content that was published by using another AD RMS root cluster either in your organization, for example a subsidiary organization in another forest, or in another, separate organization, your AD RMS cluster can grant use licenses to users for this content if you configure a trusted publishing domain (TPD). By adding a TPD, you set up a trust relationship between your AD RMS cluster and the other root cluster by importing the server licensor certificate (SLC) of the other cluster. There is no limit to the number of TPDs that you can configure for your AD RMS cluster. If the cluster key is stored in a CSP, you must transfer the cluster key to the CSP key container on each trusted server in the cluster by following the instructions in the CSP manufacturer's documentation. Depending on the type of CSP on each server and the configuration of any hardware security module devices, you might not be able to transfer the cluster key from one hardware security module to another. If you are using a CSP with a hardware security module (HSM), review the hardware security module documentation to determine whether you can transfer the cluster key without losing data that is in the destination hardware security module. If 63

64 you cannot successfully transfer the cluster key, you cannot establish a trusted publishing domain. Note If you are using a hardware-based CSP, also known as a hardware security module (HSM), to protect your AD RMS cluster key and you are importing an SLC from an AD RMS installation that internally manages the AD RMS cluster key, you must specify a cluster key password for the cluster before you attempt to import the certificate. This procedure assumes that you have exported the TPD of another AD RMS cluster. For more information about exporting the TPD, see Exporting a Trusted Publishing Domain. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To add a trusted publishing domain 1. To securely store the cluster key password in a variable, at the Windows PowerShell command prompt, type: $password = Read-Host -AsSecureString -Prompt Password: 2. Type the cluster key password, and then press the ENTER key. 3. At the Windows PowerShell command prompt, type: Import-RmsTPD -Path <drive>:\trustpolicy\trustedpublishingdomain -DisplayName <name> -FileFullPath <file_path> -Password $password where <drive> is the name of the Windows PowerShell drive, <name> is a name to identify this trusted user domain, and <file_name> is the path of the file containing the TPD being imported. To remove a trusted publishing domain 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\trustpolicy\trustedpublishingdomain where <drive> is the name of the Windows PowerShell drive. Note the ID of the TPD you want to remove. 2. To remove the trusted publishing domain, at the Windows PowerShell command prompt, type: Remove-Item -Path <drive>:\trustpolicy\trustedpublishingdomain\<tpd_id> where <drive> is the name of the Windows PowerShell drive and <TPD_ID> is the ID of the TPD you are removing. Understanding the AD RMS Administration Provider Namespace 64

65 AD RMS Administration Cmdlets Establishing Trust Policies Exporting a Trusted Publishing Domain Understanding AD RMS Trust Policies Exporting a Trusted Publishing Domain Use the following procedure to export a trusted publishing domain (TPD) to a file. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To export a trusted publishing domain 1. To securely store the cluster key password in a variable, at the Windows PowerShell command prompt, type: $password = Read-Host -AsSecureString -Prompt Password: 2. Type the cluster key password, and then press the ENTER key. 3. At the Windows PowerShell command prompt, type: Export-RmsTPD -Path <drive>:\trustpolicy\trustedpublishingdomain - SavedFile <file_path> -Password $password [-V1Compatible] where <drive> is the name of the Windows PowerShell drive, and <file_name> is the path of the file to receive the TPD being exported. If this trusted publishing domain file will be imported into versions of Windows Rights Management Services (RMS) running on Windows Server 2003, specify -V1Compatible. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Establishing Trust Policies Adding a Trusted Publishing Domain Understanding AD RMS Trust Policies 65

66 Using Windows Live ID to Establish RACs for Users Microsoft provides an account certification service that uses Windows Live ID to establish the rights account certificate (RAC) for the user. If you want users with RACs from that service to be able to obtain use licenses from an Active Directory Rights Management Services (AD RMS) cluster, you need to set up a trusted user domain that accepts user credentials from Microsoft s online RMS service. Important To use this feature, you must configure Internet Information Services (IIS) to allow access to the AD RMS licensing service, for example, by allowing anonymous access. This step is essential because the licensing service is configured to use Windows Integrated authentication by default. If IIS is not configured to allow access to the AD RMS licensing service, users with Windows Live ID-based RACs will not be able to acquire licenses. If necessary, after support for Windows Live ID is configured, you can exclude users of this service based on their address domains. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. To trust Windows Live ID-based rights account certificates At the Windows PowerShell command prompt, type: Import-RmsTUD -Path <drive>:\trustpolicy\trusteduserdomain -WindowsLiveId where <drive> is the name of the Windows PowerShell drive. To specify Windows Live ID domains to exclude 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\trustpolicy\trusteduserdomain where <drive> is the name of the Windows PowerShell drive. Note the ID of the Windows Live ID TUD you want to modify. 2. To specify which domains within the trusted user domain are trusted, at the Windows PowerShell command prompt, do one of the following: If Service Pack 1 (SP1) for Windows Server 2008 R2 is not installed, type: Set-ItemProperty -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> -Name ExcludedWindowsLiveID -Value <domain>[,<domain> ] where <drive> is the name of the Windows PowerShell drive, <TUD_ID> is the ID of the TUD you found in the previous step, and <domain> is the domain you want to exclude. You can specify more than one domain as a comma-separated list. For example, for a Windows PowerShell drive named Z, to configure the Windows 66

67 Live ID TUD with the ID of 101 to exclude the domains fabrikam.com and fabrikam.net, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name ExcludedWindowsLiveID -Value fabrikam.com, fabrikam.net If SP1 for Windows Server 2008 R2 is installed, type: Set-ItemProperty -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> -Name WindowsLiveIDFilteringMode Value {Allow Block} Set-ItemProperty -Path <drive>:\trustpolicy\trusteduserdomain\<tud_id> -Name WindowsLiveIdFilterList -Value <domain>[,<domain> ] where <drive> is the name of the Windows PowerShell drive, <TUD_ID> is the ID of the TUD you found in the previous step, and <domain> is the domain you want to allow or block. You can specify more than one domain as a comma-separated list. For example, for a Windows PowerShell drive named Z, to configure the Windows Live ID TUD with the ID of 101 to exclude the domains fabrikam.com and fabrikam.net, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name WindowsLiveIDFilteringMOde -Value Block Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name WindowsLiveIDFilterlist -Value fabrikam.com, fabrikam.net You can also configure the Windows Live ID TUD to allow only specified domains. For example, for a Windows PowerShell drive named Z, to configure the Windows Live ID TUD with the ID of 101 to allow only the domains fabrikam.com and fabrikam.net, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name WindowsLiveIDFilteringMOde -Value Allow Set-ItemProperty -Path Z:\TrustPolicy\TrustedUserDomain\101 -Name WindowsLiveIDFilterlist -Value fabrikam.com, fabrikam.net Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Establishing Trust Policies Understanding AD RMS Trust Policies 67

68 Configuring Microsoft Federation Gateway Support The tasks in this section are designed to help you configure Microsoft Federation Gateway Support on your Active Directory Rights Management Services (AD RMS) cluster. This section contains the following tasks: Updating a Microsoft Federation Gateway Support Certificate Granting the AD RMS Service Group Permission to the SSL Certificate Setting the Microsoft Federation Gateway RAC Validity Period Managing the Microsoft Federation Gateway Licensing Filter List Managing the Microsoft Federation Gateway Publishing Filter List Terminating the Federation Relationship Removing Microsoft Federation Gateway Support Updating a Microsoft Federation Gateway Support Certificate You can update the token decryption certificate or the Microsoft Federation Gateway certificate, as needed. Because the token decryption certificate is the SSL certificate for the Active Directory Rights Management Services (AD RMS) cluster, you must update the token decryption certificate if the cluster SSL certificate expires. After you update the token decryption certificate, you must grant the AD RMS Services group permission to access the certificate on all servers in the AD RMS cluster. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. To update the token decryption certificate 1. Do one of the following: To update the token decryption certificate using the default AD RMS cluster certificate, at the Windows PowerShell command prompt, type: Update-RmsMfgEnrollment -TokenCert To update the token decryption certificate by using a different certificate, at the Windows PowerShell command prompt, type: Update-RmsMfgEnrollment -TokenCert -CertificateThumbprint <thumbprint> where <thumbprint> is a string containing the thumbprint hash of the certificate being used to enroll with the Microsoft Federation Gateway. Important 68

69 If you use a certificate that contains a subject alternate name (SAN), the last entry in the SAN list must be the fully qualified domain name of the domain you want to enroll with the Microsoft Federation Gateway. 2. On all servers in the AD RMS cluster, perform the task described in Granting the AD RMS Service Group Permission to the SSL Certificate. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. To update the Microsoft Federation Gateway certificate At the Windows PowerShell command prompt, type: Update-RmsMfgEnrollment -SigningCert Understanding the AD RMS Administration Provider Namespace Configuring Microsoft Federation Gateway Support Enrolling with the Microsoft Federation Gateway Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Granting the AD RMS Service Group Permission to the SSL Certificate After enrolling the cluster with the Microsoft Federation Gateway or updating the token decryption certificate, you must grant the AD RMS Services group permission to access the token decryption certificate on all servers in the cluster. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To grant permission to the AD RMS Services group for the SSL certificate At the Windows PowerShell command prompt, type: Update-RmsMfgEnrollment -SetCertificatePermissions Configuring Microsoft Federation Gateway Support 69

70 Installing Microsoft Federation Gateway Support Updating a Microsoft Federation Gateway Support Certificate Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Setting the Microsoft Federation Gateway RAC Validity Period You can configure how long the Microsoft Federation Gateway rights account certificate (RAC) remains valid. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To set the Microsoft Federation Gateway RAC validity period At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name CertificateValidityPeriodInDays <days> where <drive> is the name of the Windows PowerShell drive, and <days> is an integer specifying the number of days the Microsoft Federation Gateway RAC remains valid. Understanding the AD RMS Administration Provider Namespace Configuring Microsoft Federation Gateway Support Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Managing the Microsoft Federation Gateway Licensing Filter List You can control the federated domains that the Active Directory Rights Management Services (AD RMS) cluster will provide licenses to for consuming protected content. You can do this either by specifying the users and domains that can receive licenses, or by specifying the users and domains that will be blocked from receiving licenses. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. 70

71 To allow or block domains for licensing 1. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name LicensingDomainFilterList -Value where<drive> is the name of the Windows PowerShell drive, <user> is the alias of a user who will be allowed to or blocked from receiving licenses, and <domain> is the name of a domain containing the users who will be allowed to or blocked from receiving licenses. Separate list entries by using a comma (,). If you specify a domain name without a user name, all users in the specified domain will be allowed to or blocked form receiving licenses, depending on which option you specify in the next step. Use an asterisk (*) to specify all users in all domains. 2. Do one of the following: To specify that the listed users and domains are allowed to receive licenses, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name LicensingDomainFilteringMode -Value Allow To specify that the listed users and domains are not allowed to receive licenses, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name LicensingDomainFilteringMode -Value Block Understanding the AD RMS Administration Provider Namespace Configuring Microsoft Federation Gateway Support Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Managing the Microsoft Federation Gateway Publishing Filter List You can control the federated domains that the Active Directory Rights Management Services (AD RMS) cluster will provide licenses to for publishing protected content by specifying the domains that will be allowed to receive publishing licenses. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. 71

72 To allow domains for publishing At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\trustpolicy\microsoftfederationgateway -Name PublishingDomainFilterList -Value <domain>[,<domain>]... where<drive> is the name of the Windows PowerShell drive and <domain> is the name of a domain whose users will be allowed to publish protected content. Separate list entries by using a comma (,). Use an asterisk (*) to specify all domains. Understanding the AD RMS Administration Provider Namespace Configuring Microsoft Federation Gateway Support Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Terminating the Federation Relationship When the Active Directory Rights Management Services (AD RMS) cluster is enrolled with the Microsoft Federation Gateway, you can stop the enrollment without disabling Microsoft Federation Gateway Support. You can enroll again with the Microsoft Federation Gateway later. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. To terminate the federation relationship At the Windows PowerShell command prompt, type: Uninstall-RmsMfgEnrollment Configuring Microsoft Federation Gateway Support Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway 72

73 Removing Microsoft Federation Gateway Support If you no longer want to use Microsoft Federation Gateway Support in Active Directory Rights Management Services (AD RMS), you can remove Microsoft Federation Gateway Support from your AD RMS cluster Caution Before uninstalling Service Pack 1 for Windows Server 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. To remove Microsoft Federation Gateway Support 1. At the Windows PowerShell command prompt, type: Uninstall-RmsMfgSupport Configuring Microsoft Federation Gateway Support Understanding AD RMS Trust Policies Understanding the Microsoft Federation Gateway Managing AD RMS Databases Servers in an Active Directory Rights Management Services (AD RMS) cluster are tightly integrated with the database server during normal operations. The AD RMS database server stores configuration, logging, and directory services information for use by AD RMS. This section contains the following task: Turning on or Turning off Logging 73

74 Turning on or Turning off Logging AD RMS logs are sent to the database server by Message Queuing. If a connection to the database server is not present, Message Queuing stores the logs in a local cache until connectivity is restored. The first time you enable logging, you should make sure that the AD RMS server has a connection to the database server, and that the database service is started. If Message Queuing cannot deliver the logs to the logging database, it keeps the data in a queue on the hard disk of the AD RMS server. It continues to do this until all of the storage space on the server is full. When no disk space is left on the server, Message Queuing will stop. AD RMS does not display an error in this condition because the feature is meant to support logging during times when the connection to the database server is interrupted. Turning off logging stops the Active Directory Rights Management Services (AD RMS) Web services from sending data to the logging message queue. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To turn on logging At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsLoggingEnabled -Value $true where <drive> is the name of the Windows PowerShell drive. To turn off logging At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsLoggingEnabled -Value $false where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace Understanding the AD RMS Databases Configuring Accounts This section contains tasks for managing the accounts that are used for the operation and maintenance of an Active Directory Rights Management Services (AD RMS) cluster. This section contains the following tasks: Setting up a Super Users Group 74

75 Resetting the AD RMS Cluster Key Password Changing the AD RMS Service Account Specifying the Administrative Contact Setting up a Super Users Group The Active Directory Rights Management Services (AD RMS) super users group is a special group that has full control over all rights-protected content managed by the cluster. Its members are granted full owner rights in all use licenses that are issued by the AD RMS cluster on which the super users group is configured. This means that members of this group can decrypt any rights-protected content file and remove rights-protection from it. The super users group is not enabled and is not assigned a group by default. When you set the IsEnabled property of the \SecurityPolicy\SuperUser container, you must also specify an Active Directory Domain Services (AD DS) universal group to use as the super users group for AD RMS. The group must exist in the same forest as the AD RMS installation. Any user accounts that are members of the group that you specify as the AD RMS super users group are automatically granted the permissions of the super users group. Caution Enabling the super users group should be done only on an as-needed basis. During normal operations, the super users group should be disabled, unless it is used to provide a trusted application with the ability to decrypt rights-protected content, such as to enable the application to scan the content for malware. It should be enabled only when necessary. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To set up a super users group At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\securitypolicy\superuser -Name IsEnabled -Value $true Set-ItemProperty -Path <drive>:\securitypolicy\superuser -Name SuperUserGroup - Value <group_ > where <drive> is the name of the Windows PowerShell drive, and <group_ > is the address of the universal group being designated as the AD RMS super users group. 75

76 For example, for a Windows PowerShell drive named Z, to designate a group named SecurityAdmins at fabrikam.com as the AD RMS super user group, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path Z:\SecurityPolicy\SuperUser -Name IsEnabled -Value $true Set-ItemProperty -Path Z:\SecurityPolicy\SuperUser -Name SuperUserGroup -Value [email protected] The super users group should remain enabled only when its use is required and should be disabled as soon as possible. To disable the super users group At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\securitypolicy\superuser -Name IsEnabled -Value $false where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace Configuring Accounts Understanding AD RMS User Accounts Understanding AD RMS User Accounts Resetting the AD RMS Cluster Key Password When a new Active Directory Rights Management Services (AD RMS) cluster is provisioned, you choose a method to protect the AD RMS cluster key. If you choose the default option of using AD RMS cluster key protection, you specify a strong password that was used to encrypt the cluster key in the configuration database. The AD RMS cluster key is used to sign the certificates and licenses granted by the cluster. The cluster key is generated, and the password is specified during the initial configuration of the AD RMS server role. If you are running AD RMS in a clustered environment, and you decided to reset the cluster key, you must reset it on every AD RMS server in the cluster. If you do not, those servers will not be able function as they will be unable to decrypt the cluster key in the configuration database. Important This procedure applies only if you are using AD RMS to centrally manage the cluster key. If you are using either a hardware-based or software-based cryptographic service provider (CSP), consult the documentation of the CSP manufacturer. 76

77 Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, you must be a member of the System Administrators database role, or equivalent, on the database server. To reset the cluster key password 1. To store the password in a variable as a secure string, at the Windows PowerShell command prompt, type: $password = Read-Host -AsSecureString 2. Type the new cluster key password. 3. To reset the cluster key password, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\securitypolicy\clusterkeypassword -Name PasswordForCentrallyManagedKey -Value $password 4. At the prompt, type the confirmed password. 5. Repeat the preceding steps on each AD RMS server in the cluster. Understanding the AD RMS Administration Provider Namespace Configuring Accounts Changing the AD RMS Service Account During installation, Active Directory Rights Management Services (AD RMS) creates the AD RMS Service Group on the local computer and grants it appropriate permissions on all of the resources that are required for AD RMS to operate. When you provision AD RMS on a server, you must define a domain account for use as the AD RMS service account. That account is made a member of the AD RMS Service Group, and it is granted the permissions that are associated with this group. During routine operations, AD RMS runs under the AD RMS service account. You can change the AD RMS service account at any time. When you do so, the previously specified account is automatically removed from the AD RMS Service Group, and the new account is made a member of it. If there is more than one server in the AD RMS cluster where you are changing the AD RMS service account, you must change the service account on all servers in the cluster. Important For security reasons, we highly recommend that you create a special user account to use as the AD RMS service account, and that you use this account only as the AD RMS 77

78 service account and for no other purpose. In addition, you should not grant this account any additional permissions. Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure. Also, this procedure can only be performed on the local computer; it cannot be performed remotely. To change the AD RMS Service Account 1. At the Windows PowerShell command prompt, type: Set-RmsSvcAccount -Path <drive>:\ where <drive> is the name of the Windows PowerShell drive. 2. In the dialog box that appears, type the user name (in <domain>\<user> format) and password of the new service account. To view the AD RMS Service Account At the Windows PowerShell command prompt, type: Get-RmsSvcAccount -Path <drive>:\ where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Configuring Accounts Understanding AD RMS User Accounts Specifying the Administrative Contact The administrative contact is the person or group of persons in your organization that can assist a user in resolving issues with Active Directory Rights Management Services (AD RMS). Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To specify the administrative contact At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name AdministrativeContact -Value <contact_ > where <drive> is the name of the Windows PowerShell drive, and <contact_ > is the 78

79 address of the administrator to contact. Understanding the AD RMS Administration Provider Namespace Configuring Accounts Understanding AD RMS User Accounts Configuring Rights Policy Templates You can create rights policy templates by using Windows PowerShell cmdlets to add items to the \RightsPolicyTemplate container in the Active Directory Rights Management Services (AD RMS) administration namespace in Windows PowerShell. You then configure the templates by setting properties on these items and delete existing templates by removing them from the \RightsPolicyTemplate container. The items in this container are logical representations of the actual templates, which are stored in the configuration database and in an optional shared folder for distribution. This section contains the following tasks: Specifying the Location of Rights Policy Templates Creating a New Rights Policy Template Editing a Rights Policy Template Viewing a Summary of User Rights for a Rights Policy Template Archiving a Rights Policy Template Deleting a Rights Policy Template Adding a New Language to a Rights Policy Template Restoring a Rights Policy Template Copying a Rights Policy Template Specifying the Location of Rights Policy Templates With Windows Server 2008 or Windows Server 2008 R2, Active Directory Rights Management Services (AD RMS) clients can automatically obtain rights policy templates from an AD RMS cluster and keep them up-to-date through an automated scheduled task. For more information about creating this scheduled task, see AD RMS Rights Policy Templates Deployment Step-by- Step Guide. However, you may need to continue exporting templates to a folder in order to distribute them manually to clients not running Windows Server 2008 or Windows 79

80 Server 2008 R2. The location you specify by using the following procedure creates a point from which you can distribute the templates to client computers. Note Only distributed rights policy templates are stored in the shared folder. If you are using archived rights policy templates, you must change them to distributed rights policy templates before they can appear in the shared folder. If you are using Microsoft Office 2003 or later as your AD RMS-enabled application, the location where Microsoft Office applications look for the rights policy templates is controlled by the AdminTemplatePath registry key. This registry entry should be configured to point to a local folder where the rights policy templates are stored. For more information about deploying rights policy templates, see AD RMS Rights Policy Templates Deployment Step-by-Step Guide. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To specify the location of rights policy templates 1. Create a shared folder that can be accessed by the AD RMS cluster and AD RMS clients. 2. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\rightspolicytemplate -Name PublishUNCFilePath - Value <UNC_path> where <drive> is the name of the Windows PowerShell drive, and <UNC_path> is the location of the shared folder created in the previous step. The path must be specified in the form \\<server_name>\<share_name>. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Creating a New Rights Policy Template When you create a new Active Directory Rights Management Services (AD RMS) rights policy template by using Windows PowerShell cmdlets, you can specify the template settings, or you can create a blank template. In either case, you can subsequently use Windows PowerShell cmdlets or the AD RMS console to modify the contents of the template. 80

81 The following procedure creates a mostly empty rights policy template that you can modify later to add settings. For more information about modifying an existing rights policy template, see Editing a Rights Policy Template. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. To create a new rights policy template to be modified later At the Windows PowerShell command prompt, type: New-Item -Path <drive>:\rightspolicytemplate -LocaleName <locale_names> - DisplayName <display_names> -Description <descriptions> where <drive> is the name of the Windows PowerShell drive, and where <locale_names>, <display_names>, and <descriptions> are the strings required by their respective parameters. For more information about the meaning and format of these strings, see the table later in this topic. The following procedure creates a rights policy template with initial settings that can be supplemented by modifying the template after it has been created. For more information about modifying an existing rights policy template, see Editing a Rights Policy Template. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. To create a new rights policy template with initial settings At the Windows PowerShell command prompt, type: New-Item -Path <drive>:\rightspolicytemplate -LocaleName <locale_names> - DisplayName <display_names> -Description <descriptions> [-UserGroup <user_list> [- Right <standard_rights>] [-CustomRight <custom_rights>]] [-RightsRequestUrl <url>] [- ContentExpiredOnDateInDaysOrNever <expiration>] [-UserLicenseRenewalInDays <days>] [- ArchivedTemplate] [-EnableViewInTrustedBrowser] [-EnableOnetimeLicense] [- ExtendedAppName <pair_names> -ExtendedAppValue <pair_values>] [- RevocationLocation <list_url> -RevocationRefreshPerDays <days> - RevocationPublicKeyFilePath <path>] where <drive> is the name of the Windows PowerShell drive. For more information about the meaning and format of other parameter values, see the table later in this topic. To create a rights policy template, you use the New-Item cmdlet to create an item in the \RightsPolicyTemplate container in the AD RMS administration namespace in Windows PowerShell. When the path of this cmdlet is set to the \RightsPolicyTemplate container, it supports dynamic parameters that allow you to specify settings for the new rights policy template. The following table lists the parameters that you can use to specify settings when creating a rights policy template. 81

82 Dynamic Parameter Description Usage -LocaleName -DisplayName -Description Required parameter that specifies one or more locales for the template. Required parameter that specifies a name to be shown to users for each template locale provided with the -LocaleName parameter. Typically, this name describes the purpose of the template (such as Read-Only ) in the language corresponding to the locale. Required parameter that specifies a description of the template for each locale provided with the -LocaleName parameter. Typically, this description explains the purpose of the template (such as Allows users to read, but not change, protected content ) in For each locale represented in the template, specify a two-part locale code consisting of a twoletter language code and a two-letter country/region code. For example, to specify United States English, use en-us, and to specify Canadian French, use fr-ca. For each locale you specify, you must also specify a corresponding display name and description. You must specify at least one locale. For each locale, specify a name for the template in quotation marks, separating each name with a comma. For each locale, specify a description of the template in quotation marks, separating each description with a comma. 82

83 Dynamic Parameter Description Usage the language corresponding to the locale. -UserGroup -Right -CustomRight Optional parameter that specifies the users or groups who are granted rights by the template. Optional parameter that specifies the standard rights to be granted by the template for each user or group. This parameter is required if the - UserGroup parameter is specified. Optional parameter that specifies custom rights to be granted by the template for each user or group. For each user or group to be granted rights by the template, specify the address of the user or group, separated by a comma. You can also specify the keyword ANYONE to designate all users. For each user or group specified with the -UserGroup parameter, specify a list of one or more rights. Each list must be contained within parentheses, and each right must be contained within single quotation marks ( ) and separated by a comma (,). Multiple lists are separated by commas. For example, to specify View and Print rights for two users or groups, provide this list: ( View, Print ),( View, Print ) Standard rights consist of the following: View, Extract, AllowMacros, ViewRightsData, Print, Forward, Reply, ReplyAll, Export, Save, Edit, EditRightsData, and FullControl. For each user or group specified with the -UserGroup parameter, specify a list of one or more custom rights using the same format as for the - Rights parameter. RightsRequestUrl Optional parameter Specify a URL in the standard 83

84 Dynamic Parameter Description Usage that specifies the URL from which users can request additional rights to rights-protected content. format. - ContentExpiredOnDateInDaysOrNeve r -UserLicenseRenewalInDays -ArchivedTemplate Optional parameter that specifies when content expires. Optional parameter that specifies when the use license expires. Optional parameter that specifies whether the template is archived or distributed. A distributed rights policy template allows users to publish and consume rights-protected content, and an archived rights policy template only allows consumption once the rights policy template has been Specify one of the following: NEVER to indicate that content protected by the template never expires A single number (such as 31) to indicate the number of days to elapse before the content expires A date (such as 01/31/2011) indicating when the content expires at midnight, Coordinated Universal Time (UCT), also known as Greenwich Mean Time. Specify a number indicating the number of days the use license will remain valid. Specify the - ArchivedTemplate parameter to designate an archived template. If you do not specify this parameter, the template will be distributed. 84

85 Dynamic Parameter Description Usage removed from the client computer. -EnableViewInTrustedBrowser -EnableOnetimeLicense -ExtendedAppName -ExtendedAppValue -RevocationLocation Optional parameter that specifies whether a user who does not have an AD RMS-enabled application installed can view rightsprotected content protected by this template. Optional parameter that requires users to re-authenticate with AD RMS each time the rights-protected content is consumed. Optional parameter that specifies the names of one or more applicationspecific data pairs. Optional parameter that specifies the values of one or more applicationspecific data pairs. This parameter is required if you specify the - ExtendedAppName parameter. Optional parameter that enables revocation and specifies the URL Specify the - EnableViewInTrustedBrowse r parameter to allow users to view protected content by using a Web browser. If you do not specify this parameter, users will be required to use an AD RMS-enabled application to use content protected by this template. Specify the - EnableOnetimeLicense parameter to require users to re-authenticate. If you do not specify this parameter, users will not be required to reauthenticate each time they access the content. Specify one or more names as a list of comma-separated strings. Specify one or more values corresponding to the names specified with the - ExtendedAppName parameter. Specify values as a list of comma-separated strings. Specify a URL in the standard format. 85

86 Dynamic Parameter Description Usage where the revocation list file is posted. If you need to support disconnected users or external users, this URL should be accessible from both the internal organization's network and the Internet. Caution Be careful when implementin g revocation. Based on the refresh interval that you specify, you must renew a revocation list periodically or it will automatically expire, preventing users from consuming content that requires that list. To ensure that you do not inadvertently prevent users from consuming content, 86

87 Dynamic Parameter Description Usage carefully evaluate the interval you require for refreshing the revocation list. - RevocationRefreshPerDays Optional parameter that specifies the number of days that the revocation list remains valid. If a user has a copy of the revocation list that is older than this value, the user must obtain an updated revocation list to consume the content. This parameter is required if you specify the - RevocationLocatio n parameter. - RevocationPublicKeyFilePath Optional parameter that specifies the path of the public key file for the revocation list. This parameter is required if you specify the - RevocationLocatio n parameter. Specify a number. Specify the path to the public key file. Important If you use both the -Right and -CustomRight parameters, each parameter must specify a list containing at least one right for each user or group. For example, when creating a template, you cannot assign standard rights to one set of users and custom rights to a 87

88 different set of users. If this is required, create a template without specifying the users and then modify the existing template to add the users and rights. For more information about modifying an existing template, see Editing a Rights Policy Template. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Editing a Rights Policy Template There are two methods available for modifying an existing rights policy template. One method enables you to change all the settings of a rights policy template with a single command. The other method allows you to change individual settings without affecting other settings of the rights policy template. Modifying all settings with a single command By using the Set-Item cmdlet, you can modify all the settings of a rights policy template with a single command. The Set-Item cmdlet uses the same parameters as the New-Item cmdlet that you can use to create a rights policy template. Important When you use this method to modify an existing rights policy template, any optional parameters that you do not specify on the command line will revert to their default settings. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To modify all the settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. At the Windows PowerShell command prompt, type: Set-Item -Path <drive>:\rightspolicytemplate\<template_id> - LocaleName <locale_names> -DisplayName <display_names> -Description <descriptions> 88

89 [-UserGroup <user_list> [-Right <standard_rights>] [-CustomRight <custom_rights>]] [- RightsRequestUrl <url>] [-ContentExpiredOnDateInDaysOrNever <expiration>] [- UserLicenseRenewalInDays <days>] [-ArchivedTemplate] [-EnableViewInTrustedBrowser] [- EnableOnetimeLicense] [-ExtendedAppName <pair_names> - ExtendedAppValue <pair_values>] [-RevocationLocation <list_url> - RevocationRefreshPerDays <days> -RevocationPublicKeyFilePath <path>] where <drive> is the name of the Windows PowerShell drive, and <template_id> is the ID of the rights policy template you found in the previous step. For information about the parameters and values for this cmdlet, see Creating a New Rights Policy Template. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Modifying individual settings You can modify a rights policy template by traversing the portion of the AD RMS administration namespace in Windows PowerShell that represents rights policy templates and creating, removing, and setting properties of objects in that namespace. The following procedures describe how to work with objects in the subcontainers of the \RightsPolicyTemplate container. For more information about specific settings, see Creating a New Rights Policy Template. To modify identification information settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. Do one of the following: To add a language to the rights policy template, at the Windows PowerShell command prompt, type: New-Item -Path <drive>:\rightspolicytemplate\<template_id>\identificationinfo -Name <locale> -DisplayName <display_name> -Description <description> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <locale> is the locale code (such as en-us), <display_name> is the language-specific name of the template to display to the user, and <description> is the language-specific description of the rights policy template. To modify an existing language in a rights policy template, at the Windows PowerShell command prompt, type: Set-Item - 89

90 Path <drive>:\rightspolicytemplate\<template_id>\identificationinfo\<locale> - DisplayName <display_name> -Description <description> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <locale> is the locale code (such as en-us), <display_name> is the language-specific name of the template to display to the user, and <description> is the language-specific description of the rights policy template. To delete an existing language in a rights policy template, at the Windows PowerShell command prompt, type: Remove-Item - Path <drive>:\rightspolicytemplate\<template_id>\identificationinfo\<locale> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and <locale> is the locale code (such as en-us) of the language you want to remove. To modify user rights settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. Do one of the following: To modify the custom rights list of a rights policy template, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\rightspolicytemplate\<template_id>\userright - Name CustomRightDefinitionList -Value <custom_right>[,<custom_right> ] where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and <custom_right> is the name of one of the custom rights you want to be able to assign to users in this rights policy template. To add a user or group to a rights policy template, at the Windows PowerShell command prompt, type: New-Item -Path <drive>:\rightspolicytemplate\<template_id>\userright -Name < _address> [-FullControl] [-View] [-Edit] [-Save] [-Export] [-Print] [-Forward] [- Reply] [-ReplyAll] [-Extract] [-AllowMacros] [-ViewRightsData] [-EditRightsData] [- CustomRight <custom_right>,<custom_right> ] where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, < _address> is the address of the user or group being added, and <custom_right> is the name of one of the custom rights in the custom rights list of the rights policy template. Use the parameters to assign one or more rights to the user or group being added. If 90

91 you specify the -FullControl parameter, you cannot assign any other rights. To modify the rights of an existing user or group, at the Windows PowerShell command prompt, type: Set-Item -Path <drive>:\rightspolicytemplate\<template_id>\userright\ < _address> [-FullControl] [-View] [-Edit] [-Save] [-Export] [-Print] [-Forward] [- Reply] [-ReplyAll] [-Extract] [-AllowMacros] [-ViewRightsData] [-EditRightsData] [- CustomRight <custom_right>,<custom_right> ] where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, < _address> is the address of the user or group being modified, and <custom_right> is the name of one of the custom rights in the custom rights list of the rights policy template. Use the parameters to assign one or more rights to the user or group being modified. If the user or group was previously assigned a right and you do not specify the corresponding parameter, that right is removed. If you specify the -FullControl parameter, you cannot assign any other rights. To remove a user or group, at the Windows PowerShell command prompt, type: Remove-Item -Path <drive>:\rightspolicytemplate\<template_id>\userright\ < _address> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and < _address> is the address of the user or group being removed. To set the URL that users can request additional rights through, at the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\rightspolicytemplate\<template_id>\userright - Name RightsRequestUrl -Value <url> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and <url> is the URL that users can request additional rights through. To modify expiration policy settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. Do one of the following: To set when content protected by the rights policy template expires, at the Windows PowerShell command prompt, type: Set-ItemProperty - Path <drive>:\rightspolicytemplate\<template_id>\expirationpolicy -Name ContentExpiredOnDateInDaysOrNever -Value {Never <days> <date>} 91

92 where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <days> is a number (such as 31) to specify the number of days to elapse before the content expires, and <date> is a date (such as 01/31/2011) indicating when the content expires at midnight, Coordinated Universal Time (UCT), also known as Greenwich Mean Time. If you specify Never (the default), the content never expires. To set when the use license expires, at the Windows PowerShell command prompt, type: Set-ItemProperty - Path <drive>:\rightspolicytemplate\<template_id>\expirationpolicy -Name UseLicenseExpiredInDays -Value <days> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and <days> is a number that specifies the number of days the use license will remain valid. To modify extended policy settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. Do one of the following: To enable users to view protected content using a browser add-on, at the Windows PowerShell command prompt, type: Set-ItemProperty - Path <drive>:\rightspolicytemplate\<template_id>\extendedpolicy -Name IsViewInTrustedBrowserEnabled -Value $true where <drive> is the name of the Windows PowerShell drive, and <template_id> is the ID of the template you found in the preceding step. To require a new use license every time content is consumed, at the Windows PowerShell command prompt, type: Set-ItemProperty - Path <drive>:\rightspolicytemplate\<template_id>\extendedpolicy -Name IsOnetimeLicenseEnabled -Value $true where <drive> is the name of the Windows PowerShell drive and <template_id> is the ID of the template you found in the preceding step. To add a name/value pair for a specific AD RMS-enabled application, at the Windows PowerShell command prompt, type: New-Item -Path <drive>:\rightspolicytemplate\<template_id>\extendedpolicy - Name <pair_name> -Value <pair_value> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID 92

93 of the template you found in the preceding step, <pair_name> is a string specifying the name of the name/value pair, and <pair_value> is the value of the name/value pair. To modify a name/value pair, at the Windows PowerShell command prompt, type: Set-Item - Path <drive>:\rightspolicytemplate\<template_id>\extendedpolicy\<pair_name> - Value <pair_value> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <pair_name> is a string specifying the name of the name/value pair, and <pair_value> is the value of the name/value pair. To delete a name/value pair, at the Windows PowerShell command prompt, type: Remove-Item - Path <drive>:\rightspolicytemplate\<template_id>\extendedpolicy\<pair_name> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, and <pair_name> is a string specifying the name of the name/value pair. To modify revocation policy settings of a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. At the Windows PowerShell command prompt, type: Set-ItemProperty - Path <drive>:\rightspolicytemplate\<template_id>\revocationpolicy -Name Location - Value <url> -RefreshPerDays <days> -PublicKeyFilePath <path> where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <url> is the location of the revocation list, <days> is a number specifying the number of days that the revocation list remains valid, and <path> specifies the path of the public key file for the revocation list. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement 93

94 Viewing a Summary of User Rights for a Rights Policy Template The summary of user rights lets you review the rights granted to users and groups by a specific template. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. To view a summary of user rights for a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to view. 2. Get-ChildItem -Path <drive>:\rightspolicytemplate\<template_id>\userright where <drive> is the name of the Windows PowerShell drive, and <template_id> is the ID of the template you found in the preceding step. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Archiving a Rights Policy Template Archived templates are not exported to the template export location and are not distributed by the template distribution pipeline. After the client computers refresh their rights policy templates, the archived templates are no longer available to users for publishing new content. At the same time, archived templates allow the server to continue issuing use licenses for content already published against them. 94

95 Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. To archive a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to view. 2. Set-ItemProperty -Path <drive>:\rightspolicytemplate\<template_id> -Name IsDistributed -Value $false where <drive> is the name of the Windows PowerShell drive, and <template_id> is the ID of the template you found in the preceding step. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Deleting a Rights Policy Template When you delete a rights policy template from the Active Directory Rights Management Services (AD RMS) cluster, content published using that template can no longer be consumed. As a best practice, you should back up the configuration database before deleting a rights policy template to ensure that you can recover rights-protected content if necessary. An alternative to backing up the whole database is to archive the template that you want to stop using to add rights-protection to documents. Archiving a rights policy template will allow users to consume the content but not create new rights-protected content with the template. For more information about archiving templates, see Archiving a Rights Policy Template. For AD RMS clients that are not running Windows Server 2008 or Windows Server 2008 R2, or clients for which the automatic rights policy template distribution has not been enabled, you must manually remove the rights policy template from a user's computer. If you do not remove the deleted rights policy template and someone uses it to publish content, AD RMS will not be 95

96 able to issue any use licenses for the content, because it will not be able to locate the specified template in the configuration database. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. To delete a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to delete. 2. Remove-Item -Path <drive>:\rightspolicytemplate\<template_id> where <drive> is the name of the Windows PowerShell drive and <template_id> is the ID of the template you found in the preceding step. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Adding a New Language to a Rights Policy Template When you create a rights policy template, you select which language that template uses. By default, rights policy templates use the language setting of your server operating system. If you have AD RMS-enabled clients that use a different language setting on their operating systems, selecting their language setting when you create or update the rights policy template enables the template to reflect the preferred regional language option of the client. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. 96

97 To add a new language to a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem -Path <drive>:\rightspolicytemplate Where <drive> is the name of the Windows PowerShell drive. Note the ID of the rights policy template that you want to modify. 2. At the Windows PowerShell command prompt, type: New-Item - Path <drive>:\rightspolicytemplate\<template_id>\identificationinfo\<locale> - DisplayName <display_name> -Description <description> Where <drive> is the name of the Windows PowerShell drive, <template_id> is the ID of the template you found in the preceding step, <locale> is the locale code (such as en- US), <display_name> is the language-specific name of the template to display to the user, and <description> is the language-specific description of the rights policy template. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Restoring a Rights Policy Template To ensure that rights policy templates are available in the export location after a system restore of the computer where the rights policy templates are stored, you must export the rights policy templates from the configuration database again. Note If you are using Windows Server 2008 R2 with automatic template distribution enabled, exporting the rights policy templates is not required. Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure. 97

98 To restore a rights policy templates 1. At the Windows PowerShell command prompt, type: Get-ItemProperty <drive>:\rightspolicytemplate -Name PublishUNCFilePath where <drive> is the name of the Windows PowerShell drive. Note the path of the template distribution folder. 2. Delete the contents of the template distribution folder. 3. At the Windows PowerShell command prompt, type: Clear-ItemProperty <drive>:\rightspolicytemplate -Name PublishUNCFilePath where <drive> is the name of the Windows PowerShell drive. 4. At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\rightspolicytemplate -Name PublishUNCFilePath - Value <UNC_path> where <drive> is the name of the Windows PowerShell drive and <UNC_path> is the path of the shared folder. All the rights policy templates from the configuration database will be exported and overwrite the ones currently in this folder. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Copying a Rights Policy Template By using Windows PowerShell cmdlets, you can copy a rights policy template from one Active Directory Rights Management Services (AD RMS) cluster to another. Membership in the local AD RMS Template Administrators group, or equivalent, on both AD RMS clusters, is the minimum required to complete this procedure. To copy a rights policy template 1. At the Windows PowerShell command prompt, type: Get-ChildItem <source_drive>:\rightspolicytemplate where <source_drive> is the Windows PowerShell drive representing the source AD RMS cluster. Note the ID of the rights policy template you want to copy. 2. At the Windows PowerShell command prompt, type: 98

99 Copy- Item <source_drive>:\rightspolicytemplate\<template_id> <destination_drive>:\rights PolicyTemplate where <source_drive> is the Windows PowerShell drive representing the source AD RMS cluster, <template_id> is the ID of the rights policy template you found in the first step, and <destination_drive> is the Windows PowerShell drive representing the destination AD RMS cluster. To copy all rights policy templates from the source AD RMS cluster, type * in place of the rights policy template ID. Tip Rather than typing out the entire rights policy template ID on the command line, you can type the first few characters and then press the TAB key. Windows PowerShell will then complete the ID for you. Understanding the AD RMS Administration Provider Namespace Configuring Rights Policy Templates Understanding Rights Policy Templates Understanding Rights Enforcement Working with Reports Active Directory Rights Management Services (AD RMS) reports give you the ability to compile and view useful information about how users are interacting with your AD RMS cluster. This section contains tasks that show you how to create these reports. This section contains the following tasks: Creating a System Health Report Creating a User Request Report Creating a User Request Information Report Creating a Certificate Chain Report Creating a Certificate Information Report Creating a Child Certificate Report Creating an Issuance License Report Exporting Report Definition Language Files 99

100 Creating a System Health Report A system health report gives you important information about how well your Active Directory Rights Management Services (AD RMS) cluster is functioning. You can obtain reports on the following areas of server activity: Request A Request report provides information about user requests that the cluster processed, including the number and success rate of requests of each type, as well as the average duration (in milliseconds) of each request type. Server A Server report provides information about user requests that each server processed, including the total number and success rates of the requests, as well as the average duration (in milliseconds) of each request. Domain A Domain report provides information about user requests that the cluster processed for each domain, including the total number and success rates of the requests, as well as the average duration (in milliseconds) of each request. User A User report provides information about requests from each user that the cluster processed, including the number and success rate of requests of each user, as well as the average duration (in milliseconds) of each user s requests. You can request summary reports that display all items for each request type, or you can narrow the report to a specific set of items. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a summary system health report At the Windows PowerShell command prompt, type: Get-RmsSystemHealthReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -ReportType <report_type> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, and <report_type> is the type (Request, Server, Domain, or User) of the report you want to create. Times are expressed as Coordinated Universal Time (UTC), also 100

101 known as Greenwich Mean Time. The default range is the preceding 14 days. For example, for a Windows PowerShell drive named Z, to create a summary report of request types for the period beginning January 1, 2009 at 8:00 AM Pacific Standard Time (which is eight hours behind UTC time) and ending January 8, 2009 at 11:59 PM Pacific Standard Time, type: Get-RmsSystemHealthReport -Path Z:\Report -StartTime "1/1/ :00" -EndTime "1/9/ :59" -ReportType Request To create a system health report for a specific request type At the Windows PowerShell command prompt, type: Get-RmsSystemHealthReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -ReportType Request -RequestType <request_type> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, and <request_type> is the type of request (such as FindServiceLocationsForUser, Certify, GetClientLicensorCert, AcquireLicense, or TemplateDistribution.AcquireTemplateInformation) for which you want to create a report. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. To create a system health report for a specific server At the Windows PowerShell command prompt, type: Get-RmsSystemHealthReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -ReportType Server -ServerName <server_name> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, and <server_name> is the name of the server for which you want to create a report. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. To create a system health report for a specific domain At the Windows PowerShell command prompt, type: Get-RmsSystemHealthReport -Path <drive>:\report -StartTime [<start_time>] [- EndTime <end_time>] -ReportType Domain -DomainName <domain_name> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, and <domain_name> is the name of the domain for which you want to create a report. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. 101

102 To create a system health report for a specific user At the Windows PowerShell command prompt, type: Get-RmsSystemHealthReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -ReportType User -UserName <user_name> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, and <user_name > is the name of the user for which you want to create a report. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Creating a User Request Report You can create a user request report to learn details about a particular user request, including such details as the time of the request, the server that responded to the request, and the results of the request. The first step in creating a user request report is to produce a summary request report for a user that lists the user ID and request types processed for the user. You can then use this information to create a report that shows the details of the specific requests of a particular type by the user. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a summary request report for a user At the Windows PowerShell command prompt, type: Get-RmsUserRequestReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -UserName <user_domain>\<user_name> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, <user_domain> is the Active Directory Domain Services domain name of the user you want to create a report for, and <user_name> is the name of the user you want to create a report for. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. 102

103 For example, for a Windows PowerShell drive named Z, to create a summary report for a user named kelly in a domain named corpmain for the period beginning January 1, 2009 at 8:00 AM Pacific Standard Time (which is eight hours behind UTC time) and ending January 8, 2009 at 11:59 PM Pacific Standard Time, type: Get-RmsUserRequestReport -Path Z:\Report -StartTime "1/1/ :00" -EndTime "1/9/ :59" -UserName corpmain\kelly Tip If Service Pack 1 (SP1) for Windows Server 2008 R2 is installed, you can also specify user names in the format <user_name>@<domain>. To create a detailed request report for a user Do one of the following a. If Service Pack 1 (SP1) for Windows Server 2008 R2 is not installed, at the Windows PowerShell command prompt, type: Get-RmsUserRequestReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -UserID <user_id> -RequestType <request_type> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, <user_id> is the integer ID (obtained from a summary report) of the user you want to create a report for, and <request_type> is the type of request (such as FindServiceLocationsForUser, Certify, GetClientLicensorCert, AcquireLicense, or TemplateDistribution.AcquireTemplateInformation) you want to create a report for. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. b. If SP1 for Windows Server 2008 R2 is installed, at the Windows PowerShell command prompt, type: Get-RmsUserRequestReport -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -UserName <user_domain>\<user_name> - RequestType <request_type> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of requests you want to report, <user_domain> is the Active Directory Domain Services domain name of the user you want to create a report for, <user_name> is the name of the user you want to create a report for, and <request_type> is the type of request (such as FindServiceLocationsForUser, Certify, GetClientLicensorCert, AcquireLicense, or TemplateDistribution.AcquireTemplateInformation) you want to create a report for. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. Tip You can also specify user names in the format <user_name>@<domain>. 103

104 Important The request IDs displayed in this report are specific to the AD RMS cluster identified by <drive>. You cannot use them as parameter values for cmdlets that you run with a Windows PowerShell drive that identifies another AD RMS cluster. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Creating a User Request Information Report A user request information report lets you view details about a particular user request. You can obtain the required request ID from a detailed user request report. For more information, see Creating a User Request Report. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a user request information report At the Windows PowerShell command prompt, type: Get-RmsRequestInfo -Path <drive>:\report -RequestID <request_id> where <drive> is the name of the Windows PowerShell drive, and <request_id> is the ID of the user request for which you want to obtain detailed information. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Creating a Certificate Chain Report A certificate chain report displays the chain of certificates associated with a particular user request. The identifier of the request can be obtained by creating a user request report. For more information, see Creating a User Request Report. 104

105 Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a certificate chain report At the Windows PowerShell command prompt, type: Get-RmsCertChain -Path <drive>:\report -RequestID <request_id> where <drive> is the name of the Windows PowerShell drive, and <request_id> is the integer ID of a user request with associated certificates, such as a Certify or AcquireLicense request. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Creating a Certificate Information Report A certificate information report lets you view details about a particular certificate. You can obtain the required certificate ID from a certificate chain report. For more information, see Creating a Certificate Chain Report. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a certificate information report At the Windows PowerShell command prompt, type: Get-RmsCertInfo -Path <drive>:\report -CertificateID <cert_id> where <drive> is the name of the Windows PowerShell drive, and <cert_id> is the ID of the certificate for which you want to obtain detailed information. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports 105

106 Creating a Child Certificate Report A child certificate report lets you view the certificates that were issued from a particular client licensor certificate (CLC) or issuance license (IL). You can use this information to help you troubleshoot problems with certificate and license issuance, for example. You can obtain the required certificate ID and type from a certificate chain report. For more information, see Creating a Certificate Chain Report. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create a child certificate report At the Windows PowerShell command prompt, type: Get-RmsChildCert -Path <drive>:\report [-StartTime <start_time>] [- EndTime <end_time>] -ParentCertID <parent_id> -ParentCertType <parent_type> where <drive> is the name of the Windows PowerShell drive, <start_time> and <end_time> are the beginning and ending time of the range of child certificates you want to include in the report, <parent_id> is the ID of the parent certificate for which you want to obtain child information, and <parent_type> is the type (Client-Licensor-Certificate or Issuance-License) of the parent certificate. You can also specify CLC or IL as the value of the -ParentCertType parameter. Times are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time. The default range is the preceding 14 days. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Creating an Issuance License Report An issuance license report unencrypts the user rights policy in an issuance license and returns it in extensible rights Markup Language (XrML) format. You can create a certificate chain report to obtain the certificate ID required for this procedure. For more information, see Creating a Certificate Chain Report. Important By default, Active Directory Rights Management Services (AD RMS) does not log the issuance license policy required to produce this report. To configure the cluster to log this 106

107 information, set the LoggingLevel value to 1 in the following registry key, and then restart the AD RMS Logging Service: HKLM\System\CurrentControlSet\Services\ADRmsLoggingService\Params Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To create an issuance license report At the Windows PowerShell command prompt, type: Get-RmsEncryptedIL -Path <drive>:\report -ILCertificateID <IL_ID> where <drive> is the name of the Windows PowerShell drive, and <IL_ID> is the ID of the issuance license for which you want to create the issuance license report. Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Exporting Report Definition Language Files You can use this procedure to export the SQL Server Report Definition Language (RDL) used by Active Directory Rights Management Services (AD RMS) to a set of files. RDL provides interoperability of commercial reporting products by defining a common schema that allows interchange of report definitions. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To export SQL Server RDL files At the Windows PowerShell command prompt, type: Export-RmsReportDefinitionLanguage -Path <drive>:\report - ExportLocation <folder_path> where <drive> is the name of the Windows PowerShell drive, and <folder_path> is the path of a folder on a file-system drive, for example, c:\users\public. 107

108 Understanding the AD RMS Administration Provider Namespace AD RMS Administration Cmdlets Working with Reports Decommissioning AD RMS Before you remove the Active Directory Rights Management Services (AD RMS) role from a server, you should first decommission AD RMS. When you decommission AD RMS, the behavior of the AD RMS cluster is changed such that it can now provide a key that decrypts the rightsprotected content that it had previously published. This key allows the content to be saved without AD RMS protection. This can be useful if you have decided to stop using AD RMS protection in your organization or still need the information. You should enable decommissioning on the cluster long enough for users to have the opportunity to save their content without AD RMS protection, and for your network and system administrators to disable any AD RMS-enabled clients that are using the service. After you enable decommissioning, the AD RMS administration provider namespace will only show the root container in the Windows PowerShell drive; no further administration is supported. Caution When you decommission a server, it cannot be restored to its previous AD RMS configuration. This process cannot be reversed. Once you have decommissioned AD RMS, you must completely remove AD RMS before you attempt to install another instance of AD RMS. Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure. To decommission AD RMS At the Windows PowerShell command prompt, type: Set-ItemProperty -Path <drive>:\ -Name IsDecommissioned -Value $true - EnableDecommission where <drive> is the name of the Windows PowerShell drive. Understanding the AD RMS Administration Provider Namespace Using Windows PowerShell to Deploy AD RMS Removing the AD RMS Server Role 108