Asynchronous group policy processing windows 2008 r2

Default location for saved searches performed from the Search Programs And Files input box on the Start menu. Windows 7 and Windows R2 retain this new profile structure. The new structure uses more folders to organize the data. This is because profiles have evolved over time and the structure of profiles has changed.

Windows XP and Windows Server profiles are called version 1 V1 profiles; profiles using the structure of Windows Vista and Windows Server and later are called version 2 V2 profiles. A V2 user profile folder is distinguished from its predecessors by an added. V2 extension. As you might have noticed in Table , the Local Settings folder from V1 profiles does not exist in V2 profiles, and many V1 profile folders are now consolidated under the AppData folder in V2 profiles.

Why does this reorganization of data matter? One big accomplishment of the V2 profile reorganization is that machine-specific data is now separated from user-specific data. V1 profiles kept machine-specific and user-specific data scattered through the profile.

V2 profiles sort this data and do a better job of separating user-specific data from data that is either too large to roam with the user or is specific to a particular machine and therefore should not roam.

OST file. The changes to the profile structure between the operating systems are one reason why you should not combine Windows 7 and Windows XP VMs in the same pool. First, keeping user data within the profile folder increases the profile size. A large profile increases the time that it takes for users to log on and log off because the data in the profile must be cached on the RD Session Host server. This will cause users a great deal of grief and bring you many unsolvable calls to the Help desk.

The Recycle Bin is a hidden file in the root of the profile folder. The third reason applies to VMs, whether pooled or personal. In the case of a personal desktop, saving files locally preserves them, but it complicates file restore because the files are stored in the VM. Saving the files separately makes it easier to restore them, and the easiest way to do that is to enable Folder Redirection. In the case of pooled VMs, Folder Redirection is essential.

As with mandatory profiles, saving files to local folders on a pooled VM can lead to lost data. That rollback means that any documents saved to the VM would be lost. For now, just know that redirecting profile folders means just that: storing profile subfolders and the data within them, outside the main root profile folder.

This topic will be discussed a lot in this chapter, but to begin, you need to be very clear about why virtualization complicates user profiles and the way users store data. RemoteApp programs running from an RD Session Host server and displayed alongside locally running applications. Figure shows the intricate matrix of user profiles and redirected folders for users who access multiple desktop and RDS environments. Figure Providing a consistent environment for RDS environments becomes more complicated with virtualization.

Using more than one or two types of virtualization can lead to profile proliferation. For example, if you normally work from a desktop running Windows 7 and use RemoteApp for Hyper-V to run a couple of Windows XP applications as RemoteApp programs, then you will have two profiles—one for the RemoteApp session and one for local use.

Add a session to that and you could potentially have three profiles to manage. Similarly, the more server farms that a person will need to access to run RemoteApp programs, the more likely that she will have multiple copies of her profile open at once. This is a good argument against farm proliferation.

Operating systems that use V1 profiles can technically use the same V1 profile and the same goes for operating systems that use V2 profiles.

Whether this is a good idea depends on whether the settings in the profiles are appropriate to both local and remote sessions. Also, keep in mind that if you have a copy of your profile open in two sessions, then you might lose changes if you edit both copies. Documents will default to Documents, images will default to Pictures, and where music is stored by default is left as an exercise for the reader. All will be well. Thus far, you have learned how to set up only a single RD Session Host server.

If the user trying to connect has no current sessions, the RD Connection Broker picks the RD Session Host server with the lowest number of active sessions and sends the user there, as shown in Figure Each time a user connects, the RD Connection Broker decides anew which server the user should connect to, based on the number of connections that each server is actively supporting and whether the user already has a session open somewhere.

The user connects to the server with the fewest active connections or the one where the user already has an open session. It is likely and highly recommended that users will log off when not using their RD Session Host server session, so if you use local profiles for RD Session Host server sessions, then over time, a user will have a local profile on all the servers in the farm.

This might not sound so bad. But when the user makes a change here and there, over time, her desktop will look completely different depending on which RD Session Host server or pooled VM she logs on to. If she makes a bad change, that change could well lead to a Help desk call that can be tricky to figure out until you determine to which RD Session Host server she is connected.

This is especially true because the problem might vanish if the user logs off and then logs back on and the RD Connection Broker sends her to a different RD Session Host server.

To avoid this scenario, all the RD Session Host servers should use the same copy of the profile, which means that you need to use roaming or mandatory profiles stored on a network share.

