Okay.
Let's switch gears and talk about the different modes of group policy processing.
So we've talked about foreground and background.
Now each processing cycle, whether it be foreground or background, can run in one of two different
modes.
And those modes are either synchronous, which is essentially meaning that group policy processing for
the computer finishes completely before the user can log in, and then group policy processing for the
user finishes completely before they can use their desktop.
So that's synchronous processing.
The other kind of processing is asynchronous.
And that means that essentially group policy processing is running while the user is logging in for
the computer and while they're working on their desktop for the user.
So group policy processing is happening in the background while the user is getting productive.
And this is a usually a.
A much better place to be from a performance and desktop experience perspective, but it's definitely
different from a group policy processing perspective.
And I will point out that asynchronous processing has been the default on Windows Workstation SKUs like
Windows XP, Windows seven since Windows XP.
And in fact, you have to specifically override it if you want some other kind of behavior.
So let's dig into this a little bit.
So what does asynchronous processing really look like?
Well, the computer starts up and this is, you know, the cycle from a computer that's often a user
that's obviously not logged on to a computer that's on and the user's logged on.
So the computer starts up.
Computer processing starts at some point during that boot cycle, when the computer gets network access
and starts to resolve to add the user's log on dialog is presented so the control plus alt plus delete
log on dialog is presented sometime, while group policy computer processing is continuing on its path.
Now the user can log on at that point and when the user logs on then user based processing happens sometime
in that in that user log on cycle.
And the user gets their desktop presented to them and usable while processing may still be going on.
So essentially user processing is happening in the background and the user is functional and able to
work on their desktop.
Now let's contrast that with synchronous processing.
So in synchronous processing, again, the computer starts up, computer processing starts up, but
the user doesn't get their log on dialogue until computer processing has completed.
So once the user gets their log on dialogue and they enter in their credentials, they log on.
And now user processing starts up at some point in the user log on cycle.
But the user doesn't get a usable desktop presented to them until after the user processing has finished.
So as you can see, this sort of elongates the whole group policy processing cycle.
So let's look at some of the facts around sync versus async processing.
So synchronous processing is obviously slower than asynchronous.
I think this is probably obvious, but for background processing, remember foreground and background.
Background processing always runs asynchronously by definition.
In other words, there is always something else going on.
While background processing is running Windows Server rescues like Windows Server 2000 or two or 2012.
They always run synchronously, so that's just the default and you can't really change it.
It's always synchronous on workstations.
You can actually force always on synchronous processing by enabling this computer's specific policies.
So it would have to apply to computer objects and AD, but you can absolutely get for synchronous processing
if you decided you wanted to do that.
And why would you do that?
Why would you force it all the time?
Well, there are several different policy areas, and I'll talk about this in a little bit that require
a foreground synchronous processing cycle in order to complete.
These include folder redirections, software, installation and then preferences drive mappings before
Windows 8.1.
In the absence of running synchronously, let's say you log on and you've got some of these policy areas
implemented and you've got a synchronous processing set.
What'll happen is the first time you log on the engine will notice that these policy areas that have
been set and it won't be able to process them because it requires that synchronous foreground cycle.
But it will set a flag that says the next time the foreground cycle runs, we need to run it synchronously.
So essentially you get the situation where you might require two separate log ons for the user to receive
their folder redirection software installation or preferences drive mappings.
Of course, if you're setting the flag to run always synchronous, then you're sort of always making
the user way that computer start up and user log on, which is not necessarily a good thing for the
user experience.
So let's dig into this a little bit more on one of our test systems.