How-To: Manipulate Hyper-V VM Symbolic Links (or How to Unregister and Register Virtual Machines without Deleting Them)

How-To: Manipulate Hyper-V VM Symbolic Links (or How to Unregister and Register Virtual Machines without Deleting Them)

Hyper-V operates using a list of symbolic links in a specific directory:

·         C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines

Each of these are links to the actual VM configuration files in their own respective subdirectories – whether stored locally or on shared storage, the link doesn’t change in its nature.

All you need to know in order to control which VMs are displayed in Hyper-V Manager follows:

1.   First you need to identify the GUID of the specific VM.  Look in the directory location for the VM you wish to manipulate and note the name of the .XML file in the Virtual Machines subdirectory.

 

     Our example will use the LitwareSpeech VM, located at D:\VMs\LitwareSpeech.  In the “D:\VMs\LitwareSpeech\Virtual Machines” path is the configuration file for this VM, named “D546B942-76AF-4C3B-97C6-9EE74828BC91.XML”

2.   To delete the reference to this VM in Hyper-V Manager, browse to “C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\” and locate the symbolic link that is named after the VM GUID.  Deleting this link only deletes the reference to the VM in Hyper-V Manager – it does not delete the actual configuration of the VM or the VHD.

 

Note

The path “C:\ProgramData” is a hidden directory path.  See “Viewing Hidden Folders” section later to complete these steps, if necessary.

 

3.   To later restore the reference to the VM, browse to the location, “C:\ProgramData\Microsoft\Windows\Hyper-V” and Shift-RightClick on the Virtual Machines directory.  Select Open Command Window Here.

4.   Using the VM GUID that you determined above in Step 1, run the following command:

mklink <GUID>.XML <VMConfigPath.XML> or in our example

mklink D546B942-76AF-4C3B-97C6-9EE74828BC91.xml “D:\VMs\LitwareSpeech\Virtual Machines\D546B942-76AF-4C3B-97C6-9EE74828BC91.xml”

This restores the reference to your VM in Hyper-V Manager.

 

The catch to this operation that I’ve learned is that when you create a VM, Hyper-V creates a security entry (ACE) on this symbolic link for the SID of the worker process for the VM.  Unfortunately, this ACE isn’t re-created when you recreate the symbolic link using mklink as detailed above.

If you try to start your re-registered VM at this point, you’re likely to receive this error message:

 

To address this requirement, follow these steps:

1.   Again, locate and note the GUID of the VM.

2.   Using this GUID, run the following command:

icacls “C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\<GUID>.xml” /grant “NT VIRTUAL MACHINE\<GUID>“:(F) /L

 

Or in our example from above:

icacls “C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\D546B942-76AF-4C3B-97C6-9EE74828BC91.xml” /grant “NT VIRTUAL MACHINE\D546B942-76AF-4C3B-97C6-9EE74828BC91”:(F) /L

3.   This process regenerates the necessary ACE on the symbolic link using the Service SID of the VM, rather than on the configuration file itself, replicating the initial state of the symbolic link.

4.    Once this command has been run successfully, you should be able to start your VM without further issues.

 

 

Viewing Hidden Folders

1.   Open Windows Explorer.  Select Tools, Folder Options…

  

2.   Select the View Tab and choose the option to “Show hidden files and folders”

3.   Click OK.

 

 

Migrating the AD RMS Databases

This post documents the steps necessary for moving the back-end SQL Server databases for your AD RMS installation to another SQL Server instance / server.  The steps for successfully updating the AD RMS server nodes differ from the process used for Windows RMS as originally outlined in this TechNet article: http://technet.microsoft.com/en-us/library/cc747607.aspx

 This post is essentially a re-write of the article mentioned, with all the steps updated to reflect the correct procedure to follow for AD RMS database migrations…enjoy!

–Ryan

 

There are instances in which a database server needs to be retired. An AD RMS database server hardware upgrade is one example. Before the database server is retired, the configuration database must be moved to a different database server. To protect the data in the configuration database, including the key pairs that it contains, you should carefully plan and implement a migration.

Microsoft recommends creating a CNAME alias for the AD RMS database server and then configuring AD RMS to use this alias. This eliminates the need to manually change the database server name in the AD RMS configuration database if the name of the server changes. When using a CNAME alias, you would only have to update the alias record.

Before you begin the configuration database migration, ensure that you have the following information:

  • The account name and password that was originally used to provision the servers in the AD RMS cluster that use this database.
  • If a software-based cryptographic service provider (CSP) is used for storing the AD RMS private key, the AD RMS private key password that was originally specified during provisioning. If a hardware security module (HSM) is used to store the RMS private key password, this step is not required.

Note

Migrating the configuration database does not require a new server licensor certificate or a new server private key because AD RMS retains the settings from the original configuration database.

 

You should back up the AD RMS databases before doing anything on the database server. If this is not an option, you must, at a minimum, export your server licensor certificate. For more information about exporting the server licensor certificate, see To Export Your Server Licensor Certificate to a File. If an error occurs when the databases are migrated, you can import the server licensor certificate into a new RMS installation and consume content that was rights-protected with the older installation.

To migrate a configuration database, use the following steps:

  • Update the AD RMS configuration database to reflect the name of the new database server name.
  • Update the registry on each server in the AD RMS cluster to use the new database server name

 

 

Important

This topic assumes that the AD RMS databases have already been copied to the new database server hosting the AD RMS databases.

 

1.    Stop the AD RMS Logging Service either through the Services interface or by typing net stop AdRmsLoggingService at a command prompt.

2.    Stop IIS services (IIS Admin Service and World Wide Web Publishing Service) either through the Services interface, through Internet Information Services (IIS) Manager or by typing IISRESET /stop at a command prompt.

 

