Using Windows XP? Don’t Press The F1 Key Warns Microsoft

In what is being described as an ‘unpatched bug in VBScript’. users of Windows XP could be compromised if they press F1 when prompted by rogue web sites. The vulnerability also affects users of Windows 2000 and Windows server 2003 as well. Microsoft has stated that Windows 7, Windows Vista and Windows Server 2008 and not affected. Microsoft describes the vulnerability as being:

“The vulnerability exists in the way that VBScript interacts with Windows Help files when using Internet Explorer,” read the advisory. “If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user.”

Last week, Prodeus called the bug a “logic flaw,” and said attackers could exploit it by feeding users malicious code disguised as a Windows help file — such files have a “.hlp” extension — then convincing them to press the F1 key when a pop-up appeared. He rated the vulnerability as “medium” because of the required user interaction.

Microsoft also has stated that:

Upon completion of this investigation, Microsoft will take the appropriate action to help protect our customers. This may include providing a security update through our monthly release process or providing an out-of-cycle security update, depending on customer needs.

It sounds like a no brainer in that users just need to ignore anything that any web sites wants us to do. LOL

Comments welcome.

Source

Use Group Policy To Deploy Applications In Windows Server 2003 Part II

Through the Microsoft Management Console (MMC) and group policies you can configure a Windows Server 2003 server to automatically distribute software to Windows clients by either assigning or publishing applications. Although the basics of this process are fairly straightforward, there are situations that will require you to use advanced publish and assign options.

For example, if you were installing Office XP onto a system that already had Office 2000, you would probably want Office XP to replace Office 2000 rather than keeping both versions. Advanced publish and assign options allow you to do this and more.

Part I of this article showed you how to get started by opening the Software Installation Properties sheet. Part I also introduced you to two tabs available from the properties sheet: the Deployment tab and the Upgrades tab.

Part II of this article introduces the remaining tabs: Categories, Modifications, and Security.

The Categories tab
The Categories tab allows you to select the categories in which the installation package should be included. By default, the Categories list will be empty because Windows doesn’t come with any existing categories.

You can create categories by right-clicking on the Software Installation container and selecting Properties from the resulting menu to open the container’s Properties sheet. You can then select the Properties sheet’s Categories tab and use the Add button to create categories.

The Modifications tab
The Modifications tab allows you to associate modification files with the installer package. Modification files allow you to create different custom installations for the same application. For example, you could configure different Microsoft Office installations for different departments. Some installations would include the entire Office suite while others would exclude certain applications, such as Access or PowerPoint.

Normally, you won’t have to worry about modification packages because they are rarely used. However, if you do choose to use modification packages, it’s absolutely critical that you apply them in the correct order. Windows tends to be very unforgiving when working with modification files. So it’s essential that you use the Move Up and Move Down buttons to arrange any modification files into the correct order before clicking OK.

The Security tab
The Security tab is where you can build a list of users and/or groups from the present domain and trusted domains.

You may then assign specific rights to each user or group based on which permissions you want them to have pertaining to the installer package. For example, by default, Authenticated Users have Read permissions to the package. Likewise, Domain Admins and the System have full rights to the package. These are usually all the permissions that you need, unless, of course, you wanted to deny permission to a user or group.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=group+policy]

Use Group Policy To Deploy Applications In Windows Server 2003 Part I

Through the Microsoft Management Console (MMC) and group policies you can configure a Windows Server 2003 server to automatically distribute software to Windows clients by either assigning or publishing applications. Although the basics of this process are fairly straightforward, there are situations that will require you to use advanced publish and assign options.

For example, if you were installing Office XP onto a system that already had Office 2000, you would probably want Office XP to replace Office 2000 rather than keeping both versions. Advanced publish and assign options allow you to do this and more.

