disaster recovery, ad rms · web viewdisaster recovery guide information protection using...

Disaster Recovery, AD RMS

Data Protection Using Active Directory Rights Management Services

Prepared by

Prasada Meegada

Technical Lead, Information Security Team, Bangalore, Microsoft India

Abstract

This white paper provides RIL with helpful information and describe best practices on disaster recovery of Microsoft Active Directory Rights Management Services (AD RMS) for Microsoft Windows Server™ 2008 deployment. This discussion is most appropriate for RIL as per there requirements of disaster recovery scenarios. This paper analyses the potential breakdown points in an RMS system and the possible impacts on the infrastructure and sensitive data should a loss of service occur. In addition, the paper includes suggestions as to how to mitigate the risks of failure and how to restore an AD RMS services.

000<<Customer Name>>0

© 2008 Microsoft Corporation. All rights reserved. MICROSOFT CONFIDENTIAL. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication and is subject to change at any time without notice to you. This document and its contents are provided AS IS without warranty of any kind, and should not be interpreted as an offer or commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other <<Customer Name>>lectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other <<Customer Name>>lectual property.

The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.

We will not knowingly provide advice that conflicts with local, regional, or international laws, however, it is your responsibility to confirm your implementation of our advice is in accordance with all applicable laws.

Page iiDisaster Recovery, AD RMS, Data Protection Using Active Directory Rights Management Services


Revision and Signoff Sheet

Change Record

Date Author Version Change reference

1.0 Initial draft for review/discussion

1.1 Inclusion of section 2.7 Backups required in a worst case DR scenario to rebuild AD RMS cluster

Reviewers

Name Version approved Position Date

© 2008 Microsoft Corporation. All rights reserved. MICROSOFT CONFIDENTIAL. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication and is subject to change at any time without notice to you. This document and its contents are provided AS IS without warranty of any kind, and should not be interpreted as an offer or commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other <<Customer Name>>lectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other <<Customer Name>>lectual property.

The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.

We will not knowingly provide advice that conflicts with local, regional, or international laws, however, it is your responsibility to confirm your implementation of our advice is in accordance with all applicable laws.

Page iiiDisaster Recovery, AD RMS, Data Protection Using Active Directory Rights Management Services


Table of Contents

1 Introduction........................................................................................................................................ 3

2 Disaster Recovery.............................................................................................................................. 4

2.1 Recovering from a cluster node failure.........................................................................................4

2.2 Recovering from a full cluster failure.............................................................................................6

2.3 Recovering from a database failure..............................................................................................6

2.3.1 Restoring AD RMS services when contingency database is not available................................7

2.3.2 Restoring AD RMS services when contingency database is available ......................................7

2.4 Recovering from a catastrophic cluster and database failure........................................................8

2.5 Recovering AD RMS protected content.......................................................................................11

2.6 Decommissioning an AD RMS cluster.........................................................................................14

2.6.1 Enable the decommissioning service.....................................................................................14

2.6.2 Modify permissions on the decommissioning pipeline............................................................14

2.6.3 Configure AD RMS enabled applications to use decommissioning pipeline...........................16

2.7 Backups required in a worst case DR scenario to rebuild AD RMS cluster..................................16

Appendix A: Exporting AD RMS databases..........................................................................................17

Export Trusted Publishing Domain.....................................................................................................17

Stop IIS, Ensure MSMQ is empty.......................................................................................................18

Create AD RMS database backup......................................................................................................19

Appendix B: Preparing a new AD RMS database server......................................................................22

Add DisableStrictNameChecking registry key....................................................................................22

Enable SQL firewall ports ..................................................................................................................23

Enable SQL server network protocols ...............................................................................................28

Add AD RMS service account to SQL login .......................................................................................30

Change the CNAME record in DNS ...................................................................................................32

Appendix C: Restoring backup of AD RMS databses to a new SQL server.......................................34

Appendix D: Log Shipping...................................................................................................................... 38

Log Shipping overview ...................................................................................................................... 38

Disaster Recovery Guide, Data Protection Using Active Directory Rights Management Services, Version 1.0 DraftPrepared by Prasada Meegada


Log Shipping operations ....................................................................................................................38

Log Shipping server roles .................................................................................................................. 39

Log Shipping jobs .............................................................................................................................. 40



1 INTRODUCTIONBy using Active Directory Rights Management Services (AD RMS) and the AD RMS client, you can augment an organization's security strategy by protecting information through persistent usage policies, which remain with the information, no matter where it is moved. You can use AD RMS to help prevent sensitive information—such as financial reports, product specifications, customer data, and confidential e-mail messages—from intentionally or accidentally getting into the wrong hands.

RMS home page: www.microsoft.com/rms

The following scenarios of disaster recovery have been discussed in this white paper which will ensure a quick and fully functional AD RMS deployment in case of failures.

Recovering from a cluster node failure

Recovering from a full cluster failure

Recovering from a database failure

Recovering from a catastrophic cluster and database failure.

Recovering AD RMS protected content

Decommission an AD RMS cluster


http://www.microsoft.com/rms


