Managing Workgroup (Non-Domain) Clients With Configuration Manager

If you’re using Configuration Manager to manage clients then chances are you have the Client Access Licenses (CALs) to join them to the domain.  However, for reasons that fall along the full spectrum of rational thought you may chose not to.  Whether or not Configuration Manager can manage workgroup devices is a question that comes up fairly often on the Technet forums, Reddit, Slack, what-have-you.  For the most part, Configuration Manager just doesn’t care whether your device is domain joined or not.  Like all things however, there are exceptions to that rule and I will attempt to explain them all here.  If I miss something, let me now and I’ll add it.

Network Access Accounts

Microsoft Doc: Manage accounts to access content in System Center Configuration Manager

One of the critical differences between workgroup and domain clients is how they authenticate.  Particularly, how they authenticate to the distribution points (DP) when they need to download content.  Every client will first attempt to authenticate with their local computer account.  Since workgroup clients won’t have an Active Directory (AD) object that will always fail.  The client then retries with the Network Access Account (NAA).  If you have DPs in multiple domains that don’t all trust  each other you will need multiple NAAs.  The client will cycle through them until one of them successfully authenticates to the DP they are trying to reach.  To set up your NAAs refer to the Microsoft documentation linked above.

The Network Access Accounts are sent to the clients as part of their machine policy and are stored ‘encrypted’ in a WMI class.  There’s two implications that come from this.  First, your NAAs should be true service accounts that are prevented from interactive logins to your domain devices.  Do not trust whatever ‘encryption’ Configuration Manager uses to safeguard the NAA credentials.  Second, you don’t really ever want to change the NAA’s password.  Such a change would be nearly instantaneous for the domain controllers (replication not-withstanding) but take hours for all your clients to get once you’ve updated the account in the console.  During this time they’ll be attempting to authenticate with the old, invalid password and quickly lock out the NAA account.  If you need to change the password then simply create a whole new NAA, add it in Configuration Manager, and remove the original a day or two later.

When using Network Access Accounts you’ll eventually need to troubleshoot them.  The easiest thing I’ve found to do is to grab a content URL from LocationServices.log and try to reach it.  On a domain-joined device you should just be able to download without a problem.  On a workgroup device you will be prompted for credentials.  Use the NAA account and verify that you can download the package data.  If you can’t, figure out why using normal IIS troubleshooting steps for permission issues.

Installing the Client

Microsoft Doc: How to install clients on workgroup computers

Client installation is one of the places where workgroup devices are most limited.  All of the limitations are listed in the documentation linked above but here are the two key points of interest:

• Workgroup clients cannot locate management points from Active Directory Domain Services, and instead must use DNS, WINS, or another management point.
• You cannot use the client push installation method to install the client on workgroup computers.

What this basically means is that you are going to have to figure out some way of deploying the client outside of Configuration Manager.  So hopefully you have some existing deployment solution otherwise you’re using sneakernet.  Also, clients are going to need help to figure out what Management Point to talk to in order to join your site.  There’s a few ways to accomplish this but the two I recommend are DNS or command line parameters.

Locate Management Points via DNS

Microsoft Docs: How to configure client computers to find management points by using DNS publishing

The first option is to have your clients query DNS for their Management Points (see documentation linked above).  In order for that to work of course you will need to actually publish that information to DNS using the details outlined here.  Once that’s in place you can use the DNSSUFFIX install parameter to tell the client which suffix to search for Management points:

CCMSetup.exe DNSSUFFIX=contoso.com

Specify Management Point via Installation Parameters

Microsoft Docs: About client installation properties

My preferred method is to simply tell the installer what Management Point to contact using installation parameters.  There are two properties for Management Points which can be confusing.  The first, simply /MP, tells the installer which Management Point to contact to locate the installation files.  The MP will provide a list of DPs and if the client fails to get the data from the DPs it will eventually fall back and download directly from the MP.  Multiple MPs can be listed here by separating them with semicolons.  You can skip this if you’ve included all of the source files as part of your installer package.  The second parameter, SMSMP, tells the newly installed client what MP to initially connect to.  It will reach out this this single MP and get the list of MPs available.  So your install command line will look a little like this:

CCMSetup.exe /mp:smsmp01.contoso.com SMSMP=smsmp01.contoso.com

Site Assignment

Once a client is installed and talking to a management point it must decide what site it will join.  Similar to Management Points, there’s two ways to do this.

Automatic Site Assignment via Boundary Groups

Microsoft Docs: How to assign clients to a site

The first option for assigning workgroup devices to a site is to use your boundary groups.  Since by definition workgroup devices aren’t joined to Active Directory Sites you’re going to have to use IP Subnet or Range boundaries for this.  When using automatic assignment the clients will install, discover the Management Point, and then assign themselves to the site defined for the Boundary Group they are a member of.  Remember, when using Boundary Groups for site assignment you may not overlap them.