Getting started
To access the advanced publishing and assigning options, open the MMC, add the Group Policy snap-in, and navigate to the Software Installation container. Right-click on the Software Installation container to access the Software Installation properties sheet. Select the default location of the Windows installer package that you wish to push to your client machines, select the Advanced radio button and click OK. Doing so will return you to the main Group Policy screen.

Then, right-click on the Software Installation container and select New | Package from the resulting menu to display the Open dialog box which lists the contents of default locations that you selected. Next, select the exact Windows Installer (.msi) file you wish to push and click OK. The installation properties window for your chosen .msi file will then be displayed. You can then configure the advanced publish or assign options for your installation through the series of tabs at the top of the window.

The Deployment tab
On this properties sheet you will find the Deployment tab, where you can select whether you want to assign or publish the application. There are also three check boxes that control auto installation by file extension activation, automatic uninstallation, and whether or not the package is visible in the Add/Remove Programs dialog box.

At the bottom of the Deployment tab, you’ll notice an Advanced button. If you click this button, you’ll see a dialog box that contains some advanced diagnostic information, such as the name of the automatic installation script that you’re creating. This dialog box also contains a check box you can select to ignore language options when deploying the package.

The Upgrades tab
The Upgrades tab contains Add and Remove buttons that you can use to build a list of applications that the new application should replace. Once you’ve created the list, select the check box to make the new package a mandatory upgrade to the previously existing package.

When you click the Add button you’ll have the option to select a package from the current group policy object or from another specific group policy object. You can also decide whether Windows should uninstall the old package prior to installing the new package or if Windows can perform an upgrade by installing the new package on top of the previously existing application.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=group+policy]

Group Policy Processing In Windows Server 2003 Part VI

If your network contains a single domain and a couple of DCs, and all computers are on the same network, you really don’t have to concern yourself with indicating the correct target DC when making changes to the group policy. However, if you have multiple domains, DCs, and users with the ability to change the group policy, getting the target right for group policy edits is important. In addition, you could have more than one DC receiving edits, causing edits at other DCs to be lost during replication.

You have two possibilities for specifying options for controlling DC group policy changes:

  • Dynamically through the Group Policy Editor console
  • Dynamically through policies defined in the Administrative Templates branch

To configure the options through the console, open the properties for the domain, click the Group Policy tab, and edit the Default Domain Policy object. Select the root of the object, then choose View | DC Options to display the Options For Domain Controller Selection dialog box.

Options you’ll find on this screen include the following:

  • The One With The Operations Master Token For The PDC Emulator: This option causes Windows Server 2003 to use the same DC as the target for all group policy creation and editing, with all other DCs receiving updates through replication. This ensures that you don’t experience editing collisions caused by multiple concurrent policy changes on different DCs. With this option selected, the Group Policy console automatically focuses on the specified DC. Typically, the DC with the Operations Master token is the first DC created in the domain, although this can change.
  • The One Used By Active Directory Snap-Ins: This option enables you to select a DC when using the Group Policy console snap-ins. As long as you select the right one, edits happen on the selected DC. Selecting the DC, however, is a conscious, manual process, inviting error. If you forget to change the focus and inadvertently make changes on the wrong DC, those edits could be lost during replication or cause other problems, so use this option with care.
  • Use Any Available Domain Controller: This option allows changes to be made on any DC, making it the least desirable option. If you have only a few DCs and only one person making policy changes, then this option is acceptable.

If you prefer to establish these options through a policy (a better method as it then applies to all administrators), configure the policy settings at the domain level. Open the Default Domain Controller GPO and modify the policy User Configuration/Administrative Templates/System/Group Policy/Group Policy Domain Controller Selection as desired. The available options are the similar to those discussed above and include:

  • Use the Primary Domain Controller
  • Inherit from Active Directory Snap-ins
  • Use any available domain controller

At this point, you should have a relatively good understanding of what group policy objects are and how they enable you to apply policies, at least in a general sense. You also should have enough information to start planning a group policy implementation.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

Group Policy Processing In Windows Server 2003 Part V

