Managing Workgroup Clients in System Center 2012 Configuration Manager

~ Chris Sugdinis

Here are some key points to consider when managing workgroup-based ConfigMgr 2012 clients.

Distribution Points

Let's start by addressing the types of boundaries that a Configuration Manager 2012 workgroup client can and cannot use for content lookup:

- 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).

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="192.168.1.0" Address="192.168.1.202"/></IPAddresses></ClientLocationInfo>)

Next is similar MP_Location.log activity from the same client a few minutes later after removing the client from the domain. 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="192.168.1.0" Address="192.168.1.202"/></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 always use your fallback DPs provided you use 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.

- 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 allow fallback 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.

Workgroup Client Installation

To install the client when you have no IP subnets or IP range boundaries defined for site assignment, use the following example. It is a time saver:

Example Command line:

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

- 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.

- 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 ccmsetup.exe runs under the context 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:

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.

Supernetting

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 192.168.121.100/24 falls under the AD Site that manages IP subnet 192.168.0.0/16. If there are two AD Sites defined where one site manages A true subnet of 192.168.121.100/24 and the other AD Site manages a supernet of 192.168.0.0/16, the OS is also able to determine that it actually belongs to the more restrictive 192.168.121.100/24 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 Configuration Manager does work with 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. 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 you can read here.

To sum this all up:

If using AD Site Boundaries that contain underlying supernetted entries, you cannot use SMSSITECODE=AUTO 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

Get the latest System Center news onFacebookandTwitter: