Differences between Managing Domain joined and Workgroup systems

Within ConfigMgr both Domain joined and Workgroup systems can be managed. Most prefered way is Domain joined probably, where systems are trusted automatically and updated after every deployment. Still Workgroup systems are used at customers also, where you must think about local permissions and non-trusted systems. Let's have a look at my experiences so far..

When deploying Domain joined systems, the existing object in ConfigMgr is updated everytime. When looking in Resource explorer you will see History of hardware and software specifications. Domain joined systems will be trusted automatically by default. No need to think about local permissions, because ConfigMgr can install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Active Directory is used to locate management points which is very handy.

When deploying Workgroup systems, a new object in ConfigMgr will be created everytime by default. The old object will get obsolete and History of hardware and software specifications will be lost. Workgroup systems are not trusted by default, or you must choose to change that in Site Hierarchy settings. You need local permissions for sure because there's no way to install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Management points cannot be located by Active Directory.

You need a Network Access account on Workgroup systems:
-This account is used by client computers when they cannot use their local computer account to access content on distribution points. This account might also be used during OS deployment when the computer installing the OS does not have a computer account on the domain.
-For ConfigMgr 2012 R2 only: You can now specify multiple network access accounts for a site. When clients try to access content and cannot use their local computer account, they will first use the last network access account that successfully connected. ConfigMgr supports adding up to ten network access accounts.
Source: Microsoft TechNet

Let's have a look at limitations for Workgroup systems:
-Workgroup clients cannot locate management points from Active Directory Domain Services, and instead must use DNS, WINS, or another management point.
-Global roaming is not supported, because clients cannot query Active Directory Domain Services for site information.
-Active Directory discovery methods cannot discover computers in workgroups.
-You cannot deploy software to users of workgroup computers.
-You cannot use the client push installation method to install the client on workgroup computers.
-Workgroup clients cannot use Kerberos for authentication and so might require manual approval.
-A workgroup client cannot be configured as a distribution point. ConfigMgr 2012 requires that distribution point computers be members of a domain.
Source: Microsoft TechNet

In my opinion it's way better to handle Domain joined systems when management must be done after deployment. More stable and easier for quick communication. There are a few tricks however to get things automated. Just have a look at them for more information:
-Remote Control on Workgroup systems
-Client Push Installation on Workgroup systems
-Support on Workgroup systems

Remote Control functionality in ConfigMgr 2012

Remote Control functionality is much better in ConfigMgr 2012. In ConfigMgr 2007 it was already a widely used feature, but it will be more used now! This because Remote Control functionality has more options available, which are very good.

The first one is named "Send Ctrl+Alt+Del key". In ConfigMgr 2007 it was not possible to remote Control a device, which was not logged-on. Then the Remote Desktop Protocol (RDP) was used to logged-on a device. It was also not possible to logout and logon with another user (for example: Administrator account). This functionality is available in ConfigMgr 2012 now!

The second one is named "Enable Clipboard Sharing", which becomes very handy when copy and paste actions must be done. Most of times this functionality is needed during troubleshooting a device.

The third one is named "Lock remote Keyboard and Mouse". When Remote Control a device now, there can be set a lock on the remote device. Then a user logged-on the device, cannot use his/her own keyboard and mouse during the remote session anymore.

Don't forget to configure the "Default Client Agent Settings", which is needed to have it all functional. Most settings are configured by default here. Only Permitted viewers must configured to users which receive the "Remote Control" rights. Other settings can be configured in this screen as well.

All functionality named here is very useful. So I will repeat my line from start: Remote Control functionality is much better in ConfigMgr 2012.

Remote Control functionality in ConfigMgr console

Most of times during a ConfigMgr 2007 implementation, there will be Delegation of Control configured. This will be done beneath Security Rights -Users/Rights in the ConfigMgr console. At that place there can be different roles configured, for example: Administrators role, Support role or Reporting role. But what to do when only Remote Control functionality is needed? In this blog I will explain what to do for configuring Remote Control in ConfigMgr.

Remote Control functionality is build-in with the ConfigMgr client. Check Site Management > Site Settings > Client Agents > Remote Tools Client Agent for configuring settings and security.

Most of time I choose this settings at General tab:

Beneath Security, Users and Groups must be added for Remote Control functionality:

This will add users and groups in the registry of all clients and servers managed within ConfigMgr 2007: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control

In the Notification tab there are multiple choices for configuring:

Most of times I don't configure settings beneath the "Remote Assistance" and "Remote Desktop" tab. These are not needed for Remote Control functionality!

Now set security in the ConfigMgr console, by going to Security Rights -Users/Rights in the ConfigMgr console. Add a new user or group for having Remote Control rights.

I've created a RemoteControl user for this blog:

 Choose to add another right or modify an existing one:

I put rights here to use Remote Tools on every collection:

Configuring is done, and the user/groups has now access rights:

For using the Remote Control functionality in ConfigMgr console now, all you hace to do is install (or virtualize) this console, and offer it to the rights users. Default the whole console will be displayed, and only the parts which you have access to, can be managed/used. You can also building a custom ConfigMgr admin console, which has for example only collections in it. See this URL for building one yourself: http://scug.be/blogs/sccm/archive/2008/07/16/building-a-custom-configmgr-2007-admin-console.aspx

Another way for giving specific users access to Remote Control functionality, is build a package with only 2 (two) files in it. This will be RC.exe and Rdpencom.dll (both can be found at ConfigMgr source > AdminUI > Bin > i386 location. Just distribute these files, and make sure security is done in the ConfigMgr console, and you're done!

The only real difference in both solutions will be the search option. In the ConfigMgr console > Collections, there can be searched in All Systems for the device which must be taken over. In the single RC.exe file solution, a name must be typed-in for having Remote Control functionality.

Remember that firewall rules must be added for having Remote Control functionality on the client when firewall is active. Otherwise an error message will follow, with a "Unable to connect" message. See this URL for used ports in ConfigMgr 2007: http://technet.microsoft.com/en-us/library/bb632618.aspx

Hope I make things clear with posting blogs like this!