2 DISASTER RECOVERYAccess to your sensitive data depends on the continuous availability of various components in the AD RMS system. Each of the AD RMS components has varying degree of impact on data access. This white paper talks about all such potential breakdown points, degree of impact and mitigation plans.

2.1 Recovering from a cluster node failureIf an AD RMS cluster node fails while there are other nodes still available in the same AD RMS cluster, the following process will enable full recovery.

1) Remove the server from the load balanced pool.

2) There’s no technical need to remove the node from the cluster as other cluster nodes will not reference it or contact it during normal operations, though if it is possible to uninstall the AD RMS role from the node this will clean up references to the node in the AD RMS database.

3) After an RMS node failure there might still be messages in the local queue in the server that haven’t been flushed to the AD RMS databases. If the server is still functional and it is suspected that there might be outstanding messages in the local message queue, flush the Message Queue service to the database by using the RMS Queue Recovery tool from the AD RMS Administration Toolkit.

4) Shut down and reinstall the server from scratch.

5) Reinstall the AD RMS role in the server by using the steps in the Step by Step deployment guides, adding the AD RMS node to the existing cluster via the existing database as shown in figure 1 below. Make sure that the proper alias is used for the database and not the database server’s physical name.


http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bae62cfc-d5a7-46d2-9063-0f6885c26b98&displaylang=en



Fig 1: Join an AD RMS Cluster

6) Select the SQL server, database instance and the configuration database name.

Fig 2: Selecting the SQL database

7) In the next screen, provide the password for cluster key.



Fig 3: Provide cluster key password

2.2 Recovering from a full cluster failureIn case the last node in an existing cluster fails, or all the nodes in an existing cluster become non-functional, the procedure remains same as mentioned in section 2.1 except for point number 2 mentioned below.

1) Remove the servers from the load balanced pool.

2) Identify the cause of the original failure and resolve it. If there are errors in the cluster’s configuration that caused the system failure, the errors might need to be corrected directly in the configuration database before continuing with the recovery.

3) There’s no technical need to remove the failed nodes from the cluster as new cluster nodes will not reference or contact them during normal operations, though if it is possible to uninstall the AD RMS role from the failed nodes this will clean up references to the nodes in the AD RMS database.

4) After an RMS node failure there might still be messages in the local queue in the servers that haven’t been flushed to the AD RMS databases. If the servers are still functional and it is suspected that there might be outstanding messages in the local message queues, flush the Message Queue service to the database by using the RMS Queue Recovery tool from the AD RMS Administration Toolkit.

5) Shut down and reinstall the servers from scratch.

6) Reinstall the AD RMS role in the servers by using the steps in the Step by Step deployment guides. Even if there are no working nodes in an AD RMS cluster, you must add the AD RMS role





to the server by indicating “join an existing cluster” and point the server to the existing AD RMS database for the cluster. Nodes do not need to communicate with any existing nodes during setup as all the information needed is obtained from the RMS configuration database. Make sure that the proper alias is used for the database and not the database server’s physical name.

7) Add the servers back to the load balanced pool.

.

2.3 Recovering from a database failureIf the active AD RMS database server fails, AD RMS nodes will continue to work until rebooted or the service is restarted. In this situation the servers will work in reduced functionality in which the following functionality will not be available:

1) AD RMS cluster nodes cannot be restarted. If reboot, servers will not join the cluster until the database is available.

2) New AD RMS users, or existing users connecting from new computers or devices, will not be able to use AD RMS until connection to the database is restored, as the AD RMS certification pipelines will not be able to perform certification without access to the database. The same applies to existing users whose existing credentials expire, typically after one year from initial certification.

3) Exchange pre-licensing will not work until database connectivity is restored. Users will have to acquire licenses when consuming content since the pre-licensing functionality requires obtaining copies of the user’s RACs from the AD RMS configuration database. It is possible to configure AD RMS to pre-cache users RACs to speedup pre-licensing, and this will also enable Exchange pre-licensing to continue working offline when the AD RMS configuration database is not available.

4) It will not be possible to perform revocation of entities whose GUID needs to be obtained from the AD RMS databases, such as user’s RACs or workstations GUIDs.

5) Reporting will not be available until the AD RMS logging database becomes reachable.

6) If the Directory Services Cache database is unavailable, all the AD RMS group membership queries will be redirected to the global catalogs servers. There is no noticeable reduction in RMS services when this table is not available for short periods of time.

During this period, the AD RMS nodes will continue to operate and log operations, but the information generated by logging of AD RMS operations will continue to be stored in each node’s local message queue, and it will be flushed to the database when connectivity to the database server is restored.

In case of an AD RMS database failure, there might be the following two possible disaster recovery scenarios:

NOTE: DO NOT reboot any AD RMS server until the database operation is restored, unless it is desired to stop the AD RMS service altogether.



2.3.1 Restoring AD RMS services when contingency database server is not available

1) Prepare the new database server which involves the following (Refer Appendix B for more information):

Add DisableStrictNameChecking Registry Key Enable SQL Firewall Ports Enable SQL Server Network Protocols Add AD RMS service account to SQL Logins Check the CNAME record in DNS

