0

I have an SCCM OS deployment task sequence that works just fine -- with one caveat that I can't seem to figure out...

Once the task sequence completes, it takes anywhere from 4-16 hours to process its client settings. This means that freshly-imaged computers do not get any of their deployments or AV settings during that time. The SCCM client will eventually sync up with the server and when it does, everything works normally after that. But because of this issue, we basically have to let computers sit overnight before we can deliver them to users. Reimaging a wonky computer out in the field isn't an option unless we do it right before the user goes home for the day, so that it will be ready for them when they get in to work the next morning.

One particular issue is the Endpoint Protection client. On Windows 10 there is no way (that I know of) to put Windows Defender into managed mode since it's a built-in component of the operating system. We absolutely have to wait for the SCCM client to do its thing in order for that to process exclusions correctly (which are required for a particular application we use).

Here are the relevant details:

  • We're using SCCM 1710
  • This happens on all our images, in both Windows 7 and Windows 10.
  • No amount of manually triggering client actions in the Config Manager control panel makes it apply policy any faster.
  • Rebooting the computer in question makes no difference.
  • Everything works normally after the client finally syncs up. Deployments, software updates, and policy evaluations are all processed on schedule after that.
  • SCCM management console shows the client as installed and active.
  • Our SCCM hierarchy only has one site server with the DB, DP, MP, and SUP roles all running on it. All the boundary groups are configured correctly.
  • AD system and user discovery happens every 24 hours, with delta discovery enabled at 5 minutes.
  • No maintenance windows are defined on any of our collections (we are mostly a 24/7 operation). All deployments are set to ignore maintenance windows anyway.
  • Logs don't have errors or anything unusual in them (although I'll admit I'm not really sure what I am looking for there).

Is there any way to force the client to download and apply policy during the imaging process?


UPDATE:

I have traced this issue down to the discovery process on the server side.

When looking at an affected machine in the SCCM console, it shows that the client is installed, active, and healthy BUT Resource Explorer shows no data for it. SCCM does not know anything about the device -- what OS is installed, what hardware it has, what software is installed, what OU it's in... nothing.

All our collections are based on queries, so until data becomes available to query on, SCCM has no idea what collection it should be in, and therefore nothing gets advertised to it. The client should be populating this data to the server during its discovery cycle, but for some reason it isn't.

IF I go forcing AD system rediscovery, forcing collection member reevaluation, and manually triggering site actions on the client, THEN I can get SCCM to behave within an hour or so. But I'm really just mashing buttons randomly at this point. I don't know what combination of timing and ordering of actions is the magic sauce here.

  • AD system discovery is set to run every day with delta discovery set to 5 minutes.
  • Collection evaluations are set to run every 7 days, with delta discovery also enabled at 5 minutes.

But none of that makes sense because it doesn't take a full 24 hours to populate. If I image a machine up first thing in the morning, it will usually be ready by late afternoon, but discovery doesn't run until the middle of the night.

Also:

  • If I re-image an existing machine with the SAME OS, I've had success with getting the computer to evaluate correctly after an hour or so by simply triggering the site actions on the client. But this is because DB already had a record for those computers, and none of the information about them changed.

So does that updated information help anyone?

  • This is really strange as default behavior is to always do a machine policy update when the client is installed. I know of one bug where the client is just stuck and does not correctly apply the policies but normally it never really recovers. Could you test what happens if you use roger zanders client center and try "reset policy" (which is more "brutal" than what the client does) on an affected machine? – Syberdoor Jul 25 '18 at 8:09
  • Have you checked the registry value ProvisioningMode which can be found in SOFTWARE\Microsoft\CCM\CcmExec on the client? It should be set to "false", if it is set to "true" then policy will not be evaluated. – Harry Johnston Nov 14 '18 at 22:54
0

If you are in HTTPS only mode, this could be a delay in the machine getting it's certificate from your certificate authority.

If that's the case, in ccmexec.log you'll see a line "Unable to find any Certificate based on Certificate Issuers".

You need to make it autoenroll for certificates first.

  • Not using HTTPS but thanks for the heads up, since we will likely be in the future – Wes Sayeed Aug 15 '18 at 23:19
0

You could use PowerShell, add as a task in the task sequence:

Invoke-WmiMethod -Namespace root\ccm\clientsdk -Class CCM_ClientUtilities -Name GetMachinePolicy
  • This is just the command-line version of triggering a Machine Policy Evaluation from the Actions tab of the ConfigMgr Control Panel. Sadly, it doesn't work :-( – Wes Sayeed Aug 15 '18 at 23:20
0

the behavior you are describing seems to be expected.

What would help you is called Delta discovery. It actively looks for AD changes (such as adding a new computer to the directory) and makes them visible to SCCM. What delta discovery is for SCCM's Discovery Methods is called Incremental update for its Collections.

SCCM Discovery Methods

enter image description here

0

Based on what you say, the longest possible chain I can think of looks like this:

Build -> AD System Discovery -> Collection Update -> Client Settings ->
Machine Policy -> Hardware Inventory -> Collection Update ->
Endpoint Protection Settings -> Machine Policy -> Done

Shrinking this can be done in a few ways:

  1. Default settings for Hardware Inventory and Endpoint Protection, rather than targeted at collections - i.e. secure/managed by default, override as needed
  2. Make your collections depend on attributes discovered from AD, rather than attributes discovered from hardware inventory - you want make sure the collection to contain systems that have client as None and Client Activity . My collection for Windows 10 has SMS_R_System.OperatingSystemNameandVersion like "%Microsoft Windows NT Workstation 10%"

I believe I don't have this problem because even though there's a race condition for the Task Sequence vs the collection membership, the collection membership is always faster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.