7/2/2014 Update: This article is also posted on the Microsoft Configuration Manager Support Team Blog at http://blogs.technet.com/b/configurationmgr/archive/2014/07/01/managing-workgroup-clients-in-system-center-2012-configuration-manager.aspx. I have recently added some additional details to this page that are not yet posted on the team blog.


In this post I discuss key points to consider when managing workgroup clients. Let's start by addressing the types of boundaries that a Configuration Manager 2012 workgroup client can and cannot use for content lookup and Distribution Point (DP) access:

- A workgroup client cannot use Active Directory Site boundaries. This is because a workgroup operating system isn't joined to a domain so the operating system itself does not have the permissions required to query Active Directory Domain Services to determine what AD site it is in. The same condition is true of a domain joined computer that is a member of a different forest.

- A workgroup client strictly uses boundaries based on IP subnet boundaries, IP address ranges and IPv6 prefixes. The only exception to this rule is an isolated case that has to do with the workgroup computer build process during Operating System Deployment (OSD). More on that further down.

As a result, workgroup systems cannot supply the AD Site in their boundary request and the MP does not resolve the AD Site for usage in the location stored procedure calls. Below is an example from MP_Location.log of activity related to a domain joined client that exists in the boundaries of an AD Site:

MP_GetContentDPInfoUnprotected (PR100002,1,PR1,SMSPackage,00000000,CWS-Contoso.com,CWS-Contoso.com,<ClientLocationInfo LocationType="SMSPackage" DistributeOnDemand="0" UseAzure="0" AllowWUMU="0" UseProtected="0" AllowCaching="0" BranchDPFlags="0" UseInternetDP="0" AllowHTTP="1" AllowSMB="1" AllowMulticast="1"><ADSite Name="DEFAULT-FIRST-SITE-NAME"/><Forest Name="CWS-Contoso.com"/><Domain Name="CWS-Contoso.com"/><IPAddresses><IPAddress SubnetAddress="" Address=""/></IPAddresses></ClientLocationInfo>)


Next is an example of similar MP_Location.log activity from the same client a few minutes later after removing the client from the domain and removing the computer object from AD. The AD Site Name is no longer returned and all content location requests are determined based on IP Subnet or IP Range data alone:

MP_GetContentDPInfoUnprotected (PR100002,1,PR1,SMSPackage,00000000,,,<ClientLocationInfo LocationType="SMSPackage" DistributeOnDemand="0" UseAzure="0" AllowWUMU="0" UseProtected="0" AllowCaching="0" BranchDPFlags="0" UseInternetDP="0" AllowHTTP="1" AllowSMB="1" AllowMulticast="1"><ADSite Name=""/><Forest Name=""/><Domain Name=""/><IPAddresses><IPAddress SubnetAddress="" Address=""/></IPAddresses></ClientLocationInfo>)



When looking at the properties of a workstation client, the Active Directory Site Name property is always null even when the client is installed and the machine is in a managed AD Site boundary.  

The Configuration Manager agent retrieves the Active Directory Site Name from the OS if it is available and later returns that information to the site MP when making content location requests. The ConfigMgr agent also includes AD Site Name in heartbeat discovery DDR data if it exists. In both cases, for a workgroup client this property will always be null. The reason the Active Directory Site Name is null in the screenshot above is because the operating system cannot read Active Directory Domain Services to determine which AD Site that the system resides in.


If you use AD Site Boundaries as your standard boundary type but are presented with the requirement to start managing workgroup clients, you have two options:

- Leave your AD Site boundaries as-is and chose not to add the equivalent IP subnet or IP range boundaries.  If you chose this option, your workgroup clients will fallback and use the distribution point as the source location for content when the content is not available on a preferred distribution point. In order to accomplish this, specify the Allow fallback source location for content" option (see screen shot below) during deployments. This is often an acceptable situation as the percentage of workgroup clients in the environment is usually very small. For more details on content location scenarios, see http://technet.microsoft.com/en-us/library/gg712321.aspx and http://technet.microsoft.com/en-us/library/b2516212-e524-4031-9a1f-7b768084304d#BKMK_PreferredDistributionPoint



