Leaving status as Noted – see https://blogs.technet.microsoft.com/configmgreng/2016/03/11/configmrguv/
We don’t do anything explicit to block GPO processing, in earlier Windows versions that wasn’t the case but GPO apply was problematic in some instances
Our next step for this item is clear explanation of how GPO relates to OS Deployment Task Sequences and standalone Task Sequences.
Basically a lot of configuration is done via GPO that can be quite critical during OSD.
Main example: Bitlocker.
Quite often you have a Bitlocker GPO defined that says for example "Encryption is AES-256, store TPM password in AD".
However, during OSD, as this GPO doesn't apply, the TS will just use the default settings of Windows, which in this case would be enabling Bitlocker with AES-128, which isn't what you want.
The current workaround is manually using "run commandline" steps in your TS to set the exact registry keys you set with that GPO. That's redundant work and can be error prone.
There are many other examples like this too.
Beyond that, by default after OSD finishes GPO hasn't applied. You need to use some _SMSTSPostAction to do a gpupdate /force and reboot to be even closely sure that GPO will be applied. This is important in high security environments where GPOs are used to enforce a Secure Configuration Baseline such as the CIS benchmark.
yes, lack of control of how dependencies are installed (or just control of general order of installation) is why we are not using App model right now and are sticking to TS and Packages.
Or just add a "process Group Policy" step to Task Sequence.
13 votesRobby Moeyaert supported this idea ·
By extension, just allow TS to be deployed to user collections. I love "user-centric" stuff, but I hate that I can only send applications user-centric. TS are insanely powerful tools, but I'm forced to do it machine-based.