This article is for those who are attempting to deploy Active Directory Rights Management Servili>
This article is for those who are attempting to deploy Active Directory Rights Management Servili>
Why are new instructions needed to cover AD RMS deployment for Windows Server 2008 R2 SP1 with SQL Server 2012?
Specifically, if you try to deploy AD RMS in Windows Server 2008 or Windows Server 2008 R2, you will not be able to complete role deployment using a SQL Server 2012 intallation as expected. This is because SQL Server 2012 does not contain a stored procedure, sp_dboption, that the legacy AD RMS deployments require and are expecting to be present. A hotfix is available for AD RMS that can be applied to your Windows Server 2008 R2 SP1 installation to workaround this issue and utilize SQL Server 2012.
Note
The hot fix described above only applies to Windows Server 2008 R2 SP1. For earlier versions of Windows Server, no hot fix is available.
Install the AD RMS server role using Windows PowerShell.
Open an elevated Windows PowerShell prompt and run the following command to load the Server Manager cmdlet module.
Import-Module ServerManager
Enter the following command to install the AD RMS server role. (Note: include the -IncludeAllSubFeatures switch if you also want to add the Identify Federation Support role feature.)
Add-WindowsFeature ADRMS
Deploy the AD RMS cluster using Windows PowerShell.
Open an elevated Windows PowerShell prompt and run the following command to load the AD RMS deployment cmdlet module.
Import-Module ADRMS
You can then use Windows PowerShell commands as needed to complete the AD RMS deployment process. For an example of the types of command that are necessary to deploy an AD RMS cluster, you can refer to the following example set of commands.
Import-Module ADRMS
New-PSDrive -PSProvider ADRMSInstall -Name RC -Root RootCluster
# Set the AD RMS service account
$adrmssvc = Get-Credential
Set-ItemProperty –Path RC:\ -Name ServiceAccount -Value $adrmssvc
# Configure the AD RMS server to use the SQL1 server and the default instance
Set-ItemProperty –Path RC:\ClusterDatabase -Name ServerName -Value SQL1
Set-ItemProperty –Path RC:\ClusterDatabase -Name InstanceName -Value MSSQLSERVER
# Securely store the cluster key password string in a variable and assign it to your AD RMS installation
$password = Read-Host -AsSecureString -Prompt "Password:"
Set-ItemProperty -Path RC:\ClusterKey -Name CentrallyManagedPassword -Value $password
# Set the AD RMS cluster address
Set-ItemProperty -Path RC:\ -Name ClusterURL -Value http://app1.corp.contoso.com:80
# Set the SLC name for your AD RMS installation
Set-ItemProperty -Path RC:\ -Name SLCName -Value "APP1"
Set-ItemProperty -Path RC:\ClusterKey -Name CentrallyManagedPassword -Value $password
# Register the SCP connection point
Set-ItemProperty -Path RC:\ -Name RegisterSCP -Value $true
# Install the AD RMS root cluster using the settings provided
Set-Location RC:\
Install-ADRMS –Path.
For more information on using AD RMS cmdlets for Windows PowerShell, see Using Windows PowerShell to Deploy AD RMS and AD RMS Cmdlets in Windows PowerShell.
Issue - After an administrator creates (or join upgrades) a cluster using WS2008 R2 SP1 AD RMS (with the hotfix) to SQL 2012, they cannot join other WS2008 R2 SP1 servers (with the hotfix) to that cluster. When they run the PowerShell cmdlet to set the DatabaseName value to the DRMS_Config_<cluster>_<port> database, they will get this error:
Validating Config Database Info. Returning message :AD RMS cannot join the specified cluster because the root cluster computer is running a later version of Windows Server than this computer. Upgrade this computer to the same version of Windows
Server (or later) as the root cluster computer before attempting to add the AD RMS role to this computer.
Cause - When the first server creates (or join-upgrades) the cluster, it sets the AdRmsFileVersion to 6.1.7601.21820 because of the hotfix. The default AdRmsFileVersion for WS2008 R2 SP1 is 6.1.7601.17514. When the second server tries to join a cluster, the joining code expects the version to be the default 6.1.7601.17514, but it sees 6.1.7601.21820. So the code blocks setting the DatabaseName to that cluster.
Workaround - Administrators can manually reset the AdRmsFileVersion value back to 6.1.7601.17514 and the joining code will not block setting the DatabaseName. Note that the second join will also increment the version number, so customers will have to reset it again before joining any other R2 SP1 servers to that database.