Configmgr is no longer managing windows gpo

Video: Content Troubleshooting Deep Dive (Full Video)

Video: Content Troubleshooting Video Timeline

Scenario 1: Succesful Content Lookup Workflow

1. Healthy ConfigMgr client.

2. The client is in a boundary.

3. There is a Distribution Point associated with the boundary group.

4. The content is distributed successfully to the DP.

5. The software / update / package is deployed to the device.

6. Enable verbose logging on the site system with the MP role and the client

Successful Content Lookup Flow

There are many moving parts when a content location request is sent to the management point and processes by a ConfigMgr client. Here are some key snippets of how this happens.

Snippets of Location Request

Example of the management point MP_Location.log calling the stored procedure MP_GetContentDPInfo

<ServerNameList>
    <ServerName LocalityEx="256" Fallback="0">DEMO1.CONTOSO.LOCAL</ServerName>
</ServerNameList>,SMSUpdate,00000000,CONTOSO.LOCAL,CONTOSO.LOCAL,<ClientLocationInfo LocationType="SMSUpdate" DistributeOnDemand="0" UseAzure="0" AllowWUMU="0" UseInternetDP="0" AllowHTTP="1" AllowSMB="1" AllowMulticast="1" AllowSuperPeer="1" DPTokenAuth="1">
<ADSite Name="DEFAULT-FIRST-SITE-NAME"/>
<Forest Name="CONTOSO.LOCAL"/>
<Domain Name="CONTOSO.LOCAL"/>
<IPAddresses>
    <IPAddress SubnetAddress="192.168.10.0" Address="192.168.10.35"/>
</IPAddresses>
<Adapters>
    <Adapter Name="Ethernet" IfType="6" PhysicalAddressExists="1" DnsSuffix="" Description="Microsoft Hyper-V Network Adapter"/>
</Adapters>
<BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-28T15:00:21.637" IsOnVPN="0">
    <BoundaryGroup GroupID="16777218" GroupGUID="ad36e248-a857-45e6-ab82-c179bb680b18" GroupFlag="0"/>
</BoundaryGroups>
</ClientLocationInfo>,<BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-28T15:00:21.637" IsOnVPN="0">
<BoundaryGroup GroupID="16777218" GroupGUID="ad36e248-a857-45e6-ab82-c179bb680b18" GroupFlag="0"/>
</BoundaryGroups>)

Example of a content location request from the client sent to the management point in CAS.log

<ContentLocationRequest SchemaVersion="1.00" BGRVersion="1" ExcludeFileList="">
    <Package ID="UID:9c93cbee-aabc-4daf-996a-4580daa09c87" Version="1" DeploymentFlags="9223372036855300962"/>
    <AssignedSite SiteCode="DM1"/>
    <ClientLocationInfo LocationType="SMSUpdate" DistributeOnDemand="0" UseAzure="0" AllowWUMU="0" UseInternetDP="0" AllowHTTP="1" AllowSMB="1" AllowMulticast="1" AllowSuperPeer="1" DPTokenAuth="1">
        <ADSite Name="Default-First-Site-Name"/>
        <Forest Name="CONTOSO.LOCAL"/>
        <Domain Name="CONTOSO.LOCAL"/>
        <IPAddresses>
            <IPAddress SubnetAddress="192.168.10.0" Address="192.168.10.35"/>
        </IPAddresses>
        <Adapters>
            <Adapter Name="Ethernet" IfType="6" PhysicalAddressExists="1" DnsSuffix="" Description="Microsoft Hyper-V Network Adapter"/>
        </Adapters>
        <BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-28T15:00:21.637" IsOnVPN="0">
            <BoundaryGroup GroupID="16777218" GroupGUID="ad36e248-a857-45e6-ab82-c179bb680b18" GroupFlag="0"/>
        </BoundaryGroups>
    </ClientLocationInfo>
</ContentLocationRequest>

Example of Content location reply from the management point to the client in the client’s CAS.log

