This article covers the case of invisible RemoteApp programs, or, no RemoteApp programs listed on the RD Web Access site.

Recently, I was working on a case and while every setting was in place, we were unable to see the remote applications on the web page. When we were trying to add the name of the Remote Desktop Session Host server in the Source name field for the One or more RemoteApp sources option on the RD Web Access page configuration tab, we were getting the following error: “RD Web Access was not able to access <RD Session Host server name>. Verify that the RD Session Host server name was entered correctly, that the server is running and connected to the network, and then try again.”



After looking at the error message, I confirmed the following:

• I had the name of the RD Web Access server in the TS Web Access Computers group on my RD Session Host server.
• RemoteApp programs were published and visible on the RD Web Access site.
• The certificate was bound to the RemoteApp programs.
• I was able to ping from one server to another.

Then I thought that it could be an issue with the WMI because the RD Web Access server queries the list of applications on the RD Session Host server. I checked WMI locally and remotely on both computers, and it was working. I checked the WMI-Tracing event logs on both computers, but couldn’t find anything. I even tried to run the non-RDS WMI calls between the two computers and it also worked fine.

After exhausting all my resources, I thought that I should enable RDWEB tracing (will discuss later in this article) and see if I could get something out of it. On reproducing the error message, the following message appeared in the RDWEB.log:

[Warning] ManagementException from PingServerWMI(rds1):Access denied

This message clearly showed me that something was wrong with the WMI calls made from the RD Web Access server to the RD Session Host server.

Then I opened the WMI console (wmimgmt.msc) on the RD Session Host server and navigated to the Security tab, under CIMV2, to TerminalServices and Security.

After pulling the information from the Security button for the TerminalServices node (see the following figure), I found that the TS Web Access Computers group was missing. It shocked me, because without this group being there, the RD Web Access server would be unable to fetch any information from the RD Session Host server. (It might be possible that the account existed, but with the wrong permissions.)

I re-added the TS Web Access Computers group, making sure that I added the group locally.

The preceding image shows that I tried to add the group under the Domain location, but it should be added to the Local location.

After adding the group, it was the permissions that mattered. Ensure that TS Web Access Computers is in the list with the Execute Methods, Enable Account, and Remote Enable check boxes set to "Allow."

After this, we were all set, and on trying again, I was able to add the RD Session Host server without any problems, and was able to view all the RemoteApp programs.

Additional resources

To use RDWEB Tracing

1. On the RD Web Access server, open the Web.config file (default location is %windir%\web\rdweb\web.config).
2. Set the Trace level to Warning:
   1. Search for: <add name="TraceTSWA" value="0" />
   2. Change the value from “0” to “2” to generate warnings:
      <add name="TraceTSWA" value="2" />
3. Set the Trace mode to file tracing:
   1. Find the block that starts with: <!-- Uncomment for file tracing
      <add name=”File Log”
      -->
   2. Delete the start and end comment lines (the lines starting with <!-- and -->) to make the code work.
4. Log on to RD Web Access and reproduce the issue.
5. Open the generated trace file (default location is %windir%\web\rdweb\App_Data\rdweb.log) and look for any suspicious errors or warnings.

Troubleshooting DCOM/WMI, with respect to Remote App programs on the RD Web Access site

We use WMI to communicate with the RD Session Host server. Various issues can cause WMI to deny access or return error codes. Here are a few things you can try:

1. Check if the TS Web Access Computers security group on the RD Session Host server has incorrect permissions in DCOM and/or WMI:

   

To check DCOM security settings:

A.      Start the Component Services MMC snap-in.

B.      Navigate to Component Services -> Computers -> My Computer.

C.      Right-click My Computer, and the select Properties.

D.      Go to the COM Security tab.

E.       Under Access Permissions, click Edit Limits.

F.       Ensure that TS Web Access Computers is in the list, with all of the permissions set to “Allow.”

G.     Under Launch and Activation Permissions, click Edit Limits.

H.      Ensure that TS Web Access Computers is in the list, with all of the permissions set to “Allow.”

To check WMI security settings:

A.      Start the WMI Control MMC snap-in.

B.      Right-click WMI Control, and then select Properties.

C.      Click the Security tab.

D.      Navigate to Root->CIMV2->TerminalServices.

E.       With TerminalServices selected, click Security.

F.       Ensure that TS Web Access Computers is in the list with the Execute Methods, Enable Account, and Remote Enable check boxes set to "Allow." 

2. Verify that the RD Session Host server's firewall allows WMI calls.

3. Verify that the RD Connection Broker server hasn't lost its trust relationship with the domain.

4. Determine if non-RDS related WMI calls can be successfully made to the RD Session Host server. This can help differentiate between a general WMI issue
and an issue calling the RDS WMI provider.

—Pankaj Pande