When a user logs on, the User Profile Service looks at the user account properties to see where the profile reserved for RD Session Host server sessions is kept and loads it from there. When a user logs off, the profile is either deleted from the RD Session Host server or retained in the local cache, depending on the Group Policy settings applied to the RD Session Host servers.

For faster logons, cache the profile. The ways in which you can provide applications to users has grown, and keeping the user experience consistent across these different environments has become even more complicated. Now you must design and implement a profile strategy that takes into account the following. As you offer more ways to present applications to users, delivering user configuration data in the profile gets more complicated.

For example, instead of having users logging onto a single desktop and doing all of their work on that local machine, you can now offer full desktops in a session, RemoteApp programs, personal VMs, pooled VMs, and even RemoteApp programs from VMs. You may find that the expected behavior for a single CSE varies when combined with the processing requirements of other CSEs.

Example 1: Fast Logon Optimization with synchronous processing when the user is not signed in. In this example, the user is not signed in to the computer when there is a change to the user policy setting for a CSE that requires synchronous processing. Synchronous processing was not requested when the user policy setting was last processed. In this example, it takes two sign-ins for the CSE to apply the policy settings. When the user signs in, Fast Logon Optimization is in effect and Group Policy processes asynchronously.

The CSE determines that it requires synchronous processing to apply the new settings. With the current processing session in asynchronous mode, the CSE exits without applying the policy settings, and the CSE signals to the Group Policy engine that synchronous processing is needed for the next sign-in.

At the second sign-in, Group Policy processes synchronously. The Group Policy engine determines that the CSE did not completely process the policy settings during the last sign-in session. Example 2: Fast Logon Optimization with synchronous processing when the user is signed in. In this example, the user is already signed in to the computer when there is a change to the user policy setting for a CSE that requires synchronous processing. The user stays signed in to the computer until Group Policy background processing occurs, and the CSE applies the policy settings after a single sign-in.

When the user stays signed in to a client computer, by default, background processing occurs approximately every ninety minutes. Background processing is always run asynchronously. During this background processing, the Group Policy engine determines that there is a change to the policy settings for a CSE. With the background processing session in asynchronous mode, the CSE exits without applying the policy settings. The CSE signals to the Group Policy engine that synchronous processing is needed for the next sign-in.

During subsequent background refreshes, the CSE is called, but it exits without applying the policy settings because it still requires synchronous processing.

At the next sign-in, Group Policy processes synchronously. The Group Policy engine determines that the CSE did not complete processing during the last sign-in session. A CSE can require synchronous processing and foreground processing to apply settings. The foreground processing requirement is set when the NoBackgroundPolicy registry key is set to a value of 1.

In this case, the CSE applies the policy settings with two sign-ins. For example, the user is signed in to the computer when there is a change to a user policy setting that requires synchronous processing and can only be applied during foreground processing. The user stays signed in to the client computer until Group Policy background processing occurs by default, approximately every ninety minutes.

During background processing, the Group Policy engine determines that there is a change to the policy settings for a CSE, but the NoBackgroundPolicy registry key is set to 1, and the Group Policy engine does not call this CSE during background processing. At the next sign-in, Group Policy processes asynchronously because Fast Logon Optimization is in effect.

This is foreground processing, so the Group Policy engine calls the CSE, which was set to only process in the foreground. The CSE determines that it requires synchronous processing to apply the new policy settings. With the current processing session in asynchronous mode, the CSE exits without applying the policy settings. In this case, it takes two sign-ins for the CSE to apply the settings. This example assumes that only policy settings for a single CSE that requires synchronous processing and foreground processing, have changed.

When you troubleshoot Group Policy, consider that there may be interactions with multiple CSEs, and you may find that the expected behavior for a single CSE varies when combined with the processing requirements of other CSEs.

Group Policy settings or scripts that are applied during startup or shutdown might not be applied on computers that are running Windows 8. The foreground application of Group Policy can be synchronous or asynchronous. In synchronous mode, the computer does not complete the system start until computer policy is applied successfully, and the user logon process does not complete until user policy is applied successfully.

In asynchronous mode, if there are no policy changes that require synchronous processing, the computer can complete the start sequence before the application of computer policy is complete, and the shell can be available to the user before the application of user policy is complete. All policy processing must be completed within 60 minutes. There is no method to modify this time-out period.