<ContentLocationReply SchemaVersion="1.00" BGRVersion="1">
    <BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-27T14:21:06.263" IsOnVPN="0">
        <BoundaryGroup GroupID="16777218" GroupGUID="ad36e248-a857-45e6-ab82-c179bb680b18" GroupFlag="0"/>
    </BoundaryGroups>
    <ContentInfo PackageFlags="0" DeploymentFlags="9223372036855300962">
        <ContentHashValues/>
    </ContentInfo>
    <Sites>
        <Site>
            <MPSite SiteCode="DM1" MasterSiteCode="DM1" SiteLocality="LOCAL" IISPreferedPort="80" IISSSLPreferedPort="443"/>
            <LocationRecords>
                <LocationRecord LocalityEx="BOUNDARYGROUP" DPFallbackIn="PT0M">
                    <URL Name="http://DEMO1.CONTOSO.LOCAL/SMS_DP_SMSPKG$/9c93cbee-aabc-4daf-996a-4580daa09c87" Signature="http://DEMO1.CONTOSO.LOCAL/SMS_DP_SMSSIG$/9c93cbee-aabc-4daf-996a-4580daa09c87.1.tar" Capability="0"/>
                    <ADSite Name="Default-First-Site-Name"/>
                    <IPSubnets>
                        <IPSubnet Address="192.168.10.0"/>
                        <IPSubnet Address=""/>
                    </IPSubnets>
                    <Metric Value=""/>
                    <Version>9040</Version>
                    <Capabilities SchemaVersion="1.0">
                        <Property Name="SSLState" Value="0"/>
                    </Capabilities>
                    <ServerRemoteName>DEMO1.CONTOSO.LOCAL</ServerRemoteName>
                    <DPType>SERVER</DPType>
                    <Windows Trust="1"/>
                </LocationRecord>
            </LocationRecords>
        </Site>
    </Sites>
    <RelatedContentIDs/>
</ContentLocationReply>

Here’s a snippet of the download options for a software update download request in UpdatesDeploymentAgent.log

<DownloadOptions>
    <Priority>Foreground</Priority>
    <DPLocality>10</DPLocality>
    <Timeout>
        <Location>604800</Location>
        <Download>86400</Download>
        <PerDPInactivity>0</PerDPInactivity>
        <TotalInactivity>0</TotalInactivity>
        <UseBranchCache>true</UseBranchCache>
        <PersistOnWriteFilterDevices>false</PersistOnWriteFilterDevices>
        <OverrideServiceWindows>false</OverrideServiceWindows>
    </Timeout>
</DownloadOptions>

A point of interest is DPLocality flag determines how the client obtains distribution points, according to distribution point locality. Possible values are:

Scenario 2: Failed Content Lookup Due to Boundary Misconfiguration

1. Healthy ConfigMgr client.

2. The client is NOT in a boundary.

3. There is a Distribution Point associated with the boundary group the client is NOT in.

4. The content is distributed successfully to the DP.

5. The software / update / package is deployed to the device.

6. Enable verbose logging on the site system with the MP role and the client

Notable Ways to Identity when a Client is Not in Boundary Group

If a client is not in a boundary group here are some snippets that can be helpful.

In the content location request in the CAS.log, you will also notice the BoundaryGroup element doesn’t contain the fields GroupID, GroupGUID, or GroupFlag.

In the CAS.log here is an example of a response from the management point when the client is in no boundary group, and fallback is disabled, and no content was found.

<ContentLocationReply SchemaVersion="1.00" BGRVersion="1" ContentFlags="86016" HashAlgorithm="32780" AlgorithmPreference="4" Hash="5230AF02CF06BDD36CDD10FD13C4DF795F465E46FC47E1B1A00E44E2589AA6AD" ExcludeFileListHash="" RelatedContentID="">
    <BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-28T15:36:56.910"/>
    <ContentInfo/>
    <Sites>
        <Site>
            <MPSite SiteCode="DM2" MasterSiteCode="DM2" SiteLocality="FALLBACK"/>
            <LocationRecords/>
        </Site>
    </Sites>
    <RelatedContentIDs/>
</ContentLocationReply>

We can compare this to the response received in the CAS.log when the content was found and the client is in a boundary group.