- The other alternative is to keep your AD Site boundaries in place and change your process to allow adding the equivalent IP subnet or IP range boundary alongside your AD Site boundaries. 

If you currently use IP boundaries as a standard but you are migrating to the use of AD Site based Boundaries, then it's fine to add those equivalent AD sites to the same boundary groups. Your domain joined clients will always use the AD Site boundaries and they will ignore the IP subnet boundaries. The workgroup clients will continue to use the IP boundaries and will be unaware of the AD Site Boundaries. 

If you have a relatively small number of workgroup clients to manage and you don't have your IP Subnets or IP Ranges mapped out in your boundaries, then your clients will always pull content from a fallback DP. If this is the route that makes the most sense for you then just insure that your deployments are configured to allowfallback because the workgroup clients require it. 

There is flexibility in managing workgroup clients and the choice is yours: 

- You can optimize your environment for workgroup clients by insuring that you have IP Subnet or IP Range boundaries defined where applicable to your network topology. This is the ideal choice as it will allow your workgroup clients to consistently retrieve package content from the closest DPs. This may be a time consuming process but the payoff may be significant if your workgroup client population is large and your network is running at full capacity. 

- If the number of workgroup clients in your environment is small, your network is robust, and you use AD Site boundaries as a standard, you may want to consider the alternative of leaving your boundaries as-is and just standardize your workgroup client deployment process to always allow fallback. 

- You can decide on a blend between of the two choices above to address key areas on your network where fallback behavior would not be a good idea on an ongoing basis.


Operating System Deployment