2) Restore a prior backup of the existing database (in particular, the configuration database needs to be restored, the logging database needs to be restored to an empty state or to a recent state if it contains information of a period that’s of interest for reporting or troubleshooting and the Directory Services Caching database can be restored to any state, including the empty initial state, as it will be regenerated as needed). This step will involve the following(Refer Appendix C for more information):

Restore the database to the new SQL server

Restart IIS and restart the AD RMS logging service on the AD RMS server

3) Reboot the AD RMS servers one by one to confirm they can connect to the new database server normally.

2.3.2 Restoring AD RMS services when contingency database server is available (For eg. via SQL Log Shipping)

1) This scenario is most appropriate when the local data center site has failed or the SQL storage has failed and need to bring the AD RMS services functional at a remote data center site.

2) Prepare the new database server which involves the following (Refer Appendix B for more information):


3) Stop the existing database server. Fail over to the secondary database server (by changing the appropriate DNS server record or using some other redirection mechanisms).

4) If AD RMS cluster nodes are functional at the local site, then reboot the AD RMS servers one by one to confirm they can connect to the new database server normally.



5) If AD RMS cluster nodes also have failed at local site due to reasons like natural calamity, then install a new AD RMS cluster nodes by following the procedure mentioned in section 2.2 “Recovering from a full cluster failure” of this white paper.

6) Shut down and fix or reinstall the original database server and perform the necessary steps to reverse the direction of the replication of the database servers.

NOTE: Refer Appendix D and Appendix A for more information on SQL Log Shipping and Exporting AD RMS databases respectively.

2.4 Recovering from a catastrophic cluster and database failureIf for any reason the AD RMS database servers are destroyed and there’s no valid, functional backup or secondary database containing valid data to restore the AD RMS cluster to a valid working state, the following process should be followed:

1) Confirm that a backup of the cluster’s Trusted Publishing Domain(TPD) is available. This backup should have been performed after initial installation and stored in a safe place, protected with a password that’s documented and stored in a separate safe location.

Figure4: Exporting TPD file (includes Server Licensor Certificate and AD RMS cluster key)

NOTE: By default, an AD RMS Licensing Server can issue use licenses for only content where it originally issued the publishing license. It some situations, this may not be acceptable. By adding a



TPD trust policy, it allows for one AD RMS cluster to issue use licenses against publishing licenses that were issued by a different AD RMS cluster. You add a trusted publishing domain by importing the server licensor certificate and private key of the server to trust.The following are examples of when TPD trust policy is added to an AD RMS cluster:

In a disaster recovery scenario like this where the AD RMS cluster and database are lost and existing rights protected content needs to be accessed.

In the event when one cluster running AD RMS is to be discontinued, users may still want to access previously protected content that was issued a publishing license by that computer. Servers in other clusters can then add the to-be-discontinued server as a trusted publishing domain.

One company acquires another company

2) Install a new AD RMS cluster:

a. Delete the existing Service Connection Point from AD as shown in figure 5. This is critical as the existence of a registered Service Connection Point will prevent the installation of a new certification cluster in the same forest.

Figure5 : Deleting AD RMS Service Connection Point (SCP) from AD

b. Install a new database server or provision a database server able to be used to host a new AD RMS database.

c. Install a new node on a new AD RMS certification cluster with the same AD RMS URLs, pointing it to the new AD RMS database.

d. If using an HSM to protect the Server Licensor Certificate of the original cluster, a backup of the keys stored in that HSM for the cluster must be available. A new security world needs to be created in the HSM by importing the existing cluster’s keys.

e. Indicate setup to use a key stored in the database server if not using an HSM or in a specific cryptographic provider if an HSM will be used.

f. Finalize installation of the new cluster with identical parameters as used for the old cluster.



3) Import the Trusted Publishing Domain from the existing cluster. This will import the cluster’s private key definition and Server Licensor Certificate, which will enable the new cluster to issue licenses against documents protected with the old cluster. Refer figure 6.

Figure6: Importing Trusted Publishing Domain file

4) Re-create any existing Rights Policy Templates using definitions similar to the ones in the old cluster. While importing the TPD will also import definitions of all the existing templates, the existing templates will be imported as Archived templates, not as Distributed Rights Policy templates. So the old templates will be available to the server in order to issue licenses to previously protected content, but new templates will be required for the users to be able to protect new documents.

5) It is recommended that the DRM folder in all the user’s personal profiles are deleted via a script, as this will make them begin using the new cluster keys.

2.5 Recovering AD RMS protected content

In any organization there’s often a need to identify content (typically in the form of documents or email) related to certain proceedings and grant access to those materials to specialized personnel. Another common situation involves the need for recovering information protected by employees without their cooperation, for example, because they no longer work for the company.



AD RMS provides tools and capabilities to regain access to protected documents in different situations, in either an automated or systematic manner or as individual recovery or search operations.

Documents protected with AD RMS can be stored in different locations, among them:

A user’s workstation inside a personal folder A user workstation inside a PST connected to Outlook A file share A SharePoint library A user’s mailbox or in transit in an Exchange infrastructure An archival system