<ContentLocationReply SchemaVersion="1.00" BGRVersion="1">
    <BoundaryGroups BoundaryGroupListRetrieveTime="2021-04-28T15:00:21.637" IsOnVPN="0">
        <BoundaryGroup GroupID="16777218" GroupGUID="ad36e248-a857-45e6-ab82-c179bb680b18" GroupFlag="0"/>
    </BoundaryGroups>
    <ContentInfo PackageFlags="0" DeploymentFlags="9223372036855300962">
        <ContentHashValues/>
    </ContentInfo>
    <Sites>
        <Site>
            <MPSite SiteCode="DM1" MasterSiteCode="DM1" SiteLocality="LOCAL" IISPreferedPort="80" IISSSLPreferedPort="443"/>
            <LocationRecords>
                <LocationRecord LocalityEx="BOUNDARYGROUP" DPFallbackIn="PT0M">
                    <URL Name="http://DEMO1.CONTOSO.LOCAL/SMS_DP_SMSPKG$/9c93cbee-aabc-4daf-996a-4580daa09c87" Signature="http://DEMO1.CONTOSO.LOCAL/SMS_DP_SMSSIG$/9c93cbee-aabc-4daf-996a-4580daa09c87.1.tar" Capability="0"/>
                    <ADSite Name="Default-First-Site-Name"/>
                    <IPSubnets>
                        <IPSubnet Address="192.168.10.0"/>
                        <IPSubnet Address=""/>
                    </IPSubnets>
                    <Metric Value=""/>
                    <Version>9040</Version>
                    <Capabilities SchemaVersion="1.0">
                        <Property Name="SSLState" Value="0"/>
                    </Capabilities>
                    <ServerRemoteName>DEMO1.CONTOSO.LOCAL</ServerRemoteName>
                    <DPType>SERVER</DPType>
                    <Windows Trust="1"/>
                </LocationRecord>
            </LocationRecords>
        </Site>
    </Sites>
    <RelatedContentIDs/>
</ContentLocationReply>

If the content is not found, you will be able to note the following line in StateMessage.log

State message(State ID : 5003) with TopicType 1702 and TopicId ScopeId_CA3F999B-7A81-43BF-912C-56E267C1E565/DeploymentType_677dac51-d2a2-4bbd-aeb0-4b845aa288cd/1 has been recorded for S-1-5-21-1880864260-2612682489-34998949-6112

Scenario 3: Download Failure Due to Content Distribution Failure

This scenario covers some of the basics in troubleshooting content that has failed to distribute to a distribution point.

Log Files for Troubleshooting Content Distribution in ConfigMgr

Example of Error if the Source Folder Doesn’t Exist or the Site Server Doesn’t Have Access

Scenario 4: Download Failure Due to Invalid Content

The fix for this type of scenario may be as simple as performing an ‘update content’ or ‘redistribute’ the content which is failing. Other times you may have to validate antivirus exclusions on your endpoints and servers. Using the log files to identify what type of error is occurring will be key to resolving the issue and determine where the issue lies.

Example of Error if the Hash of the Downloaded File Does Not Match the Expected Hash

The above log files and lines would be helpful from the client when determining if there is a hash mismatch issue. It is good to note that the hash mismatch may not be due to a corrupt file in the Content Library, but it is still worth investigating. This can also commonly be due to Antivirus on the endpoint which lacks the prover exclusions for example.

Example of Error if a File is Missing from the Content Library When a Client Requests It

Log Files for Troubleshooting

Meet the Patch My PC Team!: (​)

Scenario 1 — What happens on a successful content lookup in SCCM: (​)

Review valid boundary, boundary group, and content distribution: (​) How to Enable Verbose Logging in ConfigMgr/SCCM Client: (​)

Client logs for content location request in SCCM: (​)

Review Client Log Files CAS.log CIAgent.log CIDownloader.log CIStateStore.log ClientLocation.log CMBITSManager.log ContentTransferManager.log DataTransferService.log DCMAgent.log LocationServices.log StateMessage.log UpdatesDeployment.log : (​)

CCIStateStore::GetCIState — Client is requesting CI ModelName: (​)

===== CacheManager: Content for Content_{guid} was NOT found cache. =====: (​)

Client location request in CAS.log ContentLocationRequest: (​)

Review MP_Location.log on the management point and the stored procedure MP_GetContentDPInfo: (​)

DataTransferService.log creating a bits download request: (​)

Review downloaded update in the CCMCache folder: (​)

Review the MP_GetContentDPInfo stored procedure in the ConfigMgr database: (​)

Scenario 2 — Boundary Groups Misconfigured: (​)

Client is not in a boundary group in SCCM: (​)

Attempt application install in SCCM when the client isn’t in boundary group: (​)

Application installed fails with error code 0x87D00607 in SCCM/ConfigMgr: (​)

