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