Another important question to ask is ‘how are GPOs applied over slow links?’. Although most users log on over a relatively high-bandwidth connection such as a LAN, remote and roaming users often log on through low-bandwidth dial-up connections. Other factors can affect connection bandwidth as well. During group policy processing, Windows Server 2003 uses a relatively complex method to determine the connection speed.

Windows Server 2003 first attempts to ping the server, making several attempts to determine an average transmission rate. Failing the ping, Windows Server 2003 measures the connection speed by testing file system performance, the same method used in Windows NT. If Windows Server 2003 detects a slow connection, it processes the group policies as follows:

  1. The security policy is processed.
  2. The policies in Administrative Templates are processed.
  3. The software installation is not processed.
  4. The scripts are not processed.
  5. The folder redirection is not processed.
  6. The Internet Explorer maintenance is not processed.

You can configure the slow-link behavior through the Computer Configuration/Administrative Templates/System/Group Policy/Group Policy Slow Link Detection policy of the group policy object and for user policies through the same node of the User Configuration branch. You can configure these settings for each GPO, enabling you to apply group policies differently for each GPO across a slow link.

As mentioned above, Windows Server 2003 updates group policies automatically based on the refresh interval you specify for group policies, with the default refresh interval being 90 minutes. You can force a group policy refresh in between automatic refreshes, if needed. You can refresh the Computer Configuration policies and User Configuration policies separately.

To refresh Computer Configuration policies, select Run from the Start Menu. In the Run dialog box, type gpupdate /target:computer /force and click OK.

To refresh User Configuration policies, select Run from the Start menu. In the Run dialog box, type gpupdate /target:user /force and click OK.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

Group Policy Processing In Windows Server 2003 Part IV

By default, GPO processing is synchronous, which means that the processing of one GPO must be complete before processing of the next one begins. Computer Configuration policies apply at system startup, and User Configuration policies apply at logon and complete prior to the user interface becoming available to the user.

In most cases, you’ll want to continue to use the default synchronous behavior. You can, however, configure Windows Server 2003 to process policies asynchronously. With asynchronous mode, GPO processing can occur simultaneously and on multiple threads, providing better performance and faster processing. To ensure reliable application of policies — particularly where certain policies need to override policies set at lower levels — you should use synchronous mode. Use asynchronous mode only when performance is an issue, and then use it judiciously.

You configure GPO processing mode through the Default Domain Policy. To do so, open the Active Directory Users And Computers console. Right-click the domain and choose Properties. When the Properties window appears, choose Default Domain Policy and click Edit. Next, Expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Double-click the Group Policy Refresh Interval For Computers policy, click Enabled, and then set the interval and the offset range. When finished, click OK and close the Group Policy console.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

Group Policy Processing In Windows Server 2003 Part III

Windows Server 2003 automatically refreshes GPOs every 90 minutes by default, although it applies a randomized 30-minute offset interval to the refresh period to ensure that large groups of users don’t refresh their GPOs at the same time. Refreshing the GPOs ensures that changes to group policies are implemented in a timely manner.

You can tailor the refresh rate to your network’s needs. Increasing the refresh interval can help reduce network traffic if you seldom change policies. Decreasing the refresh interval causes group policy changes to be applied more quickly and is desirable whenever you expect to change policies more frequently or want to make sure that changes apply in a timely fashion. Decreasing the refresh interval also causes more network traffic, however, this is a factor you should consider when deciding on the refresh interval.

You can specify an interval as low as seven seconds or as high as 45 days. Obviously, high intervals such as the maximum are relatively useless, since changes should be applied much more quickly in almost all situations. Very short durations are also undesirable in most situations because of the excessive network traffic they create.

You specify the GPO refresh interval through the Default Domain Controllers GPO. To do so, open the Active Directory Users And Computers console. Right-click the domain and choose Properties. Choose Default Domain Policy and click Edit. Expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Next, double-click the Group Policy Refresh Interval For Computers policy, click Enabled, and then set the interval and the offset range. Finally, click OK and close the Group Policy console.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