Enable fallback for content in the configuration manager site: (​)

Troubleshooting content distribution failures in Configuration Manager (SCCM): (​)

Content corruption in SMSContentLib directory: (​)

Tip: The Fallback=»0″ or Fallback=»1″ controls if fallback is allowed. To learn more about fallback see this .

For scenario 4, we delete a file directly from the FileLib and modify a file directly in the FileLib. We will cover the in a future video. This builds off of scenario 3 by showing specific failure scenarios.

i have a client in our dmz that the client installed but i only have machine policy and user policy. this machine is also my MP in the dmz. i do have other systems installing and reporting back fine. just this system is giving me issues for some reason. i included a few of the logs files where the errors are showing.

ccmsetup.log

Could not retrieve value for MDM_ConfigSetting . Error 0x80041010 ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Updating MDM_ConfigSetting.ClientHealthStatus with value 1 ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Failed to get MDM_ConfigSetting instance, 0x80041010 ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Updating MDM_ConfigSetting.ClientDeploymentErrorCode with value 0 ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Failed to get MDM_ConfigSetting instance, 0x80041010 ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
[5.00.8790.1025] Params to send ‘5.0.8790.1025 Deployment [DP] https://PRI02.xxx.net/SMS_DP_SMSPKG$/xxx00002’ ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
A Fallback Status Point has not been specified and no client was installed. Message with STATEID=’400′ will not be sent. ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Failed to send status 400. Error (87D00215) ccmsetup 6/8/2020 1:59:50 PM 7476 (0x1D34)
Successfully deleted the ccmsetup service ccmsetup 6/8/2020 1:59:55 PM 7476 (0x1D34)
Deleted file C:Windowsccmsetupccmsetup.xml ccmsetup 6/8/2020 1:59:55 PM 7460 (0x1D24)
Task ‘Configuration Manager Client Upgrade Task’ does not exist ccmsetup 6/8/2020 1:59:55 PM 7460 (0x1D24)
Could not retrieve value for MDM_ConfigSetting . Error 0x80041010 ccmsetup 6/8/2020 1:59:55 PM 7460 (0x1D24)
Removed temporary download directory. ccmsetup 6/8/2020 1:59:55 PM 7460 (0x1D24)
CcmSetup is exiting with return code 0 ccmsetup 6/8/2020 1:59:55 PM 7460 (0x1D24)

locationservices.log

Instance of CCM_WindowsDOClientConfig doesn’t exist in WMI LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
This device is not enrolled into Intune. LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
This device is not externally managed. LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
ConfigMgr is no longer managing WindowsDO GPO. Set to default values. Mode = LAN. GroupID = empty LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
Current AD site of machine is xxx LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
Current AD site of machine is xxx LocationServices 6/16/2020 4:59:05 PM 1860 (0x0744)
Received reply of type PortalCertificateReply LocationServices 6/16/2020 4:59:05 PM 1552 (0x0610)
The reply from location manager contains 0 certificates LocationServices 6/16/2020 4:59:05 PM 1552 (0x0610)
Updating portal certificates LocationServices 6/16/2020 4:59:05 PM 1552 (0x0610)
There are no certificates available to install LocationServices 6/16/2020 4:59:05 PM 1552 (0x0610)
1 assigned MP errors in the last 10 minutes, threshold is 5. LocationServices 6/16/2020 4:59:05 PM 5024 (0x13A0)

Картинка с сайта: call4cloud.nl

There is definitely a lot of confusion about how Group Policies interact with, control, and affect Software Update Management (SUM) on ConfigMgr clients. At the outset of this post (or series of posts), I don’t even know exactly what’s going to happen with some of the different settings and combinations that I’m going to try and then document.

The Windows Update Agent

The Windows Update Agent (WUA) is the key Windows component that handles both update scanning and update application to a system — this is the same whether the system uses Microsoft Updates from the web, WSUS, or ConfigMgr for updates. Because ConfigMgr actually uses WSUS, these two methods have a few things in common, specifically, the actual delivery of the update catalog to the clients. In both cases, this comes straight from WSUS and thus the use of the same group policy setting(s). Additionally, there are other settings in group policy that effect how the WUA agent behaves which I intend to explore.

Domain Group Policies vs. Local Group Policies.