OSD supports AD Site Boundaries and works well in environments where AD Site Boundaries are used exclusively. The question is, how does that work? After all, Windows PE (PE client) is a workgroup OS and cannot query AD so how and why does this work? A recent discussion with the product group by colleague Ray Rosen revealed the details.
• The PE client sends a content location request that includes its IP Address and subnet to the MP. The content location request also includes ADSite Name=”?”.
• The MP sees the “?” and makes a call to a domain controller (the MP is joined to a domain) to see which AD Site covers that IP.
• The AD Site retrieved from the domain is added to subsequent stored procedure calls to find content locations.
MP_Location.log details:
MP LM: Message Body : <ContentLocationRequest SchemaVersion="1.00">
<Package ID="CAS00011" Version="3"/>
<AssignedSite SiteCode="PR1"/>
<ClientLocationInfo AllowMulticast="1">
<ADSite Name="?"/>
<IPAddress Address="" SubnetAddress=""/>
MP LM: Content Request
MP LM: Package ID is CAS00011
MP LM: Package version is 3
MP LM: Package type is SMSPackage
MP LM: Assigned site code is PR1
MP LM: AD site name is ?
Looking up AD site name for content location request.
MP LM: IP Subnet address is
MP LM: IP Address is
Successfully mapped IP address to AD site TAMPA
MP_GetContentDPInfoProtected (CAS00011,3,PR1,<ServerNameList><ServerName>SCCM-PR1.CONTOSO.COM </ServerName></ServerNameList>,SMSPackage,00000000,,,
<ClientLocationInfo AllowMulticast="1">
<ADSite Name="TAMPA"/>
<IPAddress Address="" SubnetAddress=""/>
Special thanks to Ray Rosen and the product group for sharing these details.

Workgroup Client Installation

System Center 2012 Configuration Manager does not have an SLP role. That functionality is now included in the MP role making it much easier to install and manage workgroup clients. To install the client agent on a workgroup computer when you have no IP subnets or IP range boundaries defined for site assignment, use the example that follows. It is a time saver and can also be used to install domain joined computers.

Example Command line:

\\CWS-R2PR1\SMS_PRI\Client\ccmsetup.exe /noservice SMSSITECODE=XYZ SMSMP=server01.corp.contoso.com DNSSUFFIX=corp.contoso.com FSP=server02

  • Specify the /noservice parameter so that the installation runs under the context of the currently logged on user for the entire duration of the installation. By default, ccmsetup.exe runs using the /service parameter even though you don't specify it. This means that as soon as ccmsetup.exe starts running, the user context is switched to that of the local system account. The local system account of a workgroup computer does not have rights to a domain joined primary site server so if you try to run ccmsetup.exe over a network share of a domain joined primary site server, you'll be able to initiate the install under your credentials but the user context is quickly changed to that of the local system account once the installation begins. The local system account of a workgroup computer will not have rights to the network share on a primary site server to pull down additional required files and the install will fail. When viewing ccmsetup.log, there will be an installation failure similar to "Source folder \\cws-r2pr1\SMS_PR1\Client is invalid. Skip it". Below is a more detailed snippet from ccmsetup.log that shows the entire failure when the /noservice parameter isn't specified: 
  • By specifying the SMSSITECODE and not using AUTO, you are telling ccmsetup to install the agent to a specific site regardless of how your boundaries are defined. There is no dependency or need for IP subnet or IP range based boundaries for the purposes of client installation if you are specifying the actual site code that the client will use.  
  • Specify the management point using the SMSMP parameter. This is an important parameter when not using auto-assignment.
  • Specify the DNS suffix using the DNSSUFFIX parameter.
  • Specify the Fallback Status Point using the FSP parameter.

Command line: "C:\WINDOWS\ccmsetup\ccmsetup.exe" /runservice /source:"\\cws-r2pr1\SMS_PR1\Client" "SMSSITECODE=PR1" "SMSMP=CWS-R2PR1.CWS-Contoso.com" "dnssuffix=CWS-Contoso.com" "FSP=CWS-R2PR1.CWS-Contoso.com" ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Source folder \\cws-r2pr1\SMS_PR1\Client is invalid. Skip it. ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC) (Local System account cannot access this network share!)
SslState value: 224 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CCMHTTPPORT:    80 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CCMHTTPSPORT:    443 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CCMHTTPSSTATE:    224 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CCMHTTPSCERTNAME:     ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Lookup MP:    CWS-R2PR1.CWS-Contoso.com ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
FSP:    CWS-R2PR1.CWS-Contoso.com ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CCMFIRSTCERT:    1 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
No MP or source location has been explicitly specified.  Trying to discover a valid content location... ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Looking for MPs from AD... ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Unexpected row count (0) retrieved from AD. ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
GetADInstallParams failed with 0x80004005 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Couldn't find an MP source through AD. Error 0x80004005 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
No valid source or MP locations could be identified to download content from. Ccmsetup.exe cannot continue. ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Failed to parse '"C:\WINDOWS\ccmsetup\ccmsetup.exe" /runservice /source:"\\cws-r2pr1\SMS_PR1\Client" "SMSSITECODE=PR1" "SMSMP=CWS-R2PR1.CWS-Contoso.com" "dnssuffix=CWS-Contoso.com" "FSP=CWS-R2PR1.CWS-Contoso.com"' with error 0x80004005 ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Sending Fallback Status Point message to 'CWS-R2PR1.CWS-Contoso.com', STATEID='100'. ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Failed to get client version for sending messages to FSP. Error 0x8004100e ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Params to send FSP message '5.0.7958.1000 Deployment ' ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
State message with TopicType 800 and TopicId {C4BCA8C2-D142-4B89-86A8-2936A4ED83AC} has been sent to the FSP FSPStateMessage 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Sending Fallback Status Point message to 'CWS-R2PR1.CWS-Contoso.com', STATEID='307'. ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Failed to get client version for sending messages to FSP. Error 0x8004100e ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
Params to send FSP message '5.0.7958.1000 Deployment "C:\WINDOWS\ccmsetup\ccmsetup.exe" /runservice /source:"\\cws-r2pr1\SMS_PR1\Client" "SMSSITECODE=PR1" "SMSMP=CWS-R2PR1.CWS-Contoso.com" "dnssuffix=CWS-Contoso.com" "FSP=CWS-R2PR1.CWS-Contoso.com"' ccmsetup 6/22/2014 8:15:43 PM 3324 (0x0CFC)
State message with TopicType 800 and TopicId {899431E0-57CE-42AC-9907-312AC7FD9D48} has been sent to the FSP FSPStateMessage 6/22/2014 8:15:43 PM 3324 (0x0CFC)
CcmSetup failed with error code 0x80004005 ccmsetup 6/22/2014 8:15:43 PM 3312 (0x0CF0)

