Using the Fully Qualified Domain Name for Remote Control in System Center Configuration Manager

Hello everyone, Jonathan Warnken here. I am a Premiere Field Engineer (PFE) for Microsoft. I primarily support Configuration Manager and today I want to talk about creating a custom console extension to allow the use of a Fully Qualified Domain Name (FQDN) when starting a remote-control session. If you work in a multi domain environment or need to support direct access clients you will quickly find that one of the challenges with Configuration Manager is that when it starts a remote control session it defaults to the Client name which generally matches the Net Bios name of the system. I was recently challenged by a customer wanting to simplify the management of clients connected via direct access. They had correctly configured the environment to support managing out to these devices and could complete all connected except starting remote control via the console. Remote control would work but the initial connection via the net bios name would fail and the user would need to enter the FQDN to allow the connection to complete successfully.

In all other cases when connecting to clients connected via direct access the operating system would append the correct DNS suffix. However, the Configuration Manager console would not. Starting the remote-control tool via the command line does support passing the FQDN andor the IP address. My first solution was to write a PowerShell script to take the computer name and look up the FQDN.

& $env:SMS_ADMIN_UI_PATHCmRcViewer.exe $([net.]::GetHostEntry(‘YourComputerName').Hostname)

Simple and effective but the response was that it needed to be even simpler. So after a little digging in the AssetManagementNode.xml file, I saw that two nodes exposed the remote control options via a right click in the console. For more info on finding Console Nodes see

With this info I decided to write a custom right click to run the PowerShell command. The first node started with was the devices view which has a GUID of “ed9dee86-eadd-4ac8-82a1-7234a4646e62”. After reading, I created a test action using the notepad example from the docs site and everything worked great so I made an xml file to execute the PowerShell command. And nothing happened! After some head scratching and a few expletives uttered, I realized that the ampersand (&) character is a special character for xml and must be escaped for it to be correctly parsed.

NOTE: You may need to zoom in a bit to see the screenshot. The XML content is copied below as well.



-nologo -noprofile -noninteractive -windowstyle hidden -ExecutionPolicy Bypass -Command “& { & $env:SMS_ADMIN_UI_PATHCmRcViewer.exe  $([net.]::GetHostEntry(‘##SUB:NAME##').Hostname) }”

You will also note that there is a special variable used to pass the client name. ##SUB:NAME## is the variable passed from the console to the custom action for the client name.

To use the custom action you will need to save the xml file in the XmlStorageExtensionsActions folder in path where the console is installed. Under the actions folder you will need to create a folder named the same as the GUID for the node that you would like the action to appear and save the file there. As I said earlier, there are two nodes I waned my extension to appear in. The other node I want to use is the devices in a collection node, for which the GUID is “3fd01cd1-9e01-461e-92cd-94866b8d1f39”.

With the xml in place the new right click tool is ready for action.

Hopefully, you will find this useful if you need to do something similar or need to write your own custom extension. If you would like to use mine the xml and a install script is available

Thanks for reading


This article was originally published by Microsoft's Secure Blog. You can find the original article here.