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?
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.
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.
Based on what you say, the longest possible chain I can think of looks like this:
Shrinking this can be done in a few ways:
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.
You could use PowerShell, add as a task in the task sequence: