Windows Server 2008 Beta 3 is the best build to use to dogfood the latest functionality available in RMS. Listed below is a list of know issues ib Beta 3.
AD RMS Installation Issues
· AD RMS cannot be installed on a domain controller
AD RMS on Windows Server 2008 Beta 3 cannot be installed on a computer acting as a domain controller. You must install AD RMS on a member server. This issue will be resolved in a later build of Windows Server 2008.
· Hardware Security Module (HSM) Compatibility
If a Hardware Security Module (HSM) is being used to protect the AD RMS cluster key, please check with your hardware vendor to ensure the drivers are compatible with Windows Server 2008 Beta 3.
· The AD RMS service connection point (SCP) is not registered correctly
When registering the AD RMS SCP during installation, it is not set correctly, which prevents AD RMS clients from connecting to the AD RMS cluster. To correct this issue, you should reset the SCP by using the Active Directory Rights Management Services console:
1. Open the Active Directory Rights Management Services console.
2. Right-click the AD RMS cluster, and then click Properties.
3. Click the SCP tab.
4. Select the Change SCP check box.
5. Click the Set the SCP to current certification cluster option, and then click OK.
6. Click Yes to confirm.
· Additional steps required for an in-place upgrade of AD RMS from a previous version of RMS
When doing an in-place upgrade of Rights Management Services (RMS) with Service Pack 1 or Service Pack 2 to AD RMS in Windows Server 2008 Beta 3, you must manually start the upgrade wizard:
1. After Windows Server 2008 Beta 3 is installed, go to %WINDIR%\system32\rms
2. Double-click UpgradeWizard.exe
3. Complete the steps in the wizard to complete the installation
· Microsoft Office SharePoint Server 2007 and AD RMS cannot be installed on the same computer.
Installing Microsoft Office SharePoint Server 2007 and AD RMS on the same computer is not supported.
· AD RMS installation fails with error “Error>: Attempt to configure Active Directory Rights Management Server failed. The system cannot find the path specified.”
This is an issue that will be resolved in a later build of Windows Server 2008. In order to work-around this issue, please complete the following steps:
1. Uninstall AD RMS by using Server Manager.
2. Click Start, type Regedit, and then type Enter.
3. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IISAdmin.
4. Right-click IISAdmin, point to New, and click Key.
5. Type Parameters, and then type Enter.
6. Right-click Parameters, point to New, and then click DWORD Value.
7. Type LazyWriteTIme, and then type Enter.
8. Double-click LazyWriteTime.
9. In the Value data box, type 0, and then type Enter.
10. From a command prompt, type IISRESET, and then type Enter.
11. Install AD RMS again by using Server Manager.
· AD RMS installation fails with error “Error. Fail to decide certificate hierarchy”
If an existing service connection point (SCP) for RMS exists in Active Directory and you choose to register a new SCP during the AD RMS installation, you will receive this error message. To workaround this issue, you should remove the SCP from Active Directory and install AD RMS again. You can remove the SCP by using the ADScpRegister.exe tool included in the RMS Administration Toolkit (http://www.microsoft.com/downloads/details.aspx?FamilyID=bae62cfc-d5a7-46d2-9063-0f6885c26b98&DisplayLang=en).
CAUTION Before removing the SCP, verify that RMS is not already installed in your organization.
· AD RMS is unable to validate the database name during installation
During AD RMS installation, you may receive an error message that you cannot validate the AD RMS database. If you are selecting a database that uses a named SQL Server database instance, ensure that the SQL Browser service is running on the database server.
· IIS port binding is not modified when installing AD RMS
If you select a different port on the “Specify Cluster URL” page during the AD RMS installation, the port binding is not applied to Internet Information Services (IIS). This issue is by design to ensure that any applications already installed will continue to work normally. To specify the port bindings, please go to Internet Information Services (IIS) Manager to update the bindings with the port that was specified during AD RMS installation.
AD RMS Operational Issues
· Errors when trying to administer AD RMS after installation has completed.
1. Before you can administer AD RMS, you must log off of the computer and then log back on. This is required to update your security token to include the AD RMS Enterprise Administrators group. You cannot administer AD RMS on this computer until this has been completed.
2. When trying to administer AD RMS by using the Active Directory Rights Management Services console, you may receive an Access is Denied error message. To correct this issue, reboot the server and then open the console again. This will be resolved in a later build of Windows Server 2008.
3. During the AD RMS installation, if you choose to install an SSL certificate later, you cannot open the Active Directory Rights Management Services console until the SSL certificate has been installed by using the Internet Information Services (IIS) Manager. If you are using a self signed certificate, you will need to import the certificate on to the computer running the Active Directory Rights Management Services console.
4. The Active Directory Rights Management Services console crashes when you click Open New Window from Here from within the Health Reports node of the console. This will be resolved in a later build of Windows Server 2008.
Cannot import a Trusted Publishing Domain (TPD) exported from a Windows Server 2008 Beta 3 cluster to a previous version of RMS.
This will be resolved in a later build of Windows Server 2008.
We are running a series of webcasts on Identity and Access solutions from Microsoft beginning in November and going on through March 2007. These webcasts will include a lot of technical information on RMS as well. Some more details below
Microsoft offers a broad range of technologies and products to enable a customer’s identity and access infrastructure. This web-cast and virtual lab series is designed to educate Technical Decision Makers (TDMs), and IT Professionals about Microsoft’s IDA solution areas centered around the following products:
- Windows Rights Management Services (RMS)
- Active Directory Federation Services (ADFS)
- Microsoft Identity Integration Server MIIS)
- Certificate Lifecycle Manger (CLM)
- Active Directory (AD)
These webcasts are structured under different categories. The categories take attendees from Product/Solutions Overview, what the product is and how it can help the customer’s infrastructure, to Deployment, and through the different categories to, “What is New for the Future”.
To register for any of these webcasts, including our kickoff webcast: “Identity and Access Vision and Strategy”, visit this link: IDA Webcasts
We will be adding more webcasts to this list, so please be sure to visit this site again!
Hope you find this useful
Mayur
If you are using the Windows Firewall shipped with Windows Server 2003 Service Pack 1, you probably already know that you must create firewall exceptions on each server in your RMS environment in order for RMS to function correctly. If not, read on.
When the Windows Firewall is turned on, it blocks all unsolicited inbound packets to the server. Depending on how your RMS environment is configured, several firewall exceptions must be created. Let’s run through the different scenarios:
On your Active Directory domain controllers, you must create exceptions for TCP ports 389 (used for LDAP queries to Active Directory) and TCP 3268 (the communication port for the Active Directory global catalog server). These ports exceptions are the minimum that RMS requires. It is likely that if the Windows Firewall is enabled on a domain controller several other non-RMS related ports will have to be opened as well.
On the RMS server, you must open either TCP port 80 (used for HTTP communication) or TCP port 443 (used for HTTPS). If SSL is used in your RMS environment, you should use TCP 443.Otherwise, use TCP port 80.
If your Logging database is on the same server as your RMS installation, you don’t have to create any additional port exceptions. However, if they are installed on different servers, you will have to open TCP ports 1433 and 445. TCP port 1433 is the default port for the SQL server listener and TCP port 445 is the port used for provisioning the SQL server via Named Pipes.
It’s very important to scope these exceptions correctly. If you are not using RMS outside of your organization’s network, you should scope the firewall in such a way that all packets destined to these ports are dropped from computers that are not on your organization’s network. However, if you are using the RMS Extranet cluster URL, it is likely that the RMS port (either TCP 80 or TCP 443) will need to be exposed to the Internet. Additionally, TCP port 445 should never be allowed on the Internet since this is also the file sharing port for all operating systems Windows 2000 and later.
Feel free to let us know what you think by posting comments.
Brian Lich
Let’s say that you decide that you want to enable SSL on your RMS pipelines after RMS is provisioned. It is recommended that you decrypt all RMS-protected content, re-install and re-provision RMS, and then encrypt the content again. However, this is not always possible.
One alternative option is to provision a new RMS environment and redirect all of your RMS clients to use this new license server. Before we see how to do this, there are several assumptions made about your RMS environment:
- The RMS deployment is configured with a software-based Server Licensor private key. This scenario will not work if you’re using an HSM to secure your RMS server’s private key.
- An SSL certificate is already installed and configured to require SSL encryption within IIS on the RMS vroots.
- The existing RMS database and servers have been backed up and the tapes stored in a safe place. Just in case… J
- Because this requires that a registry entry is added to every RMS client, you must have a way to update the clients. Preferably through some automated fashion but a new pair of sneakers would work too.
Whew! Now for the fun stuff. To enable SSL in your RMS environment after the RMS server has been provisioned, you should follow these steps:
- Provision a new RMS server using the HTTPS option for the Intranet Cluster URL.
- Configure the old server as a Trusted User Domain on the new server. For instruction on this, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/1c96ee74-fd28-4511-be21-087e2b04c3ee1033.mspx
- Configure the old server as a Trusted Publishing Domain on the new server. For more information on this, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/1c96ee74-fd28-4511-be21-087e2b04c3ee1033.mspx
- Add a new String Value named LicenseServerRedirection registry entry to all of your RMS clients. The registry entry should be added to HKCU\Software\Microsoft\Office\11.0\Common\DRM. The value of this entry should be set to the name of the new server in the format of https://NewRMSServer/_wmcs/licensing.
- Update your Active Directory Service Connection Point to the new server. This can be done manually or via the ADScpRegister utility available from the RMS Toolkit. NOTE: You must be a member of the Active Directory Enterprise Admins group to do this.
- Retire the old RMS server.
The method described in this blog post have not been fully tested and may lead to undesirable effects. For example, rights policy templates and trusted user domains will not be transferred using the steps outlined in this post. The recommended method to enable SSL after RMS is provisioned is to do the following:
- Back up the publishing certificate
- Remove the service connection point (SCP) from Active Directory
- Unprovision RMS
- Provision RMS again using HTTPS
- Register the new SCP
- Import the publishing certificate
- Modify the LicenseServerRedirection registry on all RMS-enabled client to point to reflect this change
Feel free to let you know what you think by posting comments. Your feedback is welcomed.
Imagine this scenario. You are about to catch a plane. You connect to Internet using a Wi-Fi spot on the airport and sync your Outlook. It’s a long flight and you want to catch up on email during the flight. You jump on the place and when the nice airhostess announces that you can use your portable electronic devices, you pull out your laptop and start reading your email. Now imagine you have a RMS-protected email in your Inbox. Since RMS requires the client to present credentials to the RMS server to get a use license before you can consume the content, you are not able to read that important email.
Here is the solution. If you use Outlook 2003 in cached mode, you can set the Outlook client to automatically license all RMS-protected emails during sync. This way you can ensure that all protected emails in your Inbox have corresponding use licenses downloaded and hence can be viewed. Now you can have a good flight!
P.S. Outlook in cached mode should do the above automatically. If it is not doing so, the Registry entry that controls this behavior is:
Hive: HKEY_CURRENT_USER
Key: Software\Microsoft\Office\11.0\Outlook
Type: REG_DWORD
Entry: UserData
Value: 0x00000001
If this is not set, or the entry doesn’t exist, create it and logoff and log back on.
If you have any questions, leave it in the comments section and we will get back to you
RMS is designed as a solution to allow digital enforcement of content usage policies. And like any other solution, one can follow some best practices to ensure that the service is running in a secure manner. Here are a few suggestions from the product team
- Deploy RMS web services as https – not http. Particularly for external services, deploying as https protects privacy of the RMS credentials that are sent back and forth in licensing requests, and importantly secures the authentication of certification requests. Additional security for authentication can be enabled by requiring https with client authentication, not just the standard server authentication, and requiring smartcards.
- The default protection for RMS server private keys is a software-based protection. For added protection, Hardware Security Modules can be used for key protection off the server. Many varieties of HSM can be used, but two specific vendors who have done testing with RMS are Safenet (Luna HSM) and nCipher
- Avoid email address recycling. This ensures that users (who may otherwise get the recycled email address of an authorized user) do not get access to protected content that they shouldn’t have access to.
- Disable hibernation on desktops. You never know what is encrypted in memory and what is not. :-)
- Use Windows integrated authentication to access SQL as it is stated in the installation guide.
- ACL the pipelines appropriately. If you are not allowing Passport-authenticated users, you might want to have authentication of the licensing pipelines as well.
- Minimize the number of services on RMS Servers. This is a recommended practice for defense-in-depth strategy.
- The group of RMS administrators and the Superuser group should be an AD restricted group.
- RMS service account should be used, as opposed to any system account, to run RMS. It should not be granted any additional special privileges. Also, be sure to isolate the RMS server by not running other applications on it. Sharing the RMS server with other applications may put RMS keys, and hence content, at risk
- Since Office applications currently use the content of the Active Directory email attribute, or alternate SMTP proxy addresses, associated with a user as that user’s unique identity, be sure to protect this field in AD. Do not allow users in your AD to change this attribute, and inquire about the protection of this attribute before importing other organizations’ RMS servers into your list of trusted RMS domains.
- When making RMS services available to the internet, you can offer advanced protection by using an application layer firewall. Rather than just opening port 443, ISA server (or potentially other application layer firewalls) can inspect the https traffic by terminating the https connection at the firewall and re-establishing a separate connection internally, once the traffic is inspected. This is a best practice when internet-enabling any web based application.
Again, the above is not an exhaustive list, but can serve as a good starting point for understanding how to deploy RMS in a secure manner. If you have more specific questions, please leave us a comment here or join our newsgroup and we will do our best to answer them
First post in the 'Ask John' series
Question
We have deployed RMS on single server and wants to migrate ( move ) RMS to another server. Of course we do not want to lose previous permissions. What is the best way for it ?
John says:
It can be very simple, as long as the following two conditions are met:
1) The Intranet Cluster URL is a FQDN (or a non-machine name); and
2) The database is on a separate server.
If these conditions are met simply build a new server to replace the existing RMS Server, install the RMS Server software on it, and elect to join an existing cluster. You will be prompted for information such as the database server FQDN and the name of the Configuration database. The name of the Configuration database will be DRMS_Config_IntranetClusterFQDN_replacing_dot_with_underscores_PortNum where PortNum is 80 or 443 depending on whether or not you use SSL. Once the cluster has been established, update DNS to point to the new system and turn off the old system (do not put it into Decommission mode, which is something entirely different). I would not destroy the old system until you have tested the new system by obtaining RACs, CLCs, and EULs.
If the two conditions above are not met, especially #1, your best bet is to create a brand new RMS installation using a FQDN for the Intranet Cluster URL and a separate database server (also use a FQDN when specifying the name of the database server), export the SLC, private key, and templates from the existing server and import them to the new server as though creating a Publish Trust. You will then have to add Publish Trust overrides to the Registry of each RMS Client. Turn off the old system and test the new system and the established Publish Trust before destroying the old system. Note that if you have published the serviceConnectionPoint in AD you will need to override the provisioning page URL when you choose to install RMS on this server, replacing ProvisionLicensing.aspx with ProvisionCertification.aspx. You will have to deregister and reregister the serviceConnectionPoint from the new system. A simpler approach is to deregister the serviceConnectionPoint from the old system prior to provisioning the new system and register it from the new.
We are starting a series of posts called "Ask John". John Howie is one of the most knowledgeable people on configuring, managing and using RMS. In his current role, John is the director of security communities and in the past has led the MCS (Microsoft Consulting Services) team working on RMS projects. A lot of technical questions are posted on our internal aliases and John usually has the answer. I am going to compile the questions which may be useful to this audience. If you have any questions, leave them in the comments and I will make sure John gets them
The first post in this series will debut tomorrow
Mayur Kamat
The following describes about how to detect the presence of the RMS client and server. Detection may be necessary in certain deployment scenarios where the appropriate action to take depends on whether or not an RMS product is installed.
Two detection methods are documented: one using registry keys and another using the MsiEnumRelatedProducts API. You may use either method to detect RMS products. We provide two detection methods because deployment tools differ in detection capability. Use the detection method appropriate for your deployment tool.
Finally, note that the registry keys and upgrade codes used for product detection depend on the version of the RMS product you are trying to detect. If you are interested in detecting all versions of an RMS product, then you would need to use methods from both sections below; in other words, you would need to use a method from section 1 for products released prior to SP1 and a method from section 2 for SP1 and newer products.
1: How to Detect Versions of the RMS Client and Server Released Prior to SP1
RMS Client
via regkey
- Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{EC905264-BCFE-423B-9C42-C3A106266790}
- Key: Version
- Type: DWORD
- Comparison: Value in key is less than 0x05010000.
via MsiEnumRelatedProducts
- Upgrade Code: {A53746F2-DE8B-4BCF-8CDB-4F18C7313FC1}
- Property: INSTALLPROPERTY_VERSIONSTRING
- Comparison: Version is less than 5.2.7.
RMS Server
via regkey
- Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{E3FF64B7-99F3-4FC9-9A76-389FF31350C3}
- Key: Version
- Type: DWORD
- Comparison: Value in key is less than 0x05010000.
via MsiEnumRelatedProducts
- Upgrade Code: {5C943502-8F11-469C-BE89-1FFED1D38B77}
- Property: INSTALLPROPERTY_VERSIONSTRING
- Comparison: Version is less than 5.2.7.
2: How to Detect SP1 and Newer Versions of the RMS Client and Server
RMS Client
via regkey
- Path: HKLM\SOFTWARE\Microsoft\udrm
- Key: Version
- Type: string
- Comparison: Value in key is greater than or equal to 5.2.3790.134.
via MsiEnumRelatedProducts
- Upgrade Code: {A3B78BBF-B6DB-4578-B7B0-B30B75A77C77}
- Property: INSTALLPROPERTY_VERSIONSTRING
- Comparison: Version greater than or equal to 5.2.7.
RMS Server
via regkey
- Path: HKLM\SOFTWARE\Microsoft\WindowsRightsManagementServicesServer
- Key: Version
- Type: string
- Comparison: Value in key is greater than or equal to 5.2.3790.134.
via MsiEnumRelatedProducts
- Upgrade Code: {5C943502-8F11-469C-BE89-1FFED1D38B77}
- Property: INSTALLPROPERTY_VERSIONSTRING
- Comparison: Version greater than or equal to 5.2.7.
Notes:
1. “HKLM” is an abbreviation for “HKEY_LOCAL_MACHINE”; use HKEY_LOCAL_MACHINE when forming registry paths.
2. If you need to detect the presence of an RMS product on a 64-bit OS, you will need to use the Wow6432Node branch of the registry if your deployment tools are 64-bit tools. For example, to detect the RMS SP1 client on a 64-bit OS, instead of you would use HKLM\SOFTWARE\Wow6432Node\Microsoft\udrm instead of HKLM\SOFTWARE\Microsoft\udrm.
The RMS server records every license request.
What is recorded?
- The user account cert (RAC/GIC)
- The content issuance license (contains an encrypted list of all user/groups that are granted rights and what rights they are granted)
- The use license issued to the user. (contains an encrypted list of the rights that the user is granted)
Once the client has the use license no other activity is recorded unless the use license contains a policy that requires users to re-license the content (either every X days or every use). There is no logging on the client side of when and what rights used. The tool in the RMS Toolkit, RMSLogAnalyzer can be used to process the verbose server logs into a much more usable format that can then be used for audit tracked (though as stated before the server only knows about the license issued, not how many times it was used etc). The issuance license can be manually pulled from either the content or the RMS logging database. The tool in the RMS Toolkit, RMS CertAnalyzer can be used to decrypt the issuance license to view who has what rights to the content.
Note: Outlook 2003 can be configured so that when it receives an RMS protected e-mail it will automatically request a use license for it. This is done to enable viewing of the content at a later date when the user might not have connectivity. Because of this the fact that the RMS server has issued the user a use license does to translate to the user has view the content.
A few members of the RMS team will be in Orlando this week for TechEd 2005. If you’ll be at TechEd this year, please stop by and meet us!
Learn about RMS
- RMS SP1 Overview and Opportunities – June 9th, 1:30-2:45pm in room N 310 H.
- Rushmi Malaviarachchi, RMS Program Manager, will speak on RMS, what’s new with Service Pack 1 and the opportunities for developers with RMS SP1.
- We’ll also be offering two small group technical drill downs and Q&A on RMS – June 8th & 9th, Exhibit Hall, Microsoft Cabana
See RMS in Action
- RMS will be demo’d during Microsoft Corporate VP-Security Gordon Mangione’s keynote – June 6th, 10:45am
- Test-drive RMS and create and send rights-protected e-mails – RMS booth (#61), Exhibit Hall, Microsoft Pavilion
Set-up RMS
- With RMS self-paced hands on labs (HOL), learn how simple it is to set-up and deploy RMS.
We hope to see you there!
This post is to aid RMS SP1 beta customers who would like to migrate their RMS Enterprise Server deployments from the RMS SP1 Beta to the RMS SP1 RTW product. Technically the 'upgrade' itself is not supported and not a true upgrade. However in order to perform this task and have the ability to preserve and open RMS protected content that was previously established within the RMS SP1 Beta timeframe, the product team has built a small utility and some very specific steps that allows this to occur.
You will still need to contact us at <
mailto:rmsbeta@microsoft.com> in order to obtain the utility that cleans up the RMS SP1 beta server.
Instructions:
The beta release of Microsoft® Windows® Rights Management Services (RMS) Service Pack 1 (SP1) used the Windows Components Wizard to install RMS SP1 as an optional component of Windows Server 2003. However, the final release of RMS SP1 uses the Microsoft® Windows® Installer to install RMS SP1 instead of the Windows Components Wizard.
These two different setup procedures use different logic and a component that is installed by the Windows Component Wizard cannot be modified by another setup procedure, which means that the RMS SP1 (Final) Windows Installer cannot effectively remove the RMS SP1 Beta. Therefore, if you attempt to upgrade a server running RMS SP1 Beta to the final release of RMS SP1, the server will run both RMS SP1 Beta and RMS SP1 final versions and both will be available for use by RMS clients.
To remove the beta version of RMS SP1 cleanly, the RmsSp1Cleanup.bat utility is being provided to the customers that participated in the RMS SP1 beta. You must complete the procedure described in this document to remove the RMS SP1 beta release before you install the final version of RMS SP1.
Before you perform the procedure, ensure that you are able to restore the current configuration if necessary by backing up your RMS SP1 Beta configuration database. It is recommended that you preserve the following information along with your database backup should it be necessary to restore the RMS SP1 Beta in case of failure:
· The name of the backup copy of the database.
· The name of the computer on which the backup database is located.
· The account name and password that was originally used to provision RMS SP1.
· The password that was originally specified for software private key protection (if it was used).
Before you begin
Before using the RmsSp1Cleanup.bat utility, make sure that the following conditions are met:
· To run this utility, the logged on user must be a member of the Administrators group on the local computer or have the equivalent permissions (this is required to delete information from the registry and certain assembly files).
· Run this utility only on the RMS SP1 Beta version. If Rights Management Services does not appear in the Windows Components Wizard, do not run this utility.
· Make sure that no Windows Rights Management Server node resides under Add/Remove Programs - if so please select to also remove this application.
· The Windows Component Wizard should be closed before running this utility.
· Download the Windows Resource Kit Tools from the Microsoft Web site <
http://go.microsoft.com/fwlink/?LinkID=20334> (http://go.microsoft.com/fwlink/?LinkId=20334). Place the iniman.exe tool in the same folder where the SP1 Clean up utility (RmsSp1Cleanup.bat) will reside.
How to
The following procedure describes the steps that must be completed to successfully remove the RMS SP1 beta:
To Remove the RMS SP1 beta
1. Open the RMS Administration Web site and click the Trust Policies link.
2. In the Trusted user domains area, click the Export button to export the server licensor certificate to a file.
3. In the Trusted publishing domains area, click the Export link next to the key container for this server to create a trusted publishing domain file.
Note:
You will specify a location to which to save the file and password with which to protect this file. Note this information so that you can import this file to your new RMS installation.
4. From the Global Administration page of the RMS Administration Web site, select Remove RMS from this server to unprovision RMS.
Note:
If you have multiple front-end Web servers for the RMS cluster, you must unprovision RMS on all of these servers before proceeding.
5. Close the RMS Administration Web site.
6. From Add or Remove Programs in Control Panel, click Add/Remove Windows Components to open the Windows Components Wizard.
7. Clear the check box next to the entry for Rights Management Services and then click OK.
8. Close the Windows Components Wizard.
9. Copy INIMAN.EXE from the Windows Server 2003 Resource Kit Tools into a desired location or folder.
10. Copy the RmsSp1Cleanup.bat utility into the same folder as INIMAN.EXE
11. Run the RmsSp1Cleanup.bat utility
12. After it finishes, the utility displays a command script that flashes on the screen. The command prompt window closes after the script finishes.
13. Connect to your database server and delete the configuration (DRMS_Config), directory services (DRMS_DirectoryServices), and logging (DRMS_Logging) databases. The database schema used in the RMS SP1 Beta is not compatible with the final version of RMS SP1.
14. Install the final version of RMS SP1.
15. Provision RMS SP1 on the server.
16. Open the RMS Administration Web site and click the Trust Policies link.
17. In the Trusted user domains area, click the Browse button and locate the server licensor certificate file that you exported in step 2 and then click the Add button to establish the trusted user domain.
18. In the Trusted publishing domains area, click the Browse button and locate the trusted publishing domain file that you exported in step 3 and then in the space provided type password need to decrypt the file and then click the Import button to establish the trusted publishing domain.
Note:
Steps 19 through 22 only apply if you have multiple front-end Web servers for the RMS cluster.
19. To upgrade all remaining front-end Web Servers in the RMS cluster, repeat the following steps on each of the remaining front-end Web Servers.
20. Repeat Steps 6 through 12 to Remove RMS Sp1 beta from the front-end.
21. Install the final version of RMS SP1.
22. Join the front-end to RMS cluster created in step 15.
More Information
If the RMS SP1 beta was installed as an update to RMS version 1.0, there will be duplicated assemblies present in the global assembly cache (GAC) that were not removed during the RMS SP1 Beta update. This utility will attempt to remove those assemblies that remained; however, it may be useful to verify that this was successful.
If the utility did not successfully remove the assemblies, you must remove them manually. To safely remove the assemblies, type the following command at the command prompt:
gacutil /u myDll ,Version=1.1.0.0,Culture=en,PublicKeyToken=874e23ab874e23a
In this command, myDll is the name of the assembly you want to remove from the GAC.
You can query on the specific DLLs by referencing the \Windows\Assembly folder.
You can also find out more information about gacutil.exe by typing gacutil.exe /? at the command prompt.
Any customized tools being used in conjunction with the RMS databases will need to be reconfigured.
Upgrading an RMS SP1 Beta database is not supported.
Chris Borkenhagen,
Software Test Engineer Lead
We've just posted the first RMS SP1
hands-on lab to the Microsoft Technet Virtual Labs site (http://www.microsoft.com/technet/virtuallab/).
For those of you not familiar with
Technet Virtual Labs, these free hands-on labs offer a great,
low-overhead way to try out Microsoft technologies (in this case RMS) with
hardly any setup or technical infrastructure requirements. Just a one-time registration step (select a
username and password and fill in some information on a web form) and a single
ActiveX component installation are all you need.
When you start the lab, you will get
a downloadable lab manual with step-by-step instructions and a 90-minute time
window to complete the lab. The user
experience is similar to accessing a system remotely via Terminal
Services.
The lab takes you through RMS
deployment and configuration steps, as well as end-user scenarios. It includes access to Windows RMS SP1,
Windows Server 2003, Office 2003 Professional, Windows XP, ADSIEdit and RMS
Toolkit tools. You will be directed
through the following modules:
-Provisioning and Enrolling an RMS
Server
-Installing the RMS Client Software
-Protecting Information Using RMS
-Configuring RMS Policy Templates
-Configuring and Using the RMS
Toolkit
Go ahead and give it a try. The direct link to the lab is http://www.microsoft.com/technet/traincert/virtuallab/rms.mspx.
As always, we would love to hear
your feedback.
Windows Rights Management Services (RMS) is a technology that allows critical information to be protected consistently throughout the content lifecycle. Traditionally, information has been protected by restricting access to it. RMS can be considered as an augmenting technology that embeds the access and usage information in the document itself. So no matter where the content resides, the protection stays with the content. There have been a number of enterprises that are using RMS to help secure their enterprise content like emails, documents and internal web content.
But that doesn’t mean that only large enterprises can utilize the value of RMS. There are several scenarios in which small businesses or even individuals can use the functionality of RMS. I am going to outline a few of these scenarios and then show how these users can utilize the IRM – Information Rights Management (RMS implementation by Office 2003) to enable secure collaboration.
Scenario 1 – Small Business
Partner is a small research firm that specializes in market research for certain verticals. All employees at Partner have Microsoft Office 2003 Pro installed which they use for authoring and collaboration features. Every month, Partner releases a market report which goes out to its subscribers (around 20). Since this is a high-value intellectual property, Partner wants to ensure that the content is accessible to only its registered subscribers and is not forwarded or distributed to unauthorized parties.
Scenario 2 – Freelancer
Matt is a freelance presentation designer. He designs presentations for special occasions and is frequently recruited by individual and agencies to design custom presentations. Matt has noted that lately few of his presentations are being sold on the web as design templates by unscrupulous entities. He wants to ensure that his clients use the presentation for their own purpose and that the content expires after 2 months.
The above scenarios (and many more) can be enabled without having to deploy (or be part of) an enterprise RMS solution. All you need is Microsoft Office 2003 Professional and a Microsoft Passport account. Here is a step-by-step process for enabling IRM scenarios
Create a document/email using Word/Excel/Powerpoint/Outlook (Office 2003 Professional) as you normally would
- Once the content is created, click on the Permissions button on the standard toolbar (it has a red Do Not Enter (-) sign)
- A Wizard will pop-up asking you to select your credentials. Since you are not an enterprise user, select the Passport option (note that this is a one-time process per machine)
- You will be prompted to enter your passport sign-on information (Note: If you do not have a Passport account, you can sign-up for one)
- After you have signed on, you will be certified as a valid user for that Passport account
- You can then use the IRM functionality in office to send protected content to any other user. You can use the More Options (Not available in Outlook) tab to set more granular permissions (like content expiry, specific rights, etc). If the recipients do not have a passport account, they would need to go get a Passport for their email address.
- If the recipients do not have Office 2003, they can download the RMS addon for IE, which allows users to read RMS content inside the browser.
So if you have Office 2003 Pro, do give RMS a try. It is a different way of securing information. And do let us know how your experience with RMS was.
Mayur Kamat, Program Manager
Over time, customers have asked us how RMS compares to or interoperates with S/MIME or PGP. This post will briefly address this issue without going into too much technical detail.
First, there are some important similarities between these technologies:
-
Every email or document that RMS handles is encrypted with state-of-the-art AES. RMS does not simply enforce DRM-style permissions on content users, like many believe – it also helps protect the content against unauthorized third party “eavesdroppers.”
-
In addition, entities involved in the RMS-protected document workflow (such as RMS servers and end users) have RSA public-private key pairs in order to enable the distribution of protected documents more securely.
Now let’s look at what is different:
-
PGP key management and exchange is mostly ad-hoc while with RMS it is the RMS server that manages user keys and key exchange is server-mediated and happens automatically; RMS offers better centralized management of users and keys and is easier to deploy
-
S/MIME is limited to email, while RMS, as used by Microsoft Office, offers you the ability to protect various document types and store them wherever you want
-
PGP offers the widest selection of encryption algorithms, most of which are not FIPS approved and standardized (e.g. CAST, IDEA) and there is no standardized front end or API making PGP (or its open source counterpart GPG) more confusing and more difficult to use (but also more flexible for a small group of power users)
-
RMS always needs connectivity to an RMS server the first time a protected document or email is opened, while PGP, due to its decentralized nature, does not need server presence
-
PGP and S/MIME offer sign-only no-encryption modes while with RMS content is always encrypted
As far as interop goes, from within Microsoft Outlook, which today is the main mail app that uses RMS, you can apply both RMS policy and S/MIME protection on the same email, e.g. you can create a “Do Not Forward” email that you sign with your S/MIME certificate. Interop between RMS and PGP is more implementation dependent, based on what PGP/GPG front end plugin you use. At the very least, you ought to be able to attach a PGP-encrypted file to an RMS-protected mail, much like you can attach any doc in an RMS protected mail.
Clearly, there is more to discuss here, and you should read some more about RMS, PGP, and S/MIME online in order to appreciate the similarities and differences between these technologies. I can post some more information in the future if there is interest on this topic.
Ivan Davtchev,
Program Manager
