Deploying GPO for Windows Vista

from Microsoft

Note :
Do not download or use the older version of GPMC (v 1.0) in Windows Vista because it is not compatible with Windows Vista.

Read consumption(below) first!!!

1.Recommended rollout
- Upgrade the Group Policy administrators' workstations to Windows Vista. All Group Policy management will now be done from the computers running Windows Vista.
- (Optional) Create a Central Store on SYSVOL for each Active Directory Primary Domain Controller (PDC), where Group Policy is managed by administrators running Windows Vista. Populate the Central Store on each PDC with ADMX/ADML files from the Group Policy administrator's Windows Vista workstation. Read the Managing Group Policy ADMX Files Step-by-Step Guide at
- Create new GPOs (or update the existing GPOs) to include the new Windows Vista Group Policy settings you may wish to use.
Note You may wish to link these GPOs to the OU that will contain new Windows Vista domain-joined workstations.
Note In rare cases, you may need to extend the AD schema to accommodate the new settings.
-Deploy Windows Vista workstations per the deployment project.

2. Create a central store

- Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.
- Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use. Each subfolder is named after the appropriate ISO-style Language/Culture Name. For a list of ISO-style Language/Culture Names, see
Locale Identifiers .

3. Populate the central store with ADMX files

-Open a command window: Click Start, click Run, and type cmd, and then press ENTER.
-To copy all language-neutral ADMX files (.admx) from your Windows Vista administrative workstation to the central store on your domain controller using the copy command, type:
copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\
-To copy all ADMX language-specific resource files (.adml) from your Windows Vista administrative workstation to the central store on your domain controller using the copy command, type:
copy %systemroot%\PolicyDefinitions\[MUIculture]\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\[MUIculture]\

4. Download new schemas

Note : Extending the schema is needed only if you need the wireless and wired Group Policy enhancements or if you need the BitLocker Group Policy enhancements.

5. Group Policy changes after migrating or upgrading to Windows Vista

After migrating or upgrading to Windows Vista, Group Policy is reapplied as if it were done on a clean installation. For clients in a Windows domain, Group Policy will be applied as if the computer had just joined the domain or as if the user had logged in for the first time. Each extension will either migrate its policy settings or apply these policy settings when applying Group Policy for the first time in the domain. After the upgrade, the Group Policy engine will process policy settings similar to a clean installation, regenerate all RSoP data, and set up all its cached values.
List of non migrating components :
GP Engine
ADM templates
Registry-based policy settings
Software installation
GPMC and GPEdit

Consumption of Windows Vista settings

1. Group Policy Scripts can fail due to User Account Control
To get around this problem, use the launchapp.wsf

2. Group Policy service cannot be stopped

The registry-based Group Policy settings in this section require either a reboot or a logon when they are enabled. The bulleted items in this section contain the name of the Group Policy setting followed by its function.
•Do not allow window animations: This policy setting controls the appearance of window animations such as those found when restoring, minimizing, and maximizing windows.
•Do not allow desktop composition: This policy setting controls how some graphics are rendered, and facilitates other features, including Flip, Flip3D, and Taskbar Thumbnails.
•Do not allow Flip3D invocation: This polciy setting disables the 3D window switcher.
•Specify a default color: This policy setting controls the default color for window frames when the user does not specify a color.
•Do not allow color changes: This policy setting controls the ability to change the color of window frames.
•Verbose vs. normal status messages: This policy setting directs the system to display highly detailed status messages.
•Set action to take when logon hours expire: This policy setting controls which action will be taken when the logon hours expire for the logged-on user.
•Set action to take when logon hours expire: This policy setting controls which action will be taken when the logon hours expire for the logged-on user. The actions include lock the workstation, disconnect the user, or log the user off completely.
•Report when logon server was not available during user logon: This policy controls whether the logged-on user should be notified if the logon server could not be contacted during logon, and the user has been logged on using previously stored account information.
•Custom user interface: This policy setting specifies an alternate user interface.
•Turn off Tablet PC touch input: This policy setting turns off touch input, which allows the user to interact with their computer using their finger.
•Turn off Windows Defender: This policy setting turns off Windows Defender Real-Time Protection, meaning no more scans are scheduled.
•Turn off legacy remote shutdown interface: This policy setting controls the legacy remote shutdown interface (named pipe). Pipe remote is needed in order to shut down this system from a remote Windows Server 2003 or Windows XP system.

3. Folder Redirection interoperability
Computers running Windows Vista cannot read roaming user profiles created from Windows XP. This creates a problem for users who have a roaming user profile but must roam from Windows Vista and Windows XP computers. Windows Vista Folder Redirection makes this possible.

4. Network Access Protection and Network Location Awareness

When a client computer attempts to access the network, it must present its system health state. If a client computer cannot prove it is compliant with system health policy, its access to the network will be limited to a restricted network segment containing server resources so compliancy issues can be remedied. After the updates are installed, the client computer requests access to the network again. If compliant, the client computer is granted unlimited access.
Keep in mind that NAP is not a security solution. It is designed to help prevent computers with unsafe configurations from connecting to a network—not to protect networks from malicious users who have valid sets of credentials and computers that meet current health requirements.
On the client computer side, the Network Location Awareness (NLA) feature enables the system to receive notifications when connectivity to the domain controller is established, and the Group Policy service makes a determination whether to apply policy settings for that event. However, NLA does not recognize the transition from a quarantine environment (in other words, a NAP environment) to a corporate environment; therefore, NLA will not provide Group Policy with network notifications when the computer comes out of quarantine.
Because NLA does not provide notifications for successful network connectivity after quarantine, the following workaround can be provided. The NAP component records an event in the log files. The administrator needs to write a script that will detect this event, which calls gpupdate to ensure that Group Policy is refreshed during a successful VPN connection.

Original Microsoft's Document is here.

No comments:

Recent Posts