There are three common situations where access to protected information is needed:

1) The documents containing the information are already in the hands of the persons requiring access.

2) The documents are known to be located in a certain location but the particular documents containing the information in question are not identified.

3) There’s a need to proactively identify all documents pertaining to a certain matter and archive them in unprotected or accessible form.

In the first case, which is common when auditors have access to a user’s workstation and they want to read or unprotect a particular piece of information found in the user’s machine, access to the documents can be enabled by making that person, either temporarily or permanently, a member of the SuperUsers group and enabling SuperUsers functionality in AD RMS. Refer Figure 7.

When a user is a member of the AD RMS Superusers group that user is granted any license it requests, so the user can view, copy or unprotect the content at will. Obviously this functionality has to be managed in a very controlled way.

Enabling SuperUser’s group:



Figure7: Enabling SuperUsers group

Additionally refer http://technet.microsoft.com/en-us/library/ee849845(WS.10).aspx for step by step guidance on enabling SuperUsers group.

Another alternative for dealing with this case is to allow one person that is a member of the SuperUsers group to perform bulk decryption of all documents in a certain location, and then handling the protected documents to the person requiring access. The information can then be indexed and searched using normal tools for the task.

Considering that the information is likely sensitive, a formal and secure process for dealing with these proceedings needs to be defined.

For this task, Microsoft has published a tool called the AD RMS Bulk Protection Tool which can be used to encrypt files via the command line or, more importantly in this case, unprotect them. The bulk protection tool can be combined with a script to search all protected files in a system and unprotect them, allowing someone performing discovery full access to all the files in the system.

The Bulk Protection Tool can work not only on file shares, but also on emails and attachments stored in a PST. This way emails archived into a PST can also be unprotected in bulk, indexed and searched as needed. Typically, the bulk protection tool will be combined with SuperUser privileges in order to access files or emails in a user’s workstation.

The Bulk Protection tool can be downloaded from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f9fbe58f-c175-41d0-afdc-6f160ab809cd.


http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f9fbe58f-c175-41d0-afdc-6f160ab809cd

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f9fbe58f-c175-41d0-afdc-6f160ab809cd

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


Figure 8 shows a very simple usage scenario of bulk protection tool.

Fig8: AD RMS Bulk Protection tool usage

When files are stored in a protected SharePoint library, they are stored in the database in unprotected format, and they are only protected when downloaded via the SharePoint interfaces. So a person performing e-discovery only needs to be granted access rights over the SharePoint library in order to be able to perform searches or downloads of protected documents. Alternatively, by granting that person direct rights over the SQL Server database acting as the back-end of the SharePoint library the user will be able to extract the unprotected files directly from the database.

When information needs to be automatically and proactively decrypted for performing automated e-discovery or archival, similar solutions typically allow automating the task of unprotecting documents.

Since the Bulk Protection tool can also work with files stored in file shares, it can be also used combined with scripts and scheduled tasks, or with the File Server Resource Manager that’s part of Windows Server 2008 R2, to automatically create unprotected backups of protected files deposited in the file share. Once unprotected files can be accessed and indexed as desired.

2.6 Decommission an AD RMS clusterDecommissioning allows an RMS cluster to be put in a state that will allow all existing documents to be unprotected. It is normally only done only with RMS usage will be removed from an organization. To eliminate one cluster in situations where other RMS clusters will continue to operate, implementing a Trusted User Domain is normally a better solution.

Following are steps to put an AD RMS cluster into the Decommissioning state:

2.6.1 Enable the decommissioning service Access the Active Directory Rights Management Services Console from the Administrative Tools

folder and expand the Active Directory Rights Management Services cluster



Expand Security Policies, click Decommissioning.

In the Actions pane, click Enable Decommissioning and then click Decommission.

Click Yes, confirming to decommission the Active Directory Rights Management Services cluster.

Figure9 : Enabling decommissioning service

2.6.2 Modify permissions on the decommissioning pipeline

Give the Active Directory Rights Management Services Service Group the Read & Execute permission on the decommission folder. Give everyone the Read & execute permission on the decommission.asmx file. The decommission pipeline is located in the %systemroot%\inetpub\wwwroot\_wmcs folder, where %systemroot% is the volume on which Windows Server 2008 is installed. Refer figure 10.

Click Start, type %systemdrive%\inetpub\wwwroot\_wmcs in the Start Search box, and then press ENTER.

Right-click the decommission folder, and then click Properties.

Click the Security tab, click Edit, and then click Add.

In the Select Users, Computers, or Groups box, type %Active Directory Rights Management Services server name%\Active Directory Rights Management Services Service Group, and then click OK.

Double-click the decommission folder, right-click decommission.asmx, and then click Properties.

Click the Security tab, click Edit, and the click Add.

In the Select Users, Computers, or Groups box, type Everyone, and then click OK. In the Windows Security dialog box, enter the name and password of the domain administrator account.

Click OK twice to close the properties sheet.



Figure10: Read & Execute rights for Everyone on Decommissioning pipeline

