Switching Between Scenarios

  • Article

Applies To: Windows Server 2003 with SP1

Joining a particular scenario is relatively simple – move the appropriate computer and user accounts into OUs to which the appropriate scenario GPOs have been linked. For example, if a user is to experience the Multi-User scenario, his or her account must exist in an OU to which the Multi-User (User) GPO has been linked and must log on to a computer in an OU to which the Multi-User (Computer) GPO has been linked.

In general, moving between scenarios is simply a matter of moving computers and users into the appropriate OUs. However, you might need to do some additional work to complete the transition between scenarios related to security settings and Roaming User Profiles.

Note that moving users between OUs requires a logon to ensure that this is reflected and that the appropriate GPOs are applied. Similarly, moving a computer to a different OU requires that the computer is restarted for the new OU to be recognized.

Security Settings

A number of security settings “tattoo” the registry – once applied through a GPO, they remain active even when the GPO is moved out of scope for the target computer or user (by unlinking the GPO, moving the account from an affected OU, or disabling the GPO). Therefore, simply switching a computer or user account to an OU associated with a different scenario will result in some settings from the original scenario remaining. This is particularly evident when transitioning to a scenario with fewer security settings than the original.

There are a number of options to address this issue:

  • Ensure that the GPOs associated with the new scenario explicitly disable/enable security settings that have been set in the GPOs associated with the original scenario. For example, if a security setting is configured in a GPO for the original scenario, the GPO for the new scenario must configure that security setting, even if the security setting isn’t directly relevant to the new scenario. While this makes for a more deterministic application of these settings (the eventual result of the security setting is independent of the configuration in the original scenario), this does result in all GPOs needing to include the superset of all possible security settings, which can be cumbersome to manage and track.

  • Temporarily move the computer and user accounts to a “clean up” OU that explicitly sets all security settings to a default state. After these have been implemented (allowing Group Policy to refresh by waiting at least 120 minutes or by using the gpupdate command), the accounts are moved to the appropriate OUs for the new scenario. One drawback with this approach is the potential for a delay to ensure that the temporary policy settings are applied to the computer and user accounts. Additionally, it is necessary for the user account be used to log on at least once to ensure that the “clean up” GPOs associated with user-based security settings are applied.

  • As an administrator on the target machine, manually remove the security settings that no longer apply. This is clearly the most labor-intensive approach, requires significant knowledge of how each security setting is implemented, and is generally not an option with a significant number of computers.

Roaming User Profiles

The Roaming User Profile attribute for a user (the location of the roaming profile, if set) is stored in the user account object within Active Directory. Due to the order in which profiles are applied, as related to the application of Group Policy, this parameter cannot be set through Group Policy. As such, if a user moves between scenarios where the use of Roaming User Profiles changes (for example, where the initial scenario uses a Roaming User Profile but the target scenario does not), then it is necessary to update the user object to reflect this change.