Fixing RDS when it has been improperly deployed

In the last few articles I walked you through setting up RDS (Remote Desktop Services) in a domain, or a workgroup, and installing and activating CALs.  Today I wanted to touch on how to fix RDS when it has been improperly deployed.  The good news, it is typically very easy.

Typically when RDS is deployed improperly the user has installed the Session Host manually via the add roles wizard.  While this is fine in a workgroup, it does not work properly in a domain environment.  If this is the case, just running the Remote Desktop Services installation wizard is typically enough to fix the deployment.  Just follow this guide.  I have had about 90% success rate with this.

But what if the Remote Desktop Services installation wizard fails or does not complete? Don’t fret.  More than likely the issue can still be resolved without removing the roles.  Below are the two most common issues that I have run into when fixing an RDS deployment.

1. The Remote Desktop Services installation wizard fails to create the Session Collection and remote apps.  Usually when this happens it is because the user has attempted to fix the installation with Group Policy.  There are two legacy group policy settings  for specifying the license server and license mode.  These settings  are not supported in 2012, do not work, and will cause the Session Collection wizard to fail.  The fix is simple, remove the group polices.  Set them to Not configured.  Here is a screen shot of what the policies should look like and their location.
   Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing
2. The Connection Broker role service role fails to deploy and the Remote Desktop Services installation wizard indicates the server requires a restart.  Rebooting the server and running the wizard will again indicate a reboot is required.
   The first time I ran into the this issue it took me a bit of time to track it down.  After rebooting the server and checking for the file C:\windows\winsxs\pending.xml, and not finding it.  Additionally, checking the c:\windows\log\cbs\cbs.log and seeing that a reboot is not pending, I was confused.  I then dug deeper into the cbs log and found that the installation was being rolled back and that roll back required a restart.  So why was the install failing?  The key is an error logged in the system log during the install.

   Log Name:      System Source:
   Service Control Manager
   Event ID:      7041
   Level:         Error
   Description: The MSSQL$MICROSOFT##WID service was unable to log on as NT SERVICE\MSSQL$MICROSOFT##WID with the currently configured password due to the following error:  Logon failure: the user has not been granted the requested logon type at this computer.

   Service: MSSQL$MICROSOFT##WID  Domain and account: NT SERVICE\MSSQL$MICROSOFT##WID

   This service account does not have the required user right “Log on as a service.

   The Connection Broker service requires a SQL database to store its data.  By default it uses the WID (Windows Internal Database).  Because the WID cannot start, the Connection Broker role service install fails and the install has to be rolled back.  This typically only occurs when the RDS server is also a domain controller.  It is possible though on a member server if security has been tightened.  The fix is fairly easy and is documented in Microsoft KB 2832204.   Because this typically occurs on a domain controller though, you cannot simply edit the local group policy or the local security policy.  You must create a new GPO (Group Policy Object) and link it to the domain controllers container.  Here is the process.

   1. On a domain controller, launch the group policy management console.  (gpmc.msc)
   2. Expand Forest, Domains, your domain name, then Domain Controllers.
   3. Right-click on the Domain Controllers container and choose Create a GPO in this domain and Link it here.
   4. Give the GPO a descriptive name like “Allow WID logon on DC” and click OK.
   5. Right click the new GPO and choose Edit.
   6. Navigate to the following location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
      
   7. Right-click on Log on as a service and choose Properties.
   8. Check the box to Define these policy settings.
   9. Click on Add User or Group and add the following user: NT SERVICE\ALL SERVICES
   10. Click OK and close the Group Policy Management Editor window.
   11. To make the setting take effect immediately, run gpupdate /force at an administrative command prompt.

If the above solutions did not resolve the deployment issues with RDS, there is another option.  If all else fails, remove all RDS role features* and start the deployment over again.  As bad as this sounds it typically only takes 30-60 minutes to remove the roles and redeploy correctly.

If I missed anything, please submit a comment below.  Thanks for reading.

* If Licensing has been configured and RDS CALs (Client Access Licenses) added, it is typically best to not remove the licensing role feature.  That is unless you enjoy calling the Microsoft clearinghouse. 🙂