2.6.3 Configure the Active Directory Rights Management Services-enabled application to use the decommissioning pipeline

Configure the Active Directory Rights Management Services-enabled applications on the clients to obtain a content key from the decommissioning service and permanently decrypt the rights-protected content.

Click Start, type regedit in the Start Search box, and then press ENTER.

Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\DRM.

Right-click DRM, point to New, and then click Key.

Type Decommission as the name for the registry key, and then press ENTER.

Right-click Decommission, point to New, and then click String Value.

Type https:// %Active Directory Rights Management Services server name%/_wmcs/licensing, and then press ENTER.



Double-click the registry entry.

In the Value data box, type https:// %Active Directory Rights Management Services server name%/_wmcs/decommission, and then click OK.

After you believe that all of the content is unprotected and saved, you should export the server licensor certificate. Then AD RMS nodes can be uninstalled. After uninstalling the last node, confirm that the AD RMS Service Connection Point has been removed in AD. If it hasn’t, it can be remover manually by deleting it from the AD RMS Sites and Services MMC, by using the PowerShell interface.

2.7 Backups required in a worst case DR scenario to rebuild AD RMS cluster from scratch

In a worst case DR scenario, the following backups are required:

A backup of SQL databases- Frequency of back up mentioned below

Configuration DB – A valid backup after each configuration change on the AD RMS cluster is a must.

Directory Services Cache DB - Can be restored to any state, including the empty initial state, as it will be regenerated as needed. Hence no recommendation on frequency.

Logging DB – Can be restored to an empty state or to a recent state if it contains information of a period that’s of interest for reporting or troubleshooting. If report generation is crucial, then a daily backup (or more frequent) of this database is required. In which ever state it is restored, it does not affect the AD RMS functionality.

A backup of Trusted Publishing Domain (TPD) – One time backup of TPD right after AD RMS is installed in the AD Forest. Please refer Appendix A.



APPENDIX A: EXPORTING AD RMS DATABASESThe following steps cover how to backup the existing AD RMS databases:

Export Trusted Publishing Domain

Stop IIS

Verify MSMQ is Empty and Stop the AD RMS Logging Service

Create database backups

Export Trusted Publishing Domain1) In the Active Directory Rights Management Services Administration console select Trusted

Publishing Domains.

2) On the right, select Export Trusted Publishing Domain. This will bring up the Export Trusted Publishing Domain box.

3) From the Export Trusted Publishing Domain, click Save As. This will bring up the Export Trusted Publishing Domain File As box. From the Export Trusted Publishing Domain As box, on the left, select folder.

4) Under File name enter filename and make sure XML File (*.xml) is selected for Save As Type. Click Save. This will close the Export Trusted Publishing Domain As box.

5) From the Export Trusted Publishing Domain box, enter password in the Password box. Enter password again in the Confirm Password box.

6) Click Finish. Close the Active Directory Rights Management Services Administration console.



Figure1: Exporting Trusted Publishing Domain (TPD)

Stop IIS, Ensure MSMQ is Empty and Stop the AD RMS Logging Service

Stop IIS

1) Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager on the AD RMS cluster node. This will bring up the Internet Information Services (IIS) Manager.

2) From the Internet Information Services (IIS) Manager, on the left, select the root node. On the right, under Actions select Stop.

3) Close the Internet Information Services (IIS) Manager.



Figure2: Stop IIS

Ensure MSMQ is Empty

This step explains how to verify the Microsoft Message Queuing is emptied and stop the AD RMS Logging Service. AD RMS uses MSMQ on each server in the AD RMS cluster to send information to the logging database. This needs to be done prior to backing up the AD RMS logging database.

1) Log on to AD RMS cluster node.

2) Click Start, point to Administrative Tools, and then click Server Manager.

3) On the left, expand Features, expand Message Queuing, expand Private Queues, expand drms_logging_rms_domain_com_443, and select Queue messages. This will populate the middle pane with Queue messages.

4) Verify there are no messages in Queue messages. Close Server Manager.

Figure3: MSMQ is empty

Stop the AD RMS Logging Service

1) Log on to AD RMS cluster node

2) Click Start, point to Administrative Tools, and then click Services.

3) On the Services screen, right-click AD RMS Logging Service, and select Stop.

4) Close Services.



Figure4: Stop AD RMS logging service

Create AD RMS Database BackupAD RMS uses three databases in the database server:

The configuration database – The configuration database is a critical component of an AD RMS

installation because it stores, shares, and retrieves all configuration data and other data that the

service needs to manage account certification, licensing, and publishing services for a whole

cluster. The way the configuration database is managed directly affects the security and

availability of rights-protected content. Each AD RMS cluster has one configuration database.

The configuration database for the root cluster contains a list of Windows user identities and their

rights account certificates (RACs). If the “Use AD RMS centrally managed key storage” option is

enabled in the AD RMS configuration, the RMS cluster key pair is encrypted, before it is stored in

the database, and used to sign certificates and licenses granted by the server.

The directory services database contains information about users, identifiers (such as e-mail

addresses), security ID (SID), group membership, and alternate identifiers. This information is a

