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

Network Access Account in ConfigMgr 2012

Last week I installed ConfigMgr 2012 at a customer location and did some default configuration in it also. I've configured Software Updates, Exchange Connector and Endpoint Protection. Today I started with Operating Systems and imported Windows 7 source files to Build and Capture a reference image. This on a Hyper-V host to build a driver free reference image.

When starting the Build and Capture task sequence, errors where displayed almost immediately after starting it. These are the error messages seen:

- GetMPLocation failed (0x80004005)
- Failed to Run Task Sequence (0x80070057)
- Failed to query http://xxxxx for MP location

On most forums I read that I need to configure the Network Access Account right and create Boundary Groups to get the job done. But I configured everything right, why still the error messages where displayed?

So I checked the Network Access Account again. Just go to the Software Distribution Component properties for that. By default the following is selected: "Use the computer account of the Configuration Manager client". That way it didn't start the task sequence at all. I changed it to "Specify the account that accesses network locations" and selected my Network Access Account.

Beneath Security - Accounts is possible to edit the account credentials again. Strange enough when verifying the account it was running fine. Test connection to different shares where all okay. Because I didn't trust it, I changed it to a totally different password and still the account verification was fine. How is that possible?

Long story short, I typed in the password again and started the Build and Capture task sequence another time. All was running fine now! It was my password which wasn't correct, but there's no way to see that? ConfigMgr let you know all is running okay, and "Test connection" will let you see that "The connection was successfully verfied". Even with a bad password! (a bug maybe?)

I think there's something really strange with the Network Access Account password verfication. Maybe it's functionality is not good in the RTM version? Because in Beta2/RC the same thing cannot be done. Then the following error message will be displayed: "The specified network password is not correct"

Hopefully this will be fixed by Microsoft at a later time.