The purpose of this test lab guidance is to enable you to understand how to setup SQL mirroring within an Active Directory Rights Management Services (AD RMS) infrastructure in a test environment.
This process assumes familiarity with the base AD RMS lab setup that is described in the Test Lab Guide: Deploying an AD RMS Cluster and that in turn leverages the base Active Directory domain setup from the Windows Server 2012 Base Configuration Test Lab Guide.
To complete this lab setup you will need the same four VMs that are described in the AD RMS base TLG (DC1, APP1, SQL1, CLIENT1). To those four VMs, you will add a fifth VM, SQL2, which will be used to accomplish the SQL mirroring of the AD RMS databases. You will also need to create an additional domain user account, SQLSVC, to be used as the SQL Server service account.
Although the configuration details will be similar to those described in these previously referenced TLGs, the following modified software and hardware requirements are necessary for both SQL server installations (SQL1 and SQL2) in order to accomplish the SQL mirroring configuration as described in this TLG:
Steps to accomplish SQL Mirroring
// To register the service account for the FQDN of the SQL servers.
Setspn –A MSSQLsvc/<SQL1 FQDN> <domain>\SQLSVC Setspn –A MSSQLsvc/<SQL2 FQDN> <domain>\SQLSVC Setspn –A MSSQLsvc/<SQL1 common name> <domain>\ SQLSVC Setspn –A MSSQLsvc/<SQL2 common name> <domain>\ SQLSVC
Troubleshooting Tips:
To verify the AD RMS configuration you can follow the process described in Step 4: Verify the AD RMS Configuration after you complete the configuration in the AD RMS base TLG.
DRMS_Config_<cluster>_<port>
DRMS_DirectoryServices_<cluster>_<port>
DRMS_Logging_<cluster>_<port>.
(The servers involved in a database mirroring session must trust each other. This means that each SQL Server instance login must have rights to connect to the other mirroring server—to the endpoints of the other SQL server instance. This is done by creating a login on each server for the mirroring server’s login. Because SQL1 and SQL2 are using the same service account for their logins, this step was skipped.)
Troubleshooting:
GRANT CONNECT ON ENDPOINT::Mirroring TO [<domain>\SQLSVC]
GO
SELECT * FROM sys.database_mirroring_endpoints
[HKLM\SOFTWARE\Microsoft\DRMS\ConnectionString]
"ConfigDatabaseConnectionString"="Data Source=SQL1; Failover Partner=SQL2; Integrated Security=SSPI;Persist Security Info=False;Packet Size=4096;Database=DRMS_Config_<cluster>_<port>;"
Execute query on the principal to update three policy values:
(Insert real names for brackets: cluster, port, SQL1, SQL2)
USE DRMS_Config_<cluster>_<port> GO UPDATE dbo.DRMS_ClusterPolicies SET PolicyData='data source=<SQL1>;failover partner=<SQL2>;integrated security=SSPI;persist security info=False;packet size=4096;database=DRMS_Config_<cluster>_<port>' WHERE PolicyName='CertificationUserKeyStorageConnectionString' GO UPDATE dbo.DRMS_ClusterPolicies SET PolicyData='data source=<SQL1>;failover partner=<SQL2>;integrated security=SSPI;persist security info=False;packet size=4096;database=DRMS_Config_<cluster>_<port>' WHERE PolicyName='DirectoryServicesCacheDatabase' GO UPDATE dbo.DRMS_ClusterPolicies SET PolicyData=<SQL1>;failover partner=<SQL2>;initial catalog=DRMS_Logging_<cluster>_<port>' WHERE PolicyName='LoggingDatabaseServer' GO
To verify the AD RMS configuration you can repeat the process that was used in previous steps (as described in Step 4 in the AD RMS base TLG).
ALTER DATABASE DRMS_Config_<cluster>_<port> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS GO ALTER DATABASE DRMS_DirectoryServices_<cluster>_<port> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS GO ALTER DATABASE DRMS_Logging_<cluster>_<port> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS GO
To verify the AD RMS configuration, repeat the same process that was used in previous steps.