cache of directory services data, used by AD RMS, obtained via Lightweight Directory Access

Protocol (LDAP) queries made to the Active Directory Domain Services (AD DS) global catalog

by the AD RMS licensing service. It is used to improve performance and reduce the burden on

the Active Directory infrastructure during licensing operations. The logging database - For each root or licensing-only cluster, by default, AD RMS installs a

logging database in the same database server instance that hosts the configuration database. AD

RMS also creates a private message queue for logging in the Microsoft Message Queue on each

AD RMS server. The AD RMS logging service transmits data from this message queue to the

logging database. A big difference between RMS v1 and AD RMS is that the certificate XrML text

is, by default, not included in AD RMS logs. This information typically makes up almost 80-90% of

the logging database space in RMS v1, but it is not logged by default in AD RMS, thus

significantly reducing logging volumes. However, logging of full certificate XrML text can be

enabled via a registry key.

To back up the configuration database, following are the steps:

1) Log on to the SQL server

2) Click Start, select All Programs, click Microsoft SQL Server 2008 and select SQL Server Management Studio. This will bring up the Connect to Server dialog box. Ensure that the Server name is correct and that Authentication is set to Windows Authentication. Click Connect.



3) Expand Databases. Right-click DRMS_Config_rms_domain_com_443, select Tasks and choose Back Up. This will bring up the Back Up Database – DRMS_Config_rms_domain_com_443 windows as shown below.

Figure5: Backup configuration database

4) Click Add in the Destination section as shown in the figure below and select the location.



Figure6: Backup Configuration Database

5) Click OK to finish the backup.

6) Repeat the above steps to backup logging and directory services cache database.



APPENDIX B: PREPARING A NEW AD RMS DATABASE SERVERBefore pointing the AD RMS cluster to a new SQL database server, following needs to be done:


Add DisableStrictNameChecking Registry KeyFor disaster recovery purposes, it is a best practice to refer to the SQL server by a CNAME record and not by the physical server name. This allows for the SQL Server to be called something other than its proper name when a connection attempt is being made. In order to use a CNAME record with a SQL Server, the DisableStrictNameChecking registry key must be added and the value set to 1. This key allows connections to be made to the SQL server by names other than the proper name. By default, SQL Server 2008 will not allow this. Follow the procedure below to implement the registry change:

1. Log on to the SQL server.

2. Click Start, type regedit.exe in the Start Search box, and then press ENTER.

3. Expand the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

4. Right-click Parameters, click New, and then click DWORD (32-bit) Value.

5. In the Value name box, type DisableStrictNameChecking, and then press ENTER.

6. Double-click the DisableStrictNameChecking registry value and type 1 in the Value data box, and then click OK.

7. Close Registry Editor.

Figure1: DisableStrictNameChecking registry key



Enable SQL Firewall PortsThis step explains how to enable the firewall rules on the new SQL server. These rules are required to allow the AD RMS cluster to communicate with the SQL Server.

1. Log on to the SQL server.

2. Click Start, select Administrative Tools and click Windows Firewall with Advanced Security.

This will bring up the Windows Firewall with Advanced Security mmc.

Figure2 : Windows Firewall Advanced Security

3. On the left, select Inbound Rules and on the right click New Rule. This will bring up the New

Inbound Rule Wizard.



Figure3: Inbound Rule Wizard4. On the Rule Type screen, select Port and click Next.

5. On the Protocol and ports screen, select TCP and enter 445 in the box next to Specific local ports: and click Next.



Figure4: Firewall Protocols and Ports

6. On the Action screen, select Allow the connection and click Next.



Figure5: Action: Allow the connection7. On the Profile screen, select Domain, Private, and Public then click Next.



Figure6: Rule profile

8. On the Name screen, enter SQL Server Named Pipes in the box and click Finish.

9. Repeat these steps for all of the entries in the table below.

10. Table 1 – SQL Server Firewall Port Exceptions

Protocol Port Number Name

TCP 445 SQL Server Named Pipes

TCP 1433 SQL Server Listening Port

UDP 1434 SQL Server Browser Service



Enable SQL Server Network ProtocolsThis step explains how to enable the allowed network protocols for SQL2. This is done so that the AD RMS Server can communicate with the database server.

1. Log on to SQL server.

2. Click Start, select All Programs, click Microsoft SQL Server 2008, click Configuration Tools, and

select SQL Server Configuration Manager. This will bring up the SQL Server Configuration

Manager.

Figure7: SQL Server Configuration Manager

3. In SQL Server Configuration Manager, on the left, expand SQL Server Network Configuration and

click Protocols for MSSQLSERVER. This will populate the right pane with four protocols and their

status.



Figure8: Protocols for MSSQLSERVER

4. On the right, right-click Disabled next to Named Pipes and select Enable. This will bring up a pop-

up box that says Any changes made will be saved; however, they will not take effect until the

service is stopped and restarted. Click OK.

Figure9: Enable named pipes



5. Repeat step 4 for TCP/IP. On the right, right-click Disabled next to TCP/IP and select Enable.