You can also work around the permissions issue by first copying all of the files from the Inboxes\Client folder on the primary site server to the local temp folder on the workgroup client first. Then run ccmsetup.exe locally. You'll be using the default /noservice parameter even if you do not specify it and local system will have rights to the files that are now local. For best results, specify the /noservice parameter because it eliminates the extra copy step and the client gets installed faster that way.

I will typically recommend that the customer create a ClientInstall.bat file in the Client folder on the primary site where ccmsetup.exe exists. This batch file makes it convenient for engineers to manually install the client on workgroup and domain joined computers alike.





Supernetting applies to domain joined computers only but it is important in the context of this topic because one might get the false impression that it may just be easier to avoid using AD Site Boundaries and keep all boundaries limited to type IP Subnet or IP range. After all, these two types of boundaries fully support both domain joined and workgroup clients equally, right? This isn't actually a good idea so here is some additional information to consider. 

- The concept of supernetting allows engineers to make a single subnet entry in the properties of an AD Site that can represent literally dozens if not hundreds of individual subnet entries. This is a more efficient means to manage thousands of subnets in large environments. 

- The underlying operating system on the client has logic to verify whether its IP address lands within a specific supernet, regardless of the mask listed for the supernet in the AD Site. For example, the OS can tell that a client with IP falls under the AD Site that manages IP subnet If there are two AD Sites defined where one site manages A true subnet of and the other AD Site manages a supernet of, the OS is also able to determine that it actually belongs to the more restrictive AD Site. For the purposes of content lookup, we can take advantage of this capability and use it to our advantage. 

- When clients attempt to locate package source for a specific package, they post a request to their current MP containing the package ID, package version, the client's assigned site code, the client's IP address and calculated IP subnet. Configuration Manager does not support supernetting but most customers have supernets in their AD Site Boundary definitions as it’s a recommended best practice from a Platforms standpoint to have catch-all supernets defined in AD. 

- Configuration Manager does not support automatic site assignment (SMSSITECODE=AUTO) when using AD supernetting. Most customers specify the actual site code instead to work around this issue. 

- The key area where the OS and Configuration Manager supports supernetting is with regards to AD Site Boundaries for content location requests. This works well and is supported by the Platforms team because it is the underlying OS that determines nearest subnet match of an appropriate AD Site. The SMS Agent simply uses the AD Site name which is supplied by the client OS. Discussions with the product group have confirmed that AD Site based content location requests are supported. This knowledge can save an engineer a significant amount of time in boundary management maintenance since the number of boundary entries required to manage a large environment can be significantly reduced if leveraging AD Sites instead of IP Subnets. For more details on this topic you can read here

To sum this up:  

    • If using AD Site Boundaries that contain underlying supernetted entries, you cannot use AUTO as the SMSSITECODE= value when running ccmsetup.exe. Instead, specify the specific site code that you require (e.g SMSSITECODE=XYZ). 
    • AD Site Boundaries can be supernetted for the purposes of content location and this capability can significantly reduce administrative overhead managing boundaries for domain joined clients. 
    • Workgroup clients cannot read AD Site Boundaries. They read IP Subnet and IP range boundaries.

For more information please see http://technet.microsoft.com/en-us/library/gg712298.aspx 


 Chris Sugdinis | Premier Field Engineer | Microsoft