Q: My Windows Server Remote Desktop Services Connection Broker is no longer publishing applications from my Remote Desktop Session Host. What can I do?

A: Windows Server 2008 introduced the ability to publish applications over RDP to clients, which means instead of the user seeing a complete desktop on the Remote Desktop Session Host (RDSH—the new name in Windows Server 2008 R2 for what was formerly known as a Terminal Server), the user sees just the application integrated with the local desktop.

This provides a seamless user experience.

Remote Desktop Connection Broker lets applications published on RDSH to be consolidated and viewed through a single Remote Desktop Web Access server accessible via a web browser. You can see all the applications that are available across all the RDSHs and also for Windows 7 clients.

These applications can be published to users’ Start menus under the RemoteApp and Desktop Connections group (see screen shot below) and automatically updated via a feed at periodic intervals.


If you find that your connection broker is no longer getting published applications from your session hosts, you need to check a few things.

First, make sure both your session hosts and connection broker have a valid SSL certificate that hasn’t expired. If you start Internet Information Services (IIS) Manager, expand your server by clicking Sites (see the screen shot below), select your site, and select the Edit Bindings... action.


Select the https type, and click Edit. The SSL certificate will be displayed. (See the screen shot below.) Click View to verify it’s still valid!


If any of the certificates have expired, get a new certificate before proceeding.

Next, you need to make sure the connection broker is a member of the local TS Web Access Computers group on the session hosts.

After you confirm this, you can try and remove, then re-add, the session host from the connection broker by doing the following:

  1. Launch the Remote Desktop Connection Manager tool.
  2. Select RemoteApp Sources.
  3. Select the server, click Remove RemoteApp Source action.
  4. Click Add RemoteApp Source, then enter the name of your Session Host, and click OK.

Now navigate to the connection broker website and see if the published applications from the session host are available (e.g., https:///rdweb). If this works, then the problem is solved; if it doesn't, check the Event Log on the connection broker:

  1. Launch Event Viewer.
  2. Navigate to Applications and Services Logs, Microsoft, Windows, RemoteApp and Desktop Connection Management, Admin.
  3. Look for Event ID 1010, which should tell you why it’s failing.

The following is a common error:

Log Name: Microsoft-Windows-RemoteApp and Desktop Connection Management/Admin
Source: Microsoft-Windows-RemoteApp and Desktop Connection Management

Date: 11/9/2011 10:41:35 AM
Event ID: 1010
Task Category: None
Level: Error

Keywords: WMI
Computer: savdalcb01.savilltech.net
Access to the WMI interface on Remote Desktop Session Host server savdalts01.savilltech.net was denied. Add the Remote App and Desktop Management computer to the TS Web Access Computers security group on savdalts01.savilltech.net.

Error Code: 0x80070005

Basically, it’s saying the connection broker doesn’t have WMI access to the session host. It should have access, as we already confirmed the computer was in the TS Web Access Computers group on the session host.

The next step is to confirm that the WMI firewall exceptions are enabled on the session host, and the WMI/DCOM permissions are correct:

  1. Log on to the Session Host.
  2. Launch the Windows Firewall Control Panel applet.
  3. Click Allow a program or feature through Windows Firewall.
  4. Make sure Windows Management Instrumentation (WMI) is enabled for at least Domain network and click OK. If it wasn’t, then enable and retry the connection broker connection.
  5. Start the MMC console by going to Start, Run, MMC.
  6. Select Add/Remove Snap-in from the File menu.
  7. Add WMI Control for Local Computer and Component Services, then click OK.
  8. Right-click WMI Control, and select Properties.
  9. Select the Security tab.
  10. Expand Root, CIMV2, TerminalServices.
  11. Select TerminalServices, and click Security.
  12. Make sure the local TS Web Access Computers group is on the list (if it’s not then add it!), and select it. Make sure it has Allow permissions for Execute Methods, Enable Account, and Remote Enable (see screen shot below).

  13. Now expand Component Services, Computers, My Computer.
  14. Right-click, and select Properties.
  15. Select the COM security tab.
  16. For the Access Permissions section, click Edit Limits, and make sure the TS Web Access Computers group has both Local Access and Remote Access set to Allow, then click OK. (See screen shot below.)

  17. Click Edit Limits in the Launch and Activation Permission. Make sure TS Web Access Computers has all of its options set to Allow--Local Launch, Remote Launch, Local Activation, and Remote Activation--then click OK.

Also make sure the RemoteApp and Desktop Connection Management service is running on the connection broker server.

At this point, repeat the process to remove and re-add the session host on the connection broker. It should now work.

If you still have a problem, I did some research and found some people opened up the RDWebAccess application pool within the IIS Manager. Under Advanced Settings, change the Identity under the Process Model to NetworkService (see the screen shot below). However, this shouldn’t be needed, as typically it uses the ApplicationPool identity. I also found uninstalling the connection broker component off the session hosts (if it was installed) can also help. If it still doesn't work, try a reboot: I think that fixes anything!

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.