This will bring up a pop-up box that says Any changes made will be saved; however, they will not

take effect until the service is stopped and restarted. Click OK.

6. In SQL Server Configuration Manager, on the left, click SQL Server Services. This will populate

the right pane with three services and their state.

Figure10: Stop and Start SQL server service7. On the right, right-click SQL Server (MSSQLSERVER) and select Stop. This will stop the SQL

Server service.

8. On the right, right-click SQL Server (MSSQLSERVER) and select Start. This will start the SQL

Server service.

9. Close SQL Server Configuration Manager.

Add AD RMS Service Account to SQL LoginThis step explains how to add the AD RMS Service Account to SQL Logins on SQL server. This allows the service account to connect to SQL server.

1. Log on to SQL server.



2. Click Start, select All Programs, click Microsoft SQL Server 2008 and select SQL Server

Management Studio. This will bring up the Connect to Server dialog box. Ensure that the Server

name is SQL2 and that Authentication is set to Windows Authentication. Click Connect.

3. On the right, expand Security, right-click Logins, and select New Login. This will bring up the

Login – New screen.

Figure11: New SQL Login4. On the Login – New screen, click Search. This will bring up a Select User or Group box.

5. On the Select User or Group box, enter domain\service account in the box below Enter the object

name to select (examples) and click Check Names. This should resolve with an underline. Click

Ok.



Figure12: Select AD RMS service account6. On the Login – New screen, click OK. This will close the Login – New screen.

7. Close SQL Server Management Studio.

Change The CNAME record in DNSThis step explains how to change the CNAME record in DNS. This will allow the AD RMS cluster to point to the new SQL server by canonical name and not by the physical server name.

1. Log on to the domain controller.

2. Click Start, point to Administrative Tools, and then click DNS. This will bring up the DNS

Manager.

3. From the DNS Manager, on the left, expand DC, expand Forward Lookup Zone, and click

domain.com. On the right, right-click the CNAME record for the SQL server and select Properties.

4. On the properties page, enter the new SQL server name under Fully qualified domain name

(FQDN) for target host: and click OK.

5. Close DNS Manager.



Figure13: DNS CNAME record for SQL server



APPENDIX C: RESTORING BACKUP OF AD RMS DATABASES TO NEW SQL SERVER

This step explains how to restore the AD RMS databases on a new SQL server.

1. Log on to the new SQL server.

2. Click Start, select All Programs, click Microsoft SQL Server 2008 and select SQL Server Management Studio. This will bring up the Connect to Server dialog box. Ensure that the

Server name is correct and that Authentication is set to Windows Authentication. Click

Connect.

3. On the right, right-click Databases and select Restore Database. This will bring up the Restore

Database window.

Figure1: SQL Server Management Studio4. On the Restore Database screen, select the From Device radio button and click the … box. This

will bring up the Specify Backup screen.



Figure2: Selecting “From Device”5. On the Specify Backup screen, click Add. This will bring up the Locate Backup File screen.

Figure3: Specify backup



6. Select the DBBackup folder. Enter DRMS_Config for the File Name and click OK.

Figure4: Locate backup file

7. On the Specify Backup screen click OK.

8. On the Restore Database screen, in the drop-down next to To database: select

DRMS_Config_rms_Fabrikam_com_443.



9. On the Restore Database screen, under Select the backup sets to restore: place a check in the

Restore box, next to DRMS_Config_rms_fabrikam_com_443-Full Database Backup. Click

OK.

Figure5: Restore Database window

10. Once this has completed, a pop-up will say the database has been restored successfully. Click

OK.

11. Repeat steps 3 to 9 for restoring AD RMS logging database and the directory services cache database.



APPENDIX D: LOG SHIPPING OVERVIEWThis appendix only provides an overview on SQL Server log shipping and how we can leverage it for quick restoration AD RMS services in a disaster recovery scenario. Step by step guidance on configuring log shipping is out of scope of this white paper. For more information please refer http://technet.microsoft.com/en-us/library/bb895393.aspx .

Log Shipping OverviewYou can use log shipping to send transaction logs from one database (the primary database) to another (the secondary database in a remote site) on a constant basis. Continually backing up the transaction logs from a primary database and then copying and restoring them to a secondary database keeps the secondary database nearly synchronized with the primary database. In a scenario where the local site database server fails due to storage failure or natural calamity, AD RMS services can be restored by using the remote database server.

Log Shipping OperationsLog shipping consists of three jobs. Each job performs one of the following operations:

1. Backs up the transaction log at the primary server instance

2. Copies the transaction log file to the secondary server instance

3. Restores the log backup on the secondary server instance

The following diagram describes log shipping.

The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are duplicated for each secondary server instance.


http://technet.microsoft.com/en-us/library/bb895393.aspx


A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.

Log Shipping Server Roles

Primary Server and Databases

The primary server in a log shipping configuration is the instance of the SQL Server Database Engine that is your production server. The primary database is the database on the primary server that you want to back up to another server. All administration of the log shipping configuration through SQL Server Management Studio is performed from the primary database.

