Now that you know how GPOs are processed, what can
you do with them anyway? The GPO that was used on Windows Server 2003
and Windows XP had about 1,700 settings (1,671, as of March 31, 2005).
The new GPO for Windows Vista has approximately 2,500 settings (2,495
with the initial release of Vista, to be exact). So what can you do with
a GPO in Windows Vista? A lot and then some. The truth is that every
configurable parameter of the operating system and every configurable
parameter of every application that uses the Registry can be controlled
with a GPO. Even if the Registry key or value doesn’t exist, it can be
added by GPO and then configured by GPO. So the real answer is that
approximately everything on the computer that uses or could use the
Registry can be controlled by GPO.
The next intelligent
question might be “So what are they going to test me on?” That is an
excellent question. You’re going to look at a handful of specific GPO
uses and settings that are potential targets on the exam.
Caution
GPOs Are Powerful Mojo GPOs can cause you significant trouble if
you create and link them in the wrong places. If you are following along
with the book on these settings, banging around inside GPOs, toggling
on and off settings, and so on, it is a good idea to create yourself a
new, empty OU to link your new trial GPOs to. I usually call my bogus
OUs BOGUS.
Then you can create user objects and computer objects, place them inside
the BOGUS OU, link your new GPOs to the BOGUS OU, and then test the
GPOs. Use extreme caution if you plan to have the GPO affect the
computer that you use regularly. GPOs can and will change a computer’s
behavior, and sometimes for the worse. You actually need at least one
computer to test out the computer settings. Virtual
machines perhaps?
Desktop Settings
One of the first target
areas has to do with locking down your Desktop settings. Remember that
GPOs have two halves: the computer configuration half and the user
configuration half. Desktop settings are user-based settings, so you can
find these settings in a GPO under User Configuration >
Administrative Templates > Desktop, as shown in Figure 1.
Software Deployment by
GPO
The next area to look at
is software deployment GPOs. These are used to deploy applications to
many computers or users automatically, over the network.
Software can only be assigned to the
computer by GPO. Software can also be published
or assigned
to the user by GPO. The exam question should identify if the target is
the computer or the user. Read the exam question carefully.
Alert
If a software deployment package is assigned to either the
computer or user, it is mandatory and is not optional. The software is
deployed at computer bootup or at user logon (unless a slow link is
detected).
If the software deployment package is published to the
user, it is optional and you may, at your discretion, choose to install
the software or choose not install the software (again, unless a slow
link is detected).
If the software is assigned
to the computer, it is installed at computer bootup, by default. If the
software is assigned to the user, it is installed at user logon, by
default. If the software is published to you (the user), you have to
install the application by using Control Panel > Programs > Get
Programs.
Applications can also be
configured for deployment by enabling the Auto-install This Application
By File Extension Activation setting. This means that if the application being published is Excel, for
example, you might trigger its installation by double-clicking on a file
with an .xls extension.
GPOs can be used
to deploy application software packages with the following extensions:
.MSI— A Microsoft Installer package. This is the
preferred software deployment package format. These files can be
installed automatically, uninstalled automatically, and even repair
themselves (application maintenance) if any of the application’s files
on the client computer go missing or corrupt.
.MST— A Microsoft Transform file. These files are used
to modify the installation behavior of an .MSI
package—for example, to deploy only Word and Excel from the MS Office
suite.
.MSP— A Microsoft Patch file. These files are used to
deploy patches for Microsoft and third-party applications. (MS
application patches are usually deployed through Microsoft Update these
days.)
.ZAP— A script file used to deploy software packages that
do not have an .MSI file for
deployment. This script must be created by an administrator to deploy
software when all that is available is a Setup.exe, or the like. Although these files can be used to
deploy software, the .ZAP file cannot
be used to maintain or automatically uninstall the deployed software.
The software deployment
package must reside on a network share, and users must have at least
Allow—Read permissions on the share and on the NTFS permissions for the
package. This network share point is called the Software Distribution
Point (SDP).
Note
Software Distribution
Point Permissions Typically, domain
administrators are granted Full Control permissions to the SDP and
content so they can do whatever they might need to do to maintain and
fix any issues that might occur with the software deployment packages.
Alert
Remember
that only the .MSI software deployment
packages can be used to automatically uninstall deployed software. You
can configure the deployment package to uninstall at next bootup
(computer) or Logon (user), or you can configure the GPO to uninstall
this application when it falls out of the scope of management. This
setting uninstalls the software automatically if the user or computer
gets moved from the container (S-D-OU) that the software deployment GPO
is linked to, or if the GPO is removed from the container that holds the
user or computer. This GPO configuration setting is shown in Figure 2.