The name of the database server that is hosting the AD RMS databases is stored in the AD RMS configuration database. After the database files have been migrated to the new database server, you must update the AD RMS configuration database. This can be done by using either the RMS Config Editor tool from the RMS Administration Toolkit or by using SQL Management Studio.

To update the AD RMS database server name by using RMS Config Editor, use the following steps:

To update the AD RMS configuration database by using RMS Config Editor

  1. Log on to an AD RMS server in the cluster as member of the System Administrators database role.
  2. Install the RMS Administration Toolkit from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=98961).
  3. Navigate to %SystemDrive%:\Program Files\RMS SP2 Administration Toolkit\RMSConfigEditor, and then double-click RMSCONFIGEDITOR.EXE.
  4. In the Server box, type the name of the new server hosting the AD RMS configuration database, and then click Go.

Note

Windows Firewall, in its default configuration will not permit the RMS Config Editor program to successfully connect to the target database server / instance.  You must either disable Windows Firewall (not recommended) or add an exception for the RMS Config Editor program directly (recommended).

 

  1. In the Database box, click DRMS_Config_<RMS cluster name>_<Port>, where <RMS cluster name> is the name of the RMS cluster and <Port> is the TCP port on which RMS communicates, and then click Go.
  2. Click DRMS_ClusterPolicies.
  3. In the results pane, change the value in the PolicyData column of the LoggingDatabaseServer row to the new RMS database server name.
  4. Click Persist.
  5. Change the value in the PolicyData column of the CertificationUserKeyStorageConnectionString row to reflect the new database server. The value should be data source=<new database server name>;integrated where <new database server name> is the name of the new database server.
  6. Click Persist.
  7. Repeat steps 9–10 for the value in the PolicyData column of the DirectoryServicesCacheDatabase row.
  8. Close RMS Config Editor.

To update the AD RMS configuration database by using SQL Server Management Studio, do the following steps:

To update the AD RMS configuration database by using SQL Server Management Studio

  1. Log on to the AD RMS configuration database server as local Administrator or another user account that is a member of the local Administrators group.
  2. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.
  3. On the Connect to Server page, ensure that the new database server name is listed in the Server name box, and then click Connect.
  4. Expand Databases, expand DRMS_Config_<RMS cluster name>_<Port>, and then expand Tables.
  5. Right-click DRMS_ClusterPolicies, and then click Open Table.
  6. In the results pane, change the value in the PolicyData column of the LoggingDatabaseServer row to the new RMS database server name.
  7. Change the value in the PolicyData column of the CertificationUserKeyStorageConnectionString row to reflect the new database server. The value should be data source=<new database server name>;integrated where <new database server name> is the name of the new database server.
  8. Repeat steps 6–7 for the value in the PolicyData column of the DirectoryServicesCacheDatabase row.
  9. Close Microsoft SQL Server Management Studio.

To configure each server in the AD RMS cluster to use the new database server name, you must update three registry entries. Once this is complete, you must restart Internet Information Services (IIS) for the changes to take effect.

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

To update the registry on each server in the AD RMS cluster

  1. Log on to a server in the AD RMS cluster as a member of the local Administrators group.
  2. Click Start, and then click Run.
  3. Type regedit.exe, and then click OK.
  4. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdRMSLoggingService\Params.
  5. Change the ConnectionString and LoggingDatabaseServer registry entries so that the data source value matches the new database server name.
  6. Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS\2.0\ConnectionString.
  7. Change the ConfigDatabaseConnectionString registry entry so that the data source value matches the new database server name.
  8. Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS\2.0\KeyProtection
  9. There is a REG_BINARY Value here that starts “PASSWORDDERIVEDKEY_<name of your old SQL Server here>“.  Rename this Value to match the new database server name.
  10. Repeat steps 1–9 for every server in the AD RMS cluster.

 

1.    Start the RMS Logging Service either through the Services interface or by typing net start AdRmsLoggingService at a command prompt.

2.    Start IIS services (IIS Admin Service and World Wide Web Publishing Service) either through the Services interface, through Internet Information Services (IIS) Manager or by typing IISRESET /start at a command prompt.

How-To: Remove Crashed or Dead AD RMS Nodes from the cluster

I recently went through this procedure in my Test Lab environment, while planning for the Production implementation. 

Migrating from a much older version of Windows Rights Management Services (RMS) to Active Directory Rights Management Services (AD RMS), I was left with a couple of older RMS servers that needed to be manually removed from the RMS cluster.

Here are the steps:

Use the RMS Config Editor (part of the Rights Management Services Administration Toolkit with SP2):

http://www.microsoft.com/downloads/details.aspx?familyid=bae62cfc-d5a7-46d2-9063-0f6885c26b98&displaylang=en , and follow these steps:

1. Enter the name of the database server in the Server field (i.e. – Server_Name\SQL_Instance)
2. Select the DRMS_Config_<servername>_80 Database in the database dropdown field
3. Choose the DRMS_ClusterServer entry in the left-hand pane and you’ll see the names of all your RMS Servers – past and present
4. Click the arrow next to any row you want to remove and hit the Delete key (no delete button within the interface)
5. Finally, and perhaps most importantly, at the top right, under Actions: you must click the “Persist” button to commit the changes to the SQL database.

Refresh your RMS console and voila!  The crashed / dead RMS server node is gone (under Properties, AD RMS Servers Tab)!

You might want to take the appropriate / necessary precautions prior to performing this little bit of surgery.  Consider stopping the AD RMS Logging service and IIS on each active RMS Server and try to confirm that there are no connections to the RMS Databases (through SQL Enterprise Manager or SP_who2 in SQL Query Analyzer) and at least take a backup of all three RMS Databases, just in case, right?  🙂

Hope this helps,
–Ryan