The primary database must use the full or bulk-logged recovery model; switching the database to simple recovery will cause log shipping to stop functioning.

Secondary Server and Databases

The secondary server in a log shipping configuration is the server where you want to keep a warm standby copy of your primary database. A secondary server can contain backup copies of databases from several different primary servers. For example, a department could have five servers, each running a mission-critical database system. Rather than having five separate secondary servers, a single secondary server could be used. The backups from the five primary systems could be loaded onto the single backup system, reducing the number of resources required and saving money. It is unlikely that more than one primary system would fail at the same time. Additionally, to cover the remote chance that more than one primary system becomes unavailable at the same time, the secondary server could be of higher specification than the primary servers.

The secondary database must be initialized by restoring a full backup of the primary database. The restore can be completed using either the NORECOVERY or STANDBY option. This can be done manually or through SQL Server Management Studio.

Monitor Server

The optional monitor server tracks all of the details of log shipping, including:

When the transaction log on the primary database was last backed up. When the secondary servers last copied and restored the backup files. Information about any backup failure alerts.

The monitor server should be on a server separate from the primary or secondary servers to avoid losing critical information and disrupting monitoring if the primary or secondary server is lost. A single monitor server can monitor multiple log shipping configurations. In such a case, all of the log shipping configurations that use that monitor server would share a single alert job.



For more information, see Monitoring Log Shipping.

Log Shipping Jobs

Log shipping involves four jobs, which are handled by dedicated SQL Server Agent jobs. These jobs include the backup job, copy job, restore job, and alert job.

The user controls how frequently log backups are taken, how frequently they are copied to each secondary server, and how frequently they are applied to the secondary database. To reduce the work required to bring a secondary server online, for example after the production system fails, you can copy and restore each transaction log backup soon after it is created. Alternatively, perhaps on a second secondary server, you can delay applying transaction log backups to the secondary database. This delay provides an interval during which you can notice and respond to a failure on the primary, such as accidental deletion of critical data.

Backup Job

A backup job is created on the primary server instance for each primary database. It performs the backup operation, logs history to the local server and the monitor server, and deletes old backup files and history information. By default, this job will run every 15 minutes, but the interval is customizable.

When log shipping is enabled, the SQL Server Agent job category "Log Shipping Backup" is created on the primary server instance.

SQL Server 2008 Enterprise and later versions support backup compression. When creating a log shipping configuration, you can control the backup compression behavior of log backups. For more information, see Backup Compression (SQL Server).

Copy Job

A copy job is created on each secondary server instance in a log shipping configuration. This job copies the backup files from the primary server to a configurable destination on the secondary server and logs history on the secondary server and the monitor server. The copy job schedule, which is customizable, should approximate the backup schedule.

When log shipping is enabled, the SQL Server Agent job category "Log Shipping Copy" is created on the secondary server instance.

Restore Job

A restore job is created on the secondary server instance for each log shipping configuration. This job restores the copied backup files to the secondary databases. It logs history on the local server and the monitor server, and deletes old files and old history information. The SQL Server job category "Log Shipping Restore" is created on the secondary server instance when log shipping is enabled.


http://technet.microsoft.com/en-us/library/bb964719.aspx

http://technet.microsoft.com/en-us/library/ms190224.aspx


On a given secondary server instance, the restore job can be scheduled as frequently as the copy job, or the restore job can delayed. Scheduling these jobs with the same frequency keeps the secondary database as closely aligned with the primary database as possible to create a warm standby database.

In contrast, delaying restore jobs, perhaps by several hours, can be useful in the event of a serious user error, such as a dropped table or inappropriately deleted table row. If the time of the error is known, you can move that secondary database forward to a time soon before the error. Then you can export the lost data and import it back into the primary database.

Alert Job

If a monitor server is used, an alert job is created on the monitor server instance. This alert job is shared by the primary and secondary databases of all log shipping configurations using this monitor server instance. Any change to the alert job (such as rescheduling, disabling, or enabling the job) affects all databases using that monitor server. This job raises alerts (for which you must specify alert numbers) for primary and secondary databases when backup and restore operations have not completed successfully within specified thresholds. You must configure these alerts to have an operator receive notification of the log shipping failure. The SQL Server Agent job category "Log Shipping Alert" is created on the monitor server instance when log shipping is enabled.

If a monitor server is not used, alert jobs are created locally on the primary server instance and each secondary server instance. The alert job on the primary server instance raises errors when backup operations have not completed successfully within a specified threshold. The alert job on the secondary server instance raises errors when local copy and restore operations have not completed successfully within a specified threshold.

A Typical Log Shipping Configuration

The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restore jobs, as follows:

1. The primary server instance runs the backup job to back up the transaction log on the primary

database. This server instance then places the log backup into a primary log-backup file, which it

sends to the backup folder. In this figure, the backup folder is on a shared directory—the backup share.

2. Each of the three secondary server instances runs its own copy job to copy the primary log-

backup file to its own local destination folder.

3. Each secondary server instance runs its own restore job to restore the log backup from the local

destination folder onto the local secondary database.

The primary and secondary server instances send their own history and status to the monitor server instance.