Manually Assign Site via Installation Parameter

Call me a control freak but again my preference is to simply assign the site as part of the client installation.  To do so you simply specify the 3 digit site code using the SMSSITECODE parameter which looks a lot like this:

CCMSetup.exe SMSSITECODE=XZY

Putting It All Together: Installation Parameters

If you chose to go the installation parameter route you’ll end up with something like this:

CCMSetup.exe /mp:smsmp01.contoso.com SMSMP=smsmp01.contoso.com SMSSITECODE=XZY

Client Push: What If It Did Work?

Despite client push not being supported for workgroup devices apparently you can work around it.  Remember though, you are in fully unsupported territory here but it seems pretty harmless to me:

• Add a push account for %COMPUTERNAME%\<USERNAME> for a local use with local administrator rights.
  • Only replace <USERNAME> in the string above, leave the COMPUTERNAME wildcard as-is.
• Set the installation properties using the information above.

For full details see Peter van der Woude’s post: Using Client Push Installation on WORKGROUP systems with ConfigMgr 2012.

Approving the Client

Ok, so you’re like 15 minutes into reading this damn blog post and all we’ve managed to do is install the client and get it talking to your Configuration Manager site.  We’re ready to manage the heck of of these things … right?  Nope, not yet.  Devices that join a Configuration Manager site must be approved.  By default, devices in a domain that Configuration Manager has a trust with are automatically approved.  Workgroup devices aren’t in a domain at all let alone a trusted one so that’s not going to work.  As if it’s some sort of theme here … there’s two ways to handle this.

Manually Approving Clients

Microsoft Doc: How to manage clients

If you select a client in the console you can approve them in the ribbon or the right-click context menu.  This is very manual and sounds extremely tedious if you have more than a small handful of one-off workgroup devices.

Automatically Approving All Computers

The second option is to simply change the default configuration and allow all computers to be automatically approved.  This setting is explicitly labeled as ‘not recommended’ right there in the console so you may want to think long and hard before going this route.  I haven’t personally thought and argued my way though all the pitfalls here but one thing’s for sure: if you enable this then anyone can join any machine to your site.  I’m not quite sure why that’s bad … but let’s just assume that’s bad.  The biggest concern would seem to be the security of your service account credentials.  So if you go down this road make sure the accounts you use are true service accounts that are prevented from interactive login.  In any case, if you are simply out of shits to give then you can configure this by going to Administration / Site Configuration / Sites / Hierarchy Settings and selecting this option.

Approve Devices via a Script

Ok, so I lied.  There’s another option here which is to simply script the approval.  The only benefit I could conceive here is that you could create your own rules for validating that a client should be allowed to join your site.  I’m lazy so I didn’t look that hard but 10 seconds of searching return a script by Peter van der Woude: Approve, Block, Unapprove, or Unblock a Client in ConfigMgr 2012 via PowerShell.  That’s two links now to Peter’s stuff … must be a Dutch thing.

Upgrading the Client

Microsoft Doc: Upgrade clients in System Center Configuration Manager

As the documentation above states, there’s a few different ways to upgrade the Configuration Manager clients.  Unless you have some crazy “I’m a special little snowflake” requirements you should be using the built in automatic client upgrade process. When doing so the first thing you may chose to do is to test client upgrades in a pre-production collection to make sure the new client works as expected.  I mean let’s be real here … not every release of Current Branch has been perfect and early adopters have most certainly been bitten.  Unfortunately, your workgroup clients must be kept out of the party.  It strikes me as an odd limitation since your workgroup devices have the Network Access Account but they are unable to download the pre-production client data.  If you try they will simply repeatedly fail and continually generate failure status messages.  Once you promote the pre-production client to be the production client your workgroup devices will automatically upgrade just fine.

Other Limitations

Ok, I’ve spent roughly 1,700 words and untold minutes of your life just to get a client installed and talking to your site.  It all sounds like, and truly is, a huge pain but the good news is that we’re pretty much done here.  There’s only a few more caveats to outline.  Again, if you know of something I’ve missed leave a comment and I’ll look into it.

Deploying Software To Users

Since you can’t sync local user accounts into Configuration Manager, software can only be targeted at Active Directory users.  That precludes workgroup devices from receiving user-based deployments.

Remote Control Viewers

Related to the software deployment limitation, workgroup computers will not be able to authenticate domain users that are configured as Remote Control viewers.  You can remotely control workgroup computers, you just need to define a local account to authenticate to.  When connecting to workgroup devices you must preface the username with either the name of the device or simply ‘localhost’.  For example: ‘localhost\DGA’.  My recommendation is to create a shared local user that does not have rights to log in interactively … yet another theme here.  This allows for a widely shared set of credentials that don’t have any real rights to do anything.  You will still need a the credentials of a local account to login if the device is unattended.