Remote Control in SCCM
System Center Configuration Manager (SCCM) 2007 offers a Remote Control feature as part of its remote tools application. A desktop administrator can have the SCCM console installed on her computer and from there remote control a computer to troubleshoot problems. I've found information regarding the Remote Control feature scattered on different places and some details can't be found or don't exist. Here I attempt to provide as much centralized information as possible, with the help of links, as well as information that may not be documented.
To use Remote Control, you have to enable and configure the SCCM Remote Tools Client Agent. Basically in the "General" tab you enable it, and on the "Security" tab you indicate who can remote control systems by adding them to "Permitted viewers".
Now you have to give the "Permitted viewers" permissions to the systems you want them to control. To do this, go to the properties of the collection that these systems are members of, and in the Security tab, grant them the following permissions for the collection: Read, Use remote tools, Read resource.
The next time these systems download their policy from the SCCM Management Point (MP), the permitted viewers will be added to their local ConfigMgr Remote Control Users group. You shouldn't manually add the users to this group.
If the users are not added automatically then you may want to check the health of that system as it may not be able to download SCCM policies.
Your desktop administrators can install the SCCM console on their machines and use it to initiate a remote control session. If the SCCM console can't connect to the SCCM database, it does not load or it hangs, you have to troubleshoot the connectivity from the remote console. Start by analyzing the SmsAdminUI.log on the desktop administrator's computer. You can find this file at
or
%ProgramFiles(x86)%\Microsoft Configuration Manager Console\AdminUI\AdminUILog
Once your console has established a connection to the SCCM database, you can proceed to administer a system remotely. If you receive a "Unable to contact host" error, ensure that any firewall from the administrator's desktop to the target system (including the Windows firewall on the target system) are allowing traffic to the ports needed by remote control. The ports for remote control connectivity, per this article, are
- TCP 2701
- TCP 2702
- TCP 135
If you are using Active Directory group policies to manage your systems, you cancreate or modify a group policy object (GPO) assigned to an organizational unit (OU) where the target systems reside. The modification would create inbound rules to allow the required remote control traffic. For more information managing GPOs, see this Group Policy Management Guide.
For example, here I'm about to modify a GPO by adding a new firewall inbound rule.
And here I show the properties of a port inbound rule created to allow ports 2701 and 2702. Note that you can use the Scope tab to allow only specific IP addresses to access your target systems on those ports.
The ports document indicate that TCP port 135 is required. However, this is the RPC end-point mapper. The RPC end-point mapper actually refers the RPC connection attempt to another dynamic port on the target system. The firewall must allow traffic to whatever dynamic port was chosen by the RPC end-point mapper. Allowing dynamic RPC traffic is a little more complicated.
You can create the appropriate inbound rule to allow traffic to port 135 and to the dynamic RPC ports. You can follow these instructions to do so, specifying "ccmexec" as the service short name. An easier way to do this is to create a Windows Firewall exception for the program rcagent.exe.
Once the Windows firewall on the target systems is allowing remote control traffic in, the desktop administrator should be able to administer remote systems. If you have problems, ensure that DCOM is enabled on the target systems. Also check the DCOM permissions on the server side.
If the desktop administrator gets "Access Denied" errors or "The currently logged-in user does not have rights to access the client machine", some troubleshooting must be done. A good place to start is by looking at the RemoteContro.log file on a target system. You'll find this log in the same folder where all the SCCM client logs are, which is
%windir%\system32\ccm\logs
or
%windir%\SysWOW64\ccm\logs
The desktop administrator does not need to be a local administrator on the target systems. She just needs to be a permitted viewer and have the appropriate permissions for the collection where the systems are. If this is all taken care of, it could be that the SCCM Remote Tools were enabled after the SCCM client was installed on the target systems. It is then possible that on the target systems, the DCOM permissions for the ConfigMgr Remote Control Users group are not set correctly.
We'll check or set the DCOM permissions for the ConfigMgr Remote Control Usersgroup by matching them with what Microsoft says the permissions should be. They are documented in the following article.
This article talks about rights and permissions on the following DCOM components:
- Remote Tools Agent component
- Remote Tools Launcher component
- Remote Tools Server component
Since there is little or no documentation about where to find these components, administrators many times set the rights and settings at the computer level, which you access by running dcomcnfg.exe:
but you'll find these components if you expand "DCOM Config" under My Computerafter you run dcomcnfg.exe:
and scroll down until you find the following components:
- SMS Remote Tools Agent
- SMS Remote Tools Launcher
- SMS Remote Tools Server
To access the DCOM permissions for a component, right-click on it, select Propertiesand click on the Security tab. For information on the steps for viewing or setting DCOM security, see the Setting DCOM Security to Allow a User to Access a Computer Remotely section in the following document.
0 comments :
Post a Comment
Comment: