Introduction
Since the terminology-change that came with Window Server 2008 R2, the term Terminal Services is no longer applied and TS is changed into RD. The fact that people still refer to Terminal Services, although they are running the R2 edition of Windows Server 2008, still often makes things confusing. With terminology-change also came an expanded set of features and possibilities. What was called Terminal Services in Windows Server 2003 is not what we know these days as Remote Desktop Services. Not only new (server manager) roles and features have been introduced in Windows Server 2008, but Remote Desktop Services (RDS) now also comes into two flavors. There is Virtual Desktop Infrastructure (VDI), which is based on the RD Virtualization Host role, and there is Session Virtualization that is based on the RD Session Host role. Both of these flavors share many parts of the global RDS deployment of course. Roles like the RD Connection Broker, RD WebAccess etc. can be used for VDI- as well as Session Virtualization Scenario’s. In this article we will look at some ways of collecting valuable information for troubleshooting issues in RDS environments when running Windows Server 2012 (up until now Windows Server 8 Beta).
Troubleshooting the standard scenario installation
The different roles that are part of the Remote Desktop Services Platform have several log files, trace files and also event logs where information, statuses and errors are stored. This information can be rather useful when troubleshooting an installation or configuration.
The main part of this article will be around a log file that contains information about the installation and configuration process. This log file is called RDMSDeploymentUI.txt. You can find this log file on the machine where you performed the RDMS deployment. RDMS stands for Remote Desktop Management Services and is the new “plugin” that has been added to the brand new Window Windows 2012 Server Manager Console. The folder where this log file resides is %windir%\Logs (e.g. C:\Windows\Logs).
In my lab environment, I did a Scenario Based Deployment of the RDS platform. As you might remember from my previous blogs and articles, the Scenario Based Deployment is new in Windows Server 2012 and is available as an option next to the “classic” role based deployment. Scenario Based Deployment is all about installing a complete scenario instead of separate roles. There are two types of Scenario Based Deployments. There is the Quick Deployment, which installs all roles (RD Session Host, RD Web Access and RD Connection Broker) on one server, ideal for LAB and POC environments etc. Then there is the Standard deployment, which allows you to choose what roles of the three mentioned earlier you want to install on what servers. The deployment that I used for this article is a standard deployment spread over multiple servers.
After the installation finishes, (whether or not successful) the log file is created in the folder mentioned above. Let’s open up the file and analyze some of the entries that are in there.
The first thing we notice is that the servers that we want to deploy on are added to the server manager pool of servers, and this action is confirmed in the log.
ServerManager.exe Information: 0 :” 03:51:44.30: DeploymentContext: Add Server ‘RDSH01.lab.local’ to SMPool.
ServerManager.exe Information: 0 :” 03:51:44.30: DeploymentContext: Add Server ‘RDCB01.lab.local’ to SMPool.
ServerManager.exe Information: 0 :” 03:51:44.30: DeploymentContext: Add Server ‘RDCB02.lab.local’ to SMPool.
The rest of log entries in this article also start with “ServerManager.exe Information: 0 :”But I left that out to create some more space. In addition, yes, I could have also left out the time of course, but I left that in on purpose to give you some insight in how fast the deployment actually is.
We then see that the setup checks the condition of the selected servers. In my case, I selected to install both the RD Connection Broker and the RD Web Access on one server (the RDCB01), that is why it shows up twice in the log file. The RD Session Host role is installed on the RDSH01.
03:53:14.72: CompatibilityHelper.VerifyCompatibility:: hostName:RDCB01.lab.local
03:53:21.85: RdmsUI: RDCB01.lab.local is reachable.
03:53:22.80: RdmsUI: RDCB01.lab.local is domain joined.
03:53:24.38: RdmsUI: Current user is an admin on the remote server.
03:53:25.46: RdmsUI: RDCB01.lab.local version is Win8 or above.
03:53:27.58: RdmsUI: RDCB01.lab.local can be enabled to allow TS connections.
03:53:38.72: CompatibilityHelper.VerifyCompatibility:: hostName:RDCB01.lab.local
03:53:40.54: RdmsUI: RDCB01.lab.local is reachable.
03:53:41.42: RdmsUI: RDCB01.lab.local is domain joined.
03:53:42.32: RdmsUI: Current user is an admin on the remote server.
03:53:43.30: RdmsUI: RDCB01.lab.local version is Win8 or above.
03:53:51.48: CompatibilityHelper.VerifyCompatibility:: hostName:RDSH01.lab.local
03:53:53.77: RdmsUI: RDSH01.lab.local is reachable.
03:53:54.92: RdmsUI: RDSH01.lab.local is domain joined.
03:53:56.16: RdmsUI: Current user is an admin on the remote server.
03:53:57.16: RdmsUI: RDSH01.lab.local version is Win8 or above.
03:54:08.56: RdmsUI: Selected server RDSH01.lab.local don’t have pending reboots.
After that the parameters and choices made in the wizard are summed up
03:54:36.86: RdmsUI: User selected paramters for shared desktop scenario deployment.
03:54:36.86: RdmsUI: Is Rdms server already exists: False
03:54:36.86: RdmsUI: Rdms server : RDCB01.lab.local
03:54:36.86: RdmsUI: Is web access server already exists on Rdms server: False
03:54:36.86: RdmsUI: Web access server : RDCB01.lab.local
03:54:36.86: RdmsUI: RD Session Host servers :
03:54:36.86: RdmsUI: RDSH01.lab.local
03:54:36.91: RdmsUI: Adding server RDCB01.lab.local to SM refresh list
03:54:37.03: RdmsUI: Selected server RDSH01.lab.local is localhost.
03:54:37.03: RdmsUI: Adding server RDSH01.lab.local to SM refresh list
03:54:37.04: RdmsUI: View created
03:54:37.05: InstallationCompletionViewModel.Configure:: wizardInput.ManagementServer:RDCB01.lab.local
03:54:37.07: RdmsUI: Selected server RDSH01.lab.local is localhost.
03:54:37.08: RdmsUI: Local reboot is required to perform this deployment
03:54:37.09: RdmsUI: RDManagement\Set-RDSHDeployment -RDMSServer RDCB01.lab.local -RDSHServers System.String[] -RDWebAccessServers System.String[]
The setup then starts the deployment by first installing the RD Session Hole role. This role is installed first because it (yes still!) requires a reboot. You can read all the steps in the installation by following the rules in the log file that start with CommandLetExecutor. There are obviously many entries, but I copied in a few below to give you an idea of what it looks like.
03:54:52.52: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Set-RDSHDeployment – Write-Debug – -1% completed
03:54:52.55: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Set-RDSHDeployment – Install RDMS – 0% completed
03:55:11.42: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Set-RDSHDeployment – Start Installation… – 1% completed
03:56:02.02: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Set-RDSHDeployment – Start Installation… – 100% completed
After the installation of the RDSH role has taken place and the reboot is performed, we see a gap in the time (bold text). This is not because the installation took that long, but I actually waited some time before logging on again after the reboot and the wizard does not continue until you actually logon.
03:57:48.07: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Set-RDSHDeployment – Restart local computer – -1% completed
04:20:47.80: RDWorkloadWizardPlugin: IRolePlugin.Initialized…
When the wizard continues, we see the log entries that show that the other two roles (RD Connection Broker and RD WebAccess) are also added. Again, just a few entries below to give you an idea
04:21:43.58: ScenarioBasedDeployment: Job Progress Received for cmdlet: Configure RDWA Server – -1% completed
04:21:43.58: ScenarioBasedDeployment: Job Progress Received for cmdlet: Add RD Web Access Server – -1% completed
04:21:44.85: ScenarioBasedDeployment: Job Progress Received for cmdlet: Adding an RD Web Access server to the deployment – 14% completed
04:21:44.85: ScenarioBasedDeployment: Job Progress Received for cmdlet: Adding an RD Web Access server to the deployment – 14% completed
04:21:26.82: ScenarioBasedDeployment: Job Progress Received for cmdlet: Adding an RD Connection Broker server to the deployment – 20% completed
04:21:26.82: ScenarioBasedDeployment: Job Progress Received for cmdlet: Adding an RD Connection Broker server to the deployment – 20% completed
04:21:33.84: ScenarioBasedDeployment: Job Progress Received for cmdlet: Adding an RD Connection Broker server to the deployment – 40% completed
Next we see a summary of what roles have been installed on what servers.
04:22:04.35: RDMachinePool: Updating RDS Machine Pool Servers …
04:22:04.35: RDMachinePool: Server RDCB01.lab.local already part of the server machine pool. Updating role information
04:22:04.35: RDMachinePool: RDS Roles/Features installed on server RDCB01.lab.local
04:22:04.35: RDMachinePool: RemoteDesktop role installed
04:22:04.35: RDMachinePool: CB & RDMS role installed
04:22:04.35: RDMachinePool: RDWA role installed
04:22:04.35: RDMachinePool: Server RDSH01.lab.local already part of the server machine pool. Updating role information
04:22:04.35: RDMachinePool: RDS Roles/Features installed on server RDSH01.lab.local
04:22:04.35: RDMachinePool: RemoteDesktop role installed
04:22:04.35: RDMachinePool: RDSH role installed
After that, the Server Manager is being refreshed and a heartbeat signal is sent out to all servers within the scenario.
04:22:09.47: RDMSHeartbeat: Is ‘RDMS’ service running? True
04:22:09.47: RDMSHeartbeat: Is ‘WinRM’ service running? True
04:22:09.47: RDMSHeartbeat: Is ‘MSSQL$MICROSOFT##WID’ service running? True
04:22:09.47: RDMSHeartbeat: Is ‘TScPubRPC’ service running? True
04:22:09.47: RDMSHeartbeat: Is ‘WinMgmt’ service running? True
04:22:09.47: RDMSHeartbeat: All the services are running
04:22:09.47: RDMSHeartbeat: Check Heart beat every 5 minutes
As you can see, if you ever run into issues during the Scenario Based Deployment this log file can be very useful as you can drill down in great technical detail to find out where the setup stranded or generated warnings.
Troubleshooting the creation of a Session Collection
The creation of a Session Collection is also logged in the same log file. To analyze the steps taken during the creation of the Session Collection, open the log file and look for “RdmsUI: RDManagement\New-RDSHCollection”. You will see something like the following line:
To see de details related to the creation of a Session Collection search the log file for “RdmsUI: RDManagement\New-RDSHCollection”.
In the progress updates that follow you can see the different steps that are taken.
04:27:41.75: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\New-RDSHCollection – Progress : 10 – -1% completed
The event that indicated the end of the creation of the session collection is stated below
04:28:21.05: RDWizardManager: Wizard for ‘Create Collection’ completed.
Note that if you need to search the log for the name of your Session Collection, it is shorted to 16 characters inside the log file.
Troubleshooting the publication of a Remote App
The steps that are taken while publishing a Remote App are also logged in the same log file. To analyze the steps taken during publishing of RemoteApps look for the event “RDWizardManager: Wizard for ‘Publish RemoteApp Programs’ is being launched…” inside the log file.
At first, you will see some progress events that indicate that the wizard is tracking down possible applications from the start menu etc.
Job Progress Received for cmdlet: RDManagement\Get-StartMenuApplications – Get-StartMenuApps – -1% complete
After that, the wizard actually logs the amount of applications that it found initially. In my case there were 20 applications, and since this was an out of the box installation, 20 will probably be the default.
04:28:33.40: RdmsUI: 20 StartMenu Apps are fetched from server RDSH01.lab.local
The applications selected in the wizard are also logged in the log file. Below is the entry of the publication of calculator.exe, which contains all the parameters (e.g. the display name, the icon, etc.) needed for the configuration.
04:29:07.28: RdmsUI: RDManagement\Publish-RemoteApplication -RDMSServer RDCB01.lab.local -AppAlias calc -PoolName Wortell_sLab_Ses -DisplayName Calculator -AppPath C:\Windows\system32\calc.exe -ShowInPortal 1 -CommandLineSetting 0 -IconContents System.Byte[] -IconPath %windir%\system32\calc.exe -Folder $Null -VirtualPath %SYSTEMDRIVE%\Windows\system32\calc.exe -SecurityDescriptor O:WDG:WDD:ARP(A;CIOI;CCLCSWLORCGR;;;S-1-5-21-3229057419-3596798998-590496206-1107) -VirtualMachine RDSH01.lab.local
After that, the actual steps take place to publish the application and it finishes with a ‘succeeded’ entry.
04:29:09.03: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Get RDSH Pool Object – -1% completed
04:29:09.04: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Get Pool Machines – -1% completed
04:29:09.04: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Get Pool Machines – -1% completed
04:29:09.04: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Set Win32_TSPublishedApplication object on all servers – -1% completed
04:29:11.47: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Set Win32_TSPublishedApplication object on all servers – -1% completed
04:29:11.47: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Unpublish remote desktop – -1% complete
04:29:11.47: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Unpublish remote desktop – -1% complete
04:29:11.47: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Write published object to RDMS – -1% complete
04:29:12.16: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Write published object to RDMS – -1% complete
04:29:12.16: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Set FTA objects – -1% complete
04:29:12.16: CommandLetExecutor: Job Progress Received for cmdlet: RDManagement\Publish-RemoteApplication – Set FTA objects – -1% completed
04:29:12.16: CommandLetExecutor: RDManagement\Publish-RemoteApplication: succeeded
These steps are repeated for every application published. Therefore, if you published multiple applications in one action, you will see these events for every application. In my case, I published four applications at once. Further down in the log file, you’ll see a list of all applications published.
04:29:17.91: RdmsUI: RdmsModel: Added app calc to collection Wortell_sLab_Ses
04:29:17.91: RdmsUI: RdmsModel: Added app iexplore to collection Wortell_sLab_Ses
04:29:17.91: RdmsUI: RdmsModel: Added app mspaint to collection Wortell_sLab_Ses
04:29:17.91: RdmsUI: RdmsModel: Added app wordpad to collection Wortell_sLab_Ses
These are followed by a summary of all the File Type Associations (FTA’s) that are configured. I inserted a few below here to give you an idea.
04:29:17.91: RdmsUI: RdmsModel: Added FTA .gif to app iexplore and collection Wortell_sLab_Ses
04:29:17.94: RdmsUI: RdmsModel: Added FTA .bmp to app mspaint and collection Wortell_sLab_Ses
04:29:17.94: RdmsUI: RdmsModel: Added FTA .docx to app wordpad and collection Wortell_sLab_Ses
Conclusion
The extensive log file that comes with the Remote Desktop Management Services plugin for the new Windows Server Manager in Windows Server 2012 is extremely useful for debugging when something actually went wrong. Especially now that we will be using Scenario’s more and more and thus will be installing and configuring remote servers and roles from 1 single console. I have not even shown you all the types of entries in the log, but there is a lot of useful information in it. I might do a 2nd article to deep dive some more in what could go wrong during a deployment and how the log file will show you this.