As their names imply, domain group polices originate from the domain and local group policies originate on the local system. A common misconception is that local group policies are simply local registry edits in one of the above policy keys. This is not true; although you may get the desired result, this is not a true local group policy. To edit a local group policy, you must open the local group policy editor: gpedit.msc. Also note that domain group policies overwrite settings defined in a local group policy without prejudice on a setting by setting basis. Thus, only settings actually configured in the domain group policy will trump those defined in the local group policy; settings defined in a local group policy and not in the domain group policy will be left unaffected.

Why is the local vs. domain distinction important? Because ConfigMgr uses local group policies to configure the Windows Update settings on all managed clients. The clear implication here is that if you have any Windows Update settings in a domain group policy, they will overwrite those that ConfigMgr sets. The settings in the screenshot below were configured by the ConfigMgr agent in my lab environment and viewed using gpedit.msc.

So what happens if we do have a domain group policy and how can we troubleshoot this? It depends on which settings are applied in the domain group policy.

Setting the Server

The first setting to test is the actual update server. First, I’ll set it to the same value that ConfigMgr sets it to.

First a gpupdate /force and then initiate a Software Update Scan Cycle from the ConfigMgr agent Control Panel applet and check wuahandler.log on the client.

So far so good. Next, let’s set the domain group policy to point to another server and see what happens.

Another gpupdate /force, initiate a Software Update Scan Cycle again, and finally check wuahandler.log.

Egregious FAIL!

Notice what the log file says here: “Group policy settings were overwritten by a higher authority”. From this it is apparent that ConfigMgr checks to make sure that the WSUS settings do match up with those that it expects, namely the server location, and if they don’t it “gracefully” stops processing.

One of the first things I tried way back when at a customer site was to trick the process by overwriting the values directly in the registry. As many folks know, all of the group policies contained in the Administrative Templates section ultimately just set registry values (see What Is Administrative Templates Extension? for more information). The Windows Updates settings are in this section and thus update specific registry values located in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate; note that the WUA will not automatically notice that you’ve updated the values manually so you must restart the Automatic Updates service to make them effective.

So what are the results? As you may (or may not) expect, everything worked. Of course, as soon as group policy decides to refresh, you’re back at square one.

One thing I learned in testing and verifying the above was that if the Windows Update server is set to a name that either does not resolve or is not a valid WSUS server, Windows Update is not a happy camper and neither is the ConfigMgr agent. It took multiple stops and starts of the Automatic Updates service and the SMS Agent Host once a valid update server is set for everything to work as expected again. It seems that if Windows Update has any kind of error connecting to the configured update server, the ConfigMgr agent refuses to do anything as far as software updates go — the wuahandler.log will show an initial error message but then will not show anything else until the problem is corrected, which as I just mentioned, took restarting both services. If I was patient, I think things might sort themselves out eventually, but restarting the services expedited the process.

XP: Keep Your Computer Up To Date

Another thing I noticed on my XP test client is that if there are no policies applied, either local or domain, and Windows Update has not been manually configured, then the “Keep your computer up to date” notification icon is displayed along with the associated balloon message. This is the default state of all Windows XP systems in my experience.

Картинка с сайта: call4cloud.nl

As soon as a Windows Update policy is applied though, including the ConfigMgr local group policy for Windows Updates, the icon and balloon are removed. This can be seen in the WindowsUpdate.log.

Windows 7: Action Center

The (nearly) equivalent behavior in Windows 7 is handled by the Action Center as seen below. However, getting rid of this message is not the same as in XP. The Action Center is a completely separate component from Windows Update and thus its messages are not generated by the WUA itself. To get rid of this message, you must set the “Configure Automatic Updates” setting; the local group policy set by ConfigMgr for Windows Updates is not sufficient. By default (in my testing at least), this setting is already set on the component at install time to “Auto download and schedule the install” and so you don’t actually need to do anything. If for some reason it’s not set though, just use a group policy to set it (local or domain).

If you set the “Configure Automatic Updates” setting to anything other than the default “Auto download and schedule the install” including disabling it, the Action Center will show the following message:

The Action Center itself is way beyond the scope of this blog, but I did dig up a few links for reference:

This blog post is long enough now so I’ll continue in another post tomorrow (hopefully). Next up is looking at the other “Configure Automatic Updates” settings and how they affect Software Updates in ConfigMgr as well as actually stopping the WUA service (i think we can all guess what happens when we do that).