Group Policy Processing In Windows Server 2003 Part II

In most cases, a user who logs on from a workstation should have his group policies applied based primarily on the settings defined by the user object in the Active Directory rather than their computer object. A user who logs on from a computer that’s part of the server’s OU, however, should take his settings from the computer’s object location rather than the user object. There can be many other situations in which you want the computer object’s GPO(s) to take precedence over the user object, as determined by your organization’s structure, computer function, and so on.

Group policy loopback is supported only in pure Windows 2000 and Windows Server 2003 environments (both clients and domain controllers). Group Policy loopback enables group policies to be applied based only on the computer from which the user logs on. Loopback provides for two processing modes:

  • Merge mode: In this mode, Windows Server 2003 processes the group policies for the User Configuration first, followed by those for the Computer Configuration. In effect, this causes the Computer Configuration group policies to have precedence over any User Configuration settings. When the Computer Configuration object doesn’t specify a given policy, the User Configuration object defines the policy setting.
  • Replace mode: In this mode, Windows Server 2003 processes only the Computer Configuration group policies, ignoring the User Configuration group policies.

Keep in mind that in either mode, the user might have several GPOs applied. For example, the user might be affected by a site GPO, a domain GPO, and two OU GPOs. When the client retrieves the GPO list from the DC, the contents of the list are determined by the loopback mode. With merge mode, the client requests the list normally (based on the user location in the AD) and then submits a second request based on the computer location. The result is that GPOs might actually be processed twice.

In this example, the initial GPO list and order of processing are GPO1, GPO2, GPO3, and GPO4. When the second request based on the computer location is fulfilled, the response is added to the list, resulting in a final GPO process list of GPO1, GPO2, GPO3, GPO4, GPO1, GPO2, GPO5, and GPO6. In the case of replace mode, the client requests the list based only on the computer location in the AD, giving the result GPO1, GPO2, GPO5, and GPO6.

Setting the loopback mode

To set the effective loopback mode, open the Active Directory Users And Computers console, right-click the container in which you want to apply the loopback setting (site, domain, or OU), and choose Properties. When the Properties window appears, click the Group Policy tab.

Select the group policy in which you want to define the loopback setting and choose Edit. Next, expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Double-click User Group Policy Loopback Processing Mode, select Enabled, then select either Merge or Replace from the drop-down list. Click OK to close the dialog box, then close the Group Policy console.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

Group Policy Processing In Windows Server 2003

In a previous series of articles on Windows Server 2003 group policy, I described what group policies are and how they work. The next question to ask is ‘How does Windows Server 2003 apply group policies?’

Before you can fully understand the implications of group policies, you need to see how Windows Server 2003 applies them. In this series of articles, I’ll look at how Windows Server 2003 applies the group policies you create.

Which comes first?

Windows Server 2003 processes the local group policy object (GPO) first, followed by the site, domain, and applicable organizational units (OUs). The client requests a GPO list from the domain controller (DC) and then processes that list to apply the policies contained in the GPO(s). The client processes the GPOs according to the priority in the DC-supplied list. Windows Server 2003 processes GPOs at startup, logon, and when the GPO refresh period is reached, which by default is 90 minutes.

One the client side, a group of DLLs — referred to as client-side extensions — perform the group policy processing. Each DLL is responsible for specific policies. Below is a list of the client-side extensions and the policies they process.

  • Registry: Userenv.dll
  • Disk Quota: Dskquota.dll
  • Folder Redirection: Fdeploy.dll
  • Scripts: Gptext.dll
  • Software Installation: Appmgmts.dll
  • Security: Scecli.dll
  • IP Security: Gptext.dll
  • EFS Recovery: Scecli.dll
  • Internet Explorer Maintenance: Ledkcs32.dll
  • Remote Installation Services: None

