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.
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.
Great article Pankaj !
Thanks Freek... :) :)
I had this exact thing happen and followed the same thought path you guys did and discovered the same thing that the local group was missing. What I also noticed was the SID was showing in the WMI security page and not the resolved one. After removing the SID and re-adding the name security group it did not happen again after multiple reboots.
The real question is what caused to happen in the first place? I am guessing it might have been my broker lost its trust in the domain transiently as the time offset between the DC and the server was sufficient for Kerberos to break. I have solved the time offset issue so I will keep an eye on this and comment if it happens again.
Thx for the article. We experienced the same sympthom.
Our fix (workaround) was to switch from a FQDN to the netbios name. Afterwards the FQDN also worked perfectly, again.
I havent checked the permissions ...
RD WEB and RD Connection Broker runs on the same machine. both Names resolved to ::1
Any Hints what happened there ?
"Verify that the RD Connection Broker server hasn't lost its trust relationship with the domain." HOW? HOW? HOW? HOW? HOW? HOW? HOW? HOW? This is the problem with these stupid articles. They assume that I'm an MCSE, and I'd never waste my money on a shitty entitlement like that.
I followed this article and what ended up fixing it was a suggestion from Martin Forster > Using the HOST name and not the FQDN somehow resolved my issue. I was banging on this server for hours trying everything that I could think of. Thanks Martin!