Release Notes for Windows Rights Management Services with Service Pack 2

  • Article

Applies To: Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1

Release Date: December 2006

Before You Begin

Review the following information before you install Microsoft® Windows® Rights Management Services (RMS) with Service Pack 2 (SP2). The information contained in these release notes applies to the RMS with SP2 server and not the RMS client. For information about RMS clients, see Rights Management Services (https://go.microsoft.com/fwlink/?LinkId=68637).

System requirements

The hardware requirements for running RMS with SP2 are listed in the following table.

Requirement Recommendation

Computer with one Pentium III processor (800 MHz or higher)

Computer with two Pentium 4 processors (1500 MHz or higher)

256 MB of RAM

512 MB of RAM

20 GB of free hard disk space

40 GB of free hard disk space

Note

RMS with SP2 server was designed for a 32-bit computer. If installed on a 64-bit computer, it will run in emulation mode.

The software requirements for servers running RMS with SP2 are listed in the following table.

Component Requirement

Operating system

Microsoft Windows Server® 2003, except Web Edition, for RMS with SP2.

Rights Management Services with SP2

RMS with Service Pack 1 (SP1) must be installed before you can upgrade to RMS with SP2. The RMS with SP2 client does not have this requirement.

File system

The NTFS file system is recommended.

Prerequisite components
  • Message Queuing (also known as MSMQ) with Active Directory® directory service integration enabled.

  • Internet Information Services (IIS) with ASP.NET enabled.

  • Microsoft .NET Framework 1.1

Note

If you configure your RMS with SP2 to allow remote administration, the computer connecting to the RMS with SP2 Administration service must use Internet Explorer 6.0 or later.

The infrastructure requirements for servers running RMS with SP2 are listed in the following table.

Component Requirements

Directory services

Active Directory on domain controllers running Windows Server 2000 with Service Pack 3 (SP3) or later, in the same domain in which RMS is installed. All users and groups that use RMS to acquire licenses and publish content must have an e-mail address that is configured in Active Directory.

Database server

RMS with SP2 requires a database and stored procedures to perform operations. You can use Microsoft SQL Server™ 2000 with SP3a or later, or Microsoft SQL Server 2005. For testing or other single-computer deployment, Microsoft SQL Server Desktop Engine (MSDE 2000) Release A or Microsoft SQL Server 2005 Express Edition can be used.

RMS is designed for and tested with database servers running Microsoft SQL Server 2000 and Microsoft SQL Server 2005. RMS can run on other database servers if they comply with the following criteria:

  • Support ADO.NET interfaces provided by the Microsoft .NET Framework 1.1.

  • Be compliant with Transact-SQL, the structured query language that Microsoft SQL Server uses, because RMS initialization scripts and RMS stored procedures use Transact-SQL.

  • Support all Microsoft SQL Server specific extensions.

  • Respond to method calls of the System.Data.SqlClient namespace of the .NET Framework.

  • Provide the corresponding functionality of the System.Data.SqlClient namespace.

  • Use Windows Authentication Mode.

To find out whether the database server supports the above criteria, contact the relevant database vendor.

The following table lists the user rights and permissions that are required for performing different activities with RMS.

Activity Account requirements

Installing RMS

Domain user with local computer administrator credentials

Provisioning a RMS root cluster

Domain user with local computer administrator credentials and Active Directory lookup and write

Provisioning a RMS licensing-only cluster

Domain user with local computer administrator credentials and Active Directory lookup

Provisioning while using a new configuration database

Domain user with local computer administrator credentials and read, write, and create on computer running SQL Server

Provisioning while using an existing configuration database

Domain user with local computer administrator credentials and read and write on computer running database server

Administering RMS

Domain user with local computer administrator credentials

Note

For more information about Windows Server configuration, Active Directory, Message Queuing, IIS, and file systems, see Windows Server 2003 TechCenter (https://go.microsoft.com/fwlink/?LinkId=78135).

If you are using RMS in a cluster deployment, make sure that you have addressed the items listed in the following table.

Condition Recommendation

Large number of desktops that will be using RMS

Use Systems Management Server (SMS) or Group Policy to install the RMS with SP2 client.

Large number of client requests

Use a load balancing server, the Network Load Balancing service in the Windows Server operating system, or hardware load balancing to distribute the requests across the cluster.

Two network adapters using virtual IP addressing to service extranet and intranet requests

Make sure that any Domain Name System (DNS) registration that exposes the virtual IP address to the extranet also exposes the address to the intranet.

Important

If DNS registration is not done for the intranet, internal client license requests will fail. If you are unable to modify the DNS settings, the hosts table of each server in the cluster can be modified to map the cluster URL to the cluster's virtual IP address. DNS registration needs to be done before RMS is provisioned. If you have already provisioned the service, you must remove RMS from the server and then repeat the provisioning process.

Supported clients for this release

The RMS client with no service pack, RMS client with SP1, or RMS client with SP2 can be installed on any computer that is running Microsoft Windows 2000, Windows XP, and Windows Server 2003. Earlier versions of Windows operating systems are not supported by this release.

Warning

If you are using the RMS client with no service pack, the client will not be able use online publishing against an RMS server with SP1 or later.

Changes to Functionality

There are several new features in RMS with SP2:

  • Enhanced group expansion across forests

  • Database logging changes

  • Larger server batching sizes

  • Microsoft SQL Server 2005 compatibility

Enhanced Group Expansion Across Forests

What does this feature do?

In RMS, group expansion across forests facilitates the ability for RMS to expand Active Directory Universal group membership in a different forest where group memberships are not replicated between two forests. When a user in one forest sends rights-protected content to a user in another forest, RMS goes through a discovery period where it verifies that the user has access to the content. This verification process is done by using an LDAP query from one forest to the other in order to find the remote forest's RMS service connection point (SCP). When the SCP for the remote forest has been discovered, the RMS service account sends a request to the group expansion pipeline. The request asks the remote forest if a user is a member of a group.

Who does this feature apply to?

This new feature will be of interest to RMS customers in a multiple forest Active Directory environment whose Universal group memberships are not replicated among forests.

Why is this change important?

The new forest trust expansion protocol will improve reliability for customers who are deploying a multiple forest Active Directory environment.

What works differently?

Previous to RMS with SP2, group expansion across forests was achieved by using .NET remoting calls. In this release, the group expansion across forests protocol has been changed to an ASP.NET Web service using SOAP/HTTP requests to the forest trust group expansion pipeline.

Note

For backwards compatibility, .NET remoting calls are still supported in RMS with SP2. However, in order to take full advantage of the new group expansion across forests protocol, all RMS clusters must be running at least RMS with SP2.

What settings are added or changed in RMS with SP2?

The new RMS group expansion pipeline is configured with the most secure settings by default in RMS with SP2 where only the local RMS Service and Administrators groups have access. To give an account access, you should change the access control list on the group expansion pipeline found at wwwroot\_wmcs\GroupExpansion\GroupExpansion.asmx.

Important

Make sure to verify that the RMS service account in each Active Directory forest has access to the group expansion pipeline on each RMS server in the cluster. If the accounts do not have access, group expansion will fail. Alternatively, you could create the same account in each forest and assign the same password to each account. In this case, you would only have to add the one account to the group expansion pipeline.

New events have been added to RMS with SP2 to inform you of problem messages that did not make it into the Message Queuing service. These new event logs include events to notify you whenever a message cannot be digitally signed or the message cannot be validated. Some examples of validation problems include a malformed message, a missing hash or signature, or an incorrect hash or signature.

Database Logging Changes

What does this feature do?

RMS uses a logging listener service that sends all RMS communication to the logging database by using Message Queuing. The RMS cluster submits messages to the Message Queuing service, and the logging listener service retrieves these messages from the Message Queuing queue and writes them to the logging database.

Who does this feature apply to?

This feature applies to current users of RMS that are using the RMS logging listener service and new users of RMS with SP2 that are considering using the RMS logging listener service.

Why is this change important?

In previous releases of RMS, the RMS logging queue was protected by using access control lists, but authentication was not enabled. Without authentication, a malicious user could potentially write erroneous messages to the RMS Logging queue.

What works differently?

In RMS with SP2, additional authentication is provided on the messages transmitted by the RMS cluster by using Message Queuing. In addition to access control lists that prevent unauthorized access to the message queue, the Message Queuing queue is also protected by using a message authenticity verification mechanism. When a message is sent to the Message Queuing service, the RMS pipelines generate a hash of the message and digitally sign it by using the RMS cluster's private key. The Logging Listener Service first calculates its own hash of the message and compares it to the hash included with the message. If the hashes match, the Logging Listener Service then verifies the signature by using the cluster's public key and the hash in the message. If the hashes match and the signature is verified, the message is sent to the logging database. If the validation steps are not successful, the message is permanently deleted from the Message Queuing queue and an event warning is written to the Application log in Event Viewer.

What settings are added or changed in RMS with SP2?

New events have been added to RMS with SP2 that are designed to indicate when problem messages did not make it into the Message Queuing queue. These new events are written to the Application log and include messages that cannot be digitally signed or the digital signatures on the message cannot be validated. Some examples of validation problems include a malformed message, a missing hash or signature, or an incorrect hash or signature.

Larger Server Batching Sizes

What does this feature do?

Batching in RMS increases performance by allowing for multiple license requests to be sent to the RMS cluster as a single request as opposed to making an individual request for each license.

Who does this feature apply to?

The support for larger server batching sizes will be of interest to RMS-enabled applications that need to acquire several licenses to rights-protected content at once.

Why is this change important?

RMS batching enables a single request to be issued to the AcquireLicense RMS pipeline to get Use licenses for multiple Rights Accounts Certificates (RACs) against one or more Publish Licenses. Without a batching size larger than 1, the RMS-enabled application would have to individually request a Use license for every user individually.

What works differently?

In versions of RMS earlier than RMS with SP2, the RMS cluster supported a maximum batching size of 1. If the maximum size was set to a number higher than 1, the cluster would ignore it. With RMS with SP2, this maximum batching size can as large as 100.

Note

Only the AcquireLicense RMS pipeline includes support for batched requests.

Error reporting has been enhanced in RMS with SP2 to account for batched requests. For example, if you send a batch of ten requests and the second and third request fail, an event will be written to the event log for each failure.

Microsoft SQL Server 2005 Compatibility

What does this feature do?

In RMS with SP2, Microsoft SQL Server 2005 can be used as the database server to support the RMS configuration and logging databases without performing any additional configuration.

Who does this feature apply to?

The support for Microsoft SQL Server 2005 with RMS with SP2 will be of interest to RMS customers who want to use Microsoft SQL Server 2005 as their RMS database.

Why is this change important?

In earlier versions of RMS, data types of some of the parameters used in the sysmessages table were incompatible with the Microsoft SQL Server 2005 format specification. For more information, see article 913372 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=68638).

What works differently?

In versions of RMS earlier than RMS with SP2, SQL RAISERROR statements were used to notify the RMS user that an error has occurred. The RAISERROR statement queries the sysmessages table to retrieve the RMS error messages stored in this table. RMS with SP2 uses a different technique to propagate SQL errors so there is no longer a dependency on the sysmessages table.

Note

If you are upgrading from RMS with SP1 to RMS with SP2, the sysmessages table is no longer queried for error messages, but the error messages themselves will remain in the sysmessages table. A clean installation of RMS with SP2 will not add any new entries in the sysmessages table.

Known Issues

The following sections discuss known issues with this release of RMS.

Help file still references RMS with Service Pack 1

The help file included in the installation of RMS with SP2 still references RMS with SP1. For information about RMS with SP2, see Rights Management Services (https://go.microsoft.com/fwlink/?LinkId=68637).

Windows Update fails to install RMS with SP2 client on x64-based or Itanium-based computers

If the RMS client or the RMS with SP1 client is installed on a x64-based computer and you attempt to upgrade the client to RMS with SP2 client (x64) from Windows Update, the installation will fail. Although the previous RMS clients, which were created for 32-bit systems, worked on x64-based computers, they cannot be upgraded to the RMS with SP2 client (x64). You need to first uninstall the previous RMS client and then start the update again. Windows Update detects the version of the operating system and offers the appropriate RMS with SP2 client. The same is true for Itanium-based computers.

Reprovisioning always fails to start logging listener service

When the cluster is unprovisioned, the logging listener service fails to leave the service in a Stopped state. In order to completely stop the service, you must restart the computer.

Cannot remove non-software based trusted publishing domain

After importing a trusted publishing domain with non-software based private key implementation, it is not possible to delete it. Importing a non-software based private key should not be done from the Windows Rights Management Services Administration Console. Contact the appropriate hardware provider for instructions on how to export and import the private key.

Microsoft .NET Framework 2.0 changes IIS virtual roots when installed on the RMS server

RMS with SP2 uses the ASP.NET script mapping included with .NET Framework version 1.1. The mapping provided by later versions is not compatible with RMS with SP2. However, both versions can coexist without interference with other dependent applications. If your server has .NET Framework 1.1 and .NET Framework 2.0 or later installed, after the installation and provisioning of RMS with SP2 appears to have successfully completed, the RMS cluster might not work properly. The reason for this is that the RMS virtual roots need to be registered with ASP.NET script map version 1.1 instead of version 2.0. To register the RMS virtual roots with ASP.NET script map version 1.1, run the following command at a command prompt:

%windir%\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -s W3SVC/1/ROOT/_wmcs

Running this command will properly register the RMS virtual roots and enable RMS with SP2 to run on the server.

Group membership might be missing if using Active Directory Windows 2000 Native functional level

When deploying RMS in an environment in which the Active Directory infrastructure levels have been raised to the Windows 2000 native functional level, RMS might not be able to read the memberOf attribute of Active Directory objects when attempting to expand group membership of distribution lists that are hidden. To allow RMS to read the memberOf attribute, the RMS Service account must use a domain account that is a member of the pre-Windows 2000 Compatible Access group. For more information, see Microsoft Knowledge Base article 812841 (https://go.microsoft.com/fwlink/?LinkId=78152).

Logging listener service sends Message Queuing messages to Dead Letter Queue when database is not accessible

There are instances (for example, database is down, network connectivity issues, and so forth) where the logging listener service cannot reach the database. In this case, the messages are sent to a Dead Letter Queue. The only way to recover these messages (that is, send them to the logging database) is by using the RMS Queue Recovery tool supplied with the RMS Administration Toolkit. To download the RMS Administration Toolkit, see https://go.microsoft.com/fwlink/?LinkId=33841.

Note

Recover and RecoverandPurge have been removed from LogRecoveryCmd. This will ensure that all messages are routed back through the Message Queuing service and authenticated before the message is sent to the logging database.

You must upgrade RMS with SP2 before upgrading Microsoft SQL Server 2005

When upgrading to RMS with SP2 and from Microsoft SQL Server 2000 to Microsoft SQL Server 2005, make sure to upgrade RMS first. This will avoid any compatibility issues with the Microsoft SQL Server upgrade.

RMS with SP2 fails to provision on Web sites whose name includes an apostrophe (')

When attempting to provision RMS with SP2 on a Web site whose name includes an apostrophe character ('), the provisioning process will fail and present an Invalid parameter error message. To provision RMS with SP2 on the Web site, remove the apostrophe from the name of the Web site.

Enabling ASP.NET version 1.1 on servers running a 64-bit version of Windows Server 2003

The "System Requirements" topic in RMS Help explains how to install .NET Framework 1.1 and enable ASP.NET 1.1 after installing Internet Information Services (IIS). However, if the .NET Framework 1.1 is installed before IIS, ASP.NET 1.1 will not be listed in the Web service extensions and the documented procedure will not be useful. If IIS was installed after installing .NET Framework 1.1, run the following command at a command prompt to enable ASP.NET:

%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i –enable

When using a version of the .NET Framework later than 1.1, replace the -i with -ir in this command to avoid resetting any existing IIS script maps.

Remote forest RMS service account must be added to local groupexpansion pipeline

A security issue was fixed which removes BUILTIN\users from the ACL on the groupexpansion pipeline. This can break group expansion across forests scenarios. To solve this problem, complete the following steps:

Add RMS service account to remote forest

  1. On Forest1, where Forest1 is the RMS root cluster in the first forest, go to inetpub\wwwroot\_wmcs.

  2. Right-click the GroupExpansion folder, and then select Properties.

  3. In the GroupExpansion Properties window, click the Security tab, add the entry for Forest2\RmsServiceAccount (for example, rmil31\rmsvc), where Forest2 is the RMS root cluster in the second forest.

  4. Click OK.

  5. Click Run, type iisreset, and then clickOK.

Upgrading the .NET Framework can result in data-loss

If the .NET Framework (CLR) version 1.1 is upgraded after RMS has been installed and provisioned, the vroots are set to use .NET Framework version 2.0. If this happens, no information is logged to the logging database. This will result in data loss. Take one of the following actions:

  • Upgrade the .NET Framework prior to installing and provisioning RMS.

  • Reset the vroots to use 1.1 after the .NET Framework is upgraded.

Documentation changes in this release

Here is a list of topics that have changed in this release:

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION 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 intellectual 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 intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2006 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, MS-DOS, Visual Studio, Windows, Windows Server, SQL Server, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.