Each GPO can include policy settings for both User Configuration and Computer Configuration. The client gives precedence to the Computer Configuration policies over the User Configuration policies by processing the User Configuration policies first. In some situations, this precedence can cause unexpected results. For example, a user’s computer might reside in one OU and the user account in a different OU. So how do you determine which GPO is applied? Group policy loopback lets you control that behavior.

[rsslist:http://lockergnome.4jobs.com/MKT/RSS/rss.asp?key=windows+server+2003]

How To Trim Down A Windows Install For A Virtual Machine

Over at Lifehacker, Adam Pash has written an article describing in some very useful detail how to use a couple freeware apps to trim down a Windows XP installation so you can create a lighter-weight install disc for whatever purpose you may have.

I’m interested in this because I plan (at least at this point) to use a Windows Server 2003 install disc as the starting point for a VMWare Fusion virtual machine on my MacBook Air, and I want to keep it as lean and mean as I possibly can. That way I can run the couple/few Windows apps that I really need to make my computer life complete.

Why Windows Server 2003? Because I have a couple unused copies sitting on my shelf just screaming to have the shrink-wrap removed. Come to think on it, it might be the first time I have opened an actual shrink-wrapped Windows Server box since around 2000. I’ve grown quite used to electronic delivery and volume licensing discs. Wow.

Does anyone have any solid information that would point to benefits of using the 64-bit edition of Server 2003 over the 32-bit version? If so, please let me know!

I’ll report back with results after I get it all set up. Should be interesting and a bit of fun.

Group Policy Objects In Windows Server 2003 Group Part IV

Assume that you’ve just spent several days creating a GPO to link to a particular OU and have tested and verified that the policies it contains are correct. Also assume that you have two other OUs that need to use the same policies. You don’t really want to re-create those policies twice more, do you? Fortunately, you don’t have to. You can link a given GPO to multiple objects, so once you’ve created the GPO, you can easily use it in other objects simply by linking the GPO to the object.

In this example, assume you have an OU named Help Desk and want to apply the GPO previously created for the Support OU to the Help Desk OU. You link the GPO to the Help Desk OU from the OU. To do so, open the Active Directory Users And Computers console, right-click the Help Desk OU, and choose Properties. Click the Group Policy tab, then click Add. In the Add A Group Policy Object Link dialog box select the GPO you want to link to the OU and click OK. In this case, click the All tab, select the Test Support GPO, and click OK. Then, click OK to close the Help Desk Properties sheet.

Deleting links and GPOs
There will no doubt come a time when you need to either delete a link to a GPO or delete the GPO itself, and it’s important to understand that the two actions are quite different. I’ll use a desktop shortcut as an analogy. Say that you create a shortcut on your desktop to an application. When you delete the shortcut, the application is unaffected. Go to the application’s folder and delete its executable, and the program is gone. Its remnants, however, are still floating around the registry because you didn’t remove it properly.

The same is true for GPOs and links. When you delete a link, the associated GPO is unaffected. Delete the GPO itself, however, and it’s gone.

As with other GP processes, you can delete links and GPOs through the properties for the object to which the GPO is linked. For example, assume you now need to remove the link between the Test Support GPO and the Help Desk OU because you need to apply a different set of policies. In that case, open the Active Directory Users And Computers console, right-click the Help Desk OU, and choose Properties. On the Group Policy tab, select the GPO link from the list and click Delete. Windows displays a dialog box that gives you two options:

  • Remove the link from the list
  • Remove the link and delete the Group Policy Object permanently

Select the desired action and click OK.

Exercise some care when you delete GPOs. Windows provides no warning if a GPO you’re deleting is linked to other objects. Delete the Test Support GPO from the Help Desk OU, for example, and it’s gone from the Support OU as well.

Configuring local group policy
You’ve read previously that Windows Server 2003 applies the local group policy first and then applies GPOs at the site, domain, and OU levels. So in addition to modifying GPOs for the upper levels, you might also want to modify the local GPO. Each computer has only one local GPO.

As with other GPOs, you get to the local GPO through the group policy snap-in. Open the MMC and add the group policy snap-in, and when prompted for the location of the GPO, retain the default Local Computer focus and click Finish.

You also can open the local GPO of other computers across the network. Rather than accept the Local Computer default, click Browse, then click the Computers tab. Select the Another Computer option, then type the computer name in the field provided or click Browse to locate it.

Group Policy Objects In Windows Server 2003 Group Part III

Simply creating a GPO doesn’t modify any policy settings. If you don’t modify any settings, the GPO won’t have any effect. So now it’s time to set some policies in each of the test GPOs you just created. As mentioned before, you can get to the GPO through the properties for the object where the GPO is linked. Just right-click the object, choose Properties, click the Group Policy tab, select the GPO, and click Edit. In this example, however, we’ll use the custom console instead.

Open the branch containing the policy you want to edit. In this example, we’ll focus on the Test Support GPO. Expand the Test Support GPO branch, and you should see two items under it: Computer Configuration and User Configuration, each of which has several branches of its own.

Knowing where all the policy settings are is a pretty tall order at first. Actually defining the policies is pretty easy. Just expand the branch where the policy is located, double-click the policy, and select Define This Policy Setting. The GP console enables the associated policy setting, which varies from one to another. In some cases, you simply select either Enabled or Disabled. Other policy settings require other data that varies according to the policy’s function.

For example, you can configure policies that define how services start, setting a particular service to Manual, Automatic, or Disabled. Or, you can define policies that determine the startup, shutdown, logon, and logoff scripts that apply within the selected GPO.

Another example of policies that require much more than a simple Enable/Disable toggle is the IP Security (IPSec) policies. You can define IPSec policies to force implementation of desired IPSec filters. Another good example is the User Configuration/Software Settings/Software Installation node, which enables you to define application installation packages for the Windows Installer that install automatically or are available for installation by users who fall under the influence of the selected GPO.

Explaining every branch in the GP editor, much less each policy setting would take a book in itself to present adequately. For now, just understand that the GP editor lets you define group policies and that you can access the GP console through the properties for the container where a given GPO is linked or through a custom MMC to which you’ve added the group policy snap-in focused on a specific site, domain, or OU (or the local GPO).

Group Policy Objects In Windows Server 2003 Group Part II

You modify GPOs through the Group Policy editor, an MMC snap-in. You can open the Group Policy snap-in directly through the MMC or access it through the properties for the AD container to which you want to link the GPO or whose existing GPO you want to modify.

For example, open the Active Directory Sites And Services console, right-click a site, choose Properties, and click the Group Policy tab. You’ll see all the existing GPOs linked to that site. Or, open the Active Directory Users And Computers console, right-click a domain, choose Properties, and click the Group Policy tab to work with the GPOs linked to the selected domain. Select a GPO and click Edit, and the Group Policy editor opens focused on the selected GPO.

If you open the GP console from the properties for an object, such as a domain or OU, the console is automatically focused on that object. You can configure the console to allow the focus to be changed when the console is opened from the command prompt, but it’s easiest to simply add a GP snap-in for each GPO you want to manage. For example, assume you need to manage a GPO that is linked to a domain, one site GPO, and two OU GPOs. The easiest way to get to all of those is to combine all of them into a single, custom MMC.

To create the custom MMC, select Run from the Start menu. In the Run dialog box, type MMC and click OK. When the MMC starts, select Add/Remove Snap-In from the Console menu and click Add. Select Group Policy and click Add. In the Select Group Policy Object dialog box, click Browse and choose the level at which you want to select the GPO or click the All tab to view all GPOs. Select the GPO you want to add to the console and click OK. Click Finish. Finally, close the Add/Remove Snap-In dialog box and save the console.

For the purpose of this article, we’ll create three test policies. Use the previous steps to add the Test Site Policy, Test Domain Policy, and Test Support GPO to your console. Once you are finished, the console should have three snap-ins added – one for each of the test GPOs.

Group Policy Objects In Windows Server 2003 Group Part I

In previous series of articles, I introduced you to the concept of Windows Server 2003 group policies. In this series of articles, I’ll dig deeper into group policies by showing you how to create and work with them. I’ll cover the nuts and bolts of group policy object (GPO) creation and application to help you start to build and assign GPO objects and apply them across the enterprise.

Creating group policy objects
As a quick refresher, a GPO is a named collection of group policy settings that you link to specific containers in Active Directory (AD). You can link GPOs to sites, domains, or Organizational Units (OUs). Each computer also has a local GPO.

A given GPO can link to multiple objects at various levels in the AD. For example, a particular GPO might link to several domains in a site or to several OUs in a domain. Windows Server 2003 applies group policy using a hierarchical structure, applying the local GPO first, followed by the GPOs at the site, domain, and OU levels.

We’ll take a look shortly at the group policy (GP) snap-in. First, however, let’s create a few GPOs-one at the site level, one at the domain level, and another at an OU level. If you don’t have an OU in the domain in which you’re going to create your test GPOs, create one now. For this example, assume that you have an OU named Support in your domain.

To create the domain OU, open the Active Directory Users And Computers console. Right-click the domain in the left pane and choose Properties. Click the Group Policy tab. You should see one existing policy, the Default Domain Policy. Click New to create the GPO, type the name Test Domain Policy, and press [Enter]. Click Close.

Next, create a test OU GPO. Begin by creating a new OU within the domain called Support. Still in the AD Users And Groups console, right-click the Support OU and choose Properties, then click the Group Policy tab. Click New, type Test Support GPO, press [Enter], and click Close.

Finally, let’s create a GPO at the site level. Open the Active Directory Sites And Services console. Right-click the site in the left pane and choose Properties. Click the Group Policy tab, click New, type Test Site Policy, press [Enter], and click Close.

Now you have three GPOs created and linked to three objects: a site, a domain, and an OU. You could bounce back and forth between the AD Users And Groups console and the AD Sites And Services console to manage them, but why not save yourself a little work and combine them all into a single console? Read Part II to find out how.

Importance Of Windows Server 2003 Group Policies Part IV

Group policies enable you to control a wide range of capabilities and actions. The ones you address depend on your situation and how they impact your users and systems. The following list summarizes the key issues to address:

Hardware changes: You can use change control to prevent users from changing existing hardware settings such as display resolution, drive settings, and so on. You can prevent them from changing drivers or installing additional drivers, which helps protect against systems going down because of faulty drivers.

Application installation and changes: Use change control to prevent users from installing applications or changing existing installations. This helps control problems caused by buggy applications and/or viruses and Trojan horses introduced through shareware or freeware (and not unheard of, but less common with, commercial applications).

Security needs: Use change control to define whether users can use encryption, IPSec, and other security features. This partly helps keep users out of trouble and helps protect against such situations as a user encrypting his or her documents and then leaving the company after deleting his/her certificates. Although you can recover the encrypted data, it can be a protracted process and at best, an annoyance.

Network requirements and settings: Prevent users from making changes to their network settings or installing additional network clients or services.

Access to services: Control users’ ability to access and add, remove, change, or control services.

Local and network resource access: Define the actions that users can take in connecting to and using local and network resources.

Environment settings: You can employ change control over a wide variety of settings that control the user’s working environment including the desktop, mapped drives, printers, and so on. Group policies give you an exceptional level of control over the user’s environment and therefore the types of tasks the user can and can’t perform.

In addition to the types of change control described above, you’ll find that as you become comfortable with group policies they will play an increasingly important role in how you administer your network. You’ll use group policies not only to apply change control at the workstation and server level but also to apply granular security and distributed administration to such services as DNS and DHCP, control application installation and deployment, and much more.