Step-by-Step Guide to Understanding the Group Policy Feature Set

This step-by-step guide presents a brief overview of Group Policy, and shows how to use the Group Policy snap-in to specify policy settings for groups of users and computers.

On This Page

	Introduction
	Overview
	Group Policy and the Microsoft Management Console
	Appendix
	Additional Resources

Introduction

Step-by-Step Guides

The Microsoft Windows Server 2003 Deployment step-by-step guides provide hands-on experience for many common operating system configurations. The guides begin by establishing a common network infrastructure through the installation of Windows Server 2003, the configuration of Active Directory^®, the installation of a Windows XP Professional workstation, and finally the addition of this workstation to a domain. Subsequent step-by-step guides assume that you have this common network infrastructure in place. If you do not wish to follow this common network infrastructure, you will need to make appropriate modifications while using these guides.

The common network infrastructure requires the completion of the following guides.

Once the common network infrastructure is configured, any of the additional step-by-step guides may be employed. Note that some step-by-step guides may have additional prerequisites above and beyond the common network infrastructure requirements. Any additional requirements will be noted in the specific step-by-step guide.

Microsoft Virtual PC

The Windows Server 2003 Deployment step-by-step guides may be implemented within a physical lab environment or through virtualization technologies like Microsoft Virtual PC 2004 or Microsoft Virtual Server 2005. Virtual machine technology enables customers to run multiple operating systems concurrently on a single physical server. Virtual PC 2004 and Virtual Server 2005 are designed to increase operational efficiency in software testing and development, legacy application migration, and server consolidation scenarios.

The Windows Server 2003 Deployment step-by-step guides assume that all configurations will occur within a physical lab environment, although most configurations can be applied to a virtual environment without modification.

Applying the concepts provided in these step-by-step guides to a virtual environment is beyond the scope of this document.

Important Notes

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, places, or events is intended or should be inferred.

This common infrastructure is designed for use on a private network. The fictitious company name and Domain Name Service (DNS) name used in the common infrastructure are not registered for use on the Internet. You should not use this name on a public network or Internet.

The Active Directory service structure for this common infrastructure is designed to show how Windows Server 2003 Change and Configuration Management works and functions with Active Directory. It was not designed as a model for configuring Active Directory for any organization.

Top of page

Overview

Group Policy settings define the various components of the user's desktop environment that a system administrator needs to manage, for example, the programs that are available to users, the programs that appear on the user's desktop, and options for the Start menu. Group Policy settings that you specify are contained in a Group Policy object (GPO), which in turn is associated with selected Active Directory objects—sites, domains, or organizational units (OUs).

Group Policy applies not only to users and client computers, but also to member servers, domain controllers, and any other Windows Server 2003 computers within the scope of management. By default, Group Policy that is applied to a domain (that is, applied at the domain level just above the root of Active Directory Users and Computers) affects all computers and users in the domain. Active Directory Users and Computers also provides a built-in Domain Controllers OU. If you keep your domain controller accounts there, you can use the GPO Default Domain Controllers Policy to manage domain controllers separately from other computers.

GPOs are linked to site, domain, and OU containers in Active Directory. The default order of precedence follows the hierarchical nature of Active Directory: sites are first, then domains, and then each OU. A GPO can be associated with more than one Active Directory container, or multiple containers can be linked to a single GPO.

A GPO can be used to filter objects based on security group membership, which allows administrators to manage computers and users in either a centralized or a de-centralized manner. To do this, administrators can use filtering based on security groups to define the scope of Group Policy management, so that Group Policy can be applied centrally at the domain level. Or, it can be applied in a decentralized manner at the OU level and can then be filtered again by security groups. Administrators can use security groups in Group Policy to:

Several administrative tools are available for the management of Group Policy settings including:

Group Policy includes policy settings for User Configuration, which affect users, and for Computer Configuration, which affect computers.

With Group Policy, you can do the following:

This document presents a brief overview of Group Policy, and shows how to use the Group Policy snap-in to specify policy settings for groups of users and of computers.

Prerequisites

Guide Requirements

Note:  This document does not describe all the possible Group Policy scenarios. This instruction set should be used to help you begin to understand how Group Policy works and begin to think about how your organization might use Group Policy to reduce its IT administration costs. Other Windows Server 2003 features, including Security Settings and Software Installation and Maintenance, are built on Group Policy. For a comprehensive list of available documents, see the Group Policy in Windows Server 2003 Web site.

Top of page

Group Policy and the Microsoft Management Console

Group Policy is directly integrated with Active Directory management tools through the MMC snap-in extension mechanism. The Active Directory snap-ins set the scope of management for Group Policy. The most common way to access Group Policy is by using the Active Directory User and Computers snap-in, for setting the scope of management to domain and OUs. You can also use the Active Directory Sites and Services snap-in to set the scope of management to a site. These two tools can be accessed from the Administrative Tools program group; the Group Policy snap-in extension is enabled in both tools. Alternatively, you can create a custom MMC console, as described in the next section.

Configuring a Custom Console

The examples in this document use the custom MMC console that you can create by following the procedures outlined in this section. You need to create this custom console before attempting the remaining procedures in this document.

To configure a custom console

To save console changes

1.	In the MMC console, click File, and then click Save.
2.	In the Save As dialog box, in the File name text box, type GPWalkThrough, and then click Save. The console should appear as shown in Figure 1. Figure 1.  Group Policy MMC Console

Accessing Group Policy

You can use the appropriate Active Directory tools to access Group Policy while focused on any site, domain, or OU.

To open Group Policy from Active Directory Sites and Services

To open Group Policy from Active Directory Users and Computers

To access Group Policy scoped to a specific computer (or the local computer), you must load the Group Policy snap-in into the MMC console namespace targeted at the specific computer (or local computer). There are two major reasons for these differences:

Creating a Group Policy Object

Group Policy settings are contained in GPOs that are individually linked to selected Active Directory objects, such as sites, domains, or OUs.

To create and link a new GPO to the Headquarters OU

1.	In the GPWalkThrough MMC, expand contoso.com under Active Directory Users and Computers.
2.	Click the plus sign (+) next to Accounts to expand the tree.
3.	Right-click Headquarters, and then click Properties.
4.	On the Headquarters Properties page, click the Group Policy tab.
5.	Click New, type HQ Policy, and then press Enter. The Headquarters Properties page appears as shown in Figure 2. Figure 2.  New GPO Linked to Headquarters OU

The previous steps showed how to create and automatically link a GPO to an Active Directory container—the Headquarters OU. However, the GPO will have no direct impact on users or computers until its various settings are defined. The next section shows how to edit the HQ Policy GPO settings.

Multiple GPOs may be created and/or linked under any Active Directory container. If more than one GPO is associated with an Active Directory container, you must ensure that the GPOs are ordered correctly. GPOs higher in the list that have the highest precedence are processed last. (This is what gives them a higher precedence.)

GPOs are objects; they have context menus for viewing the properties of each GPO. You can use the context menus to obtain and modify general information about a GPO. This information includes Discretionary Access Control Lists (DACLs), and lists the other site, domain, or OUs to which this GPO is linked.

Best Practice:  You can further refine a GPO through user or computer membership in security groups by setting DACLs based on that membership. For information about using DACLs, see the section Security Group Filtering.

Managing Group Policy

To manage Group Policy

Editing a Group Policy Object

You can use the GPWalkThrough custom console created previously to edit a GPO.

To edit the HQ Policy GPO

1.	In the GPWalkThrough MMC console, double-click the HQ Policy GPO (or highlight it, and then click Edit). This opens the Group Policy Object Editor for editing the HQ Policy. It should appear as shown in Figure 3. Figure 3.  HQ Policy See full-sized image
2.	Close the Group Policy Object Editor for the HQ Policy.

Adding or Browsing a Group Policy Object

To add a GPO

1.

In the Headquarters Properties page, on the Group Policy tab, click Add. The Add a Group Policy Object Link dialog box lists GPOs currently associated with Domains/OUs, sites, or all GPOs that exist within the Active Directory structure. Figure 4 illustrates this dialog box. Figure 4.  Add a Group Policy Object Link

Review the following components of the Add a Group Policy Object Link dialog box and then close the dialog box.

Note:  It is possible to have two or more GPOs with the same name. This is by design and is possible because GPOs are actually stored as globally unique identifiers (GUIDs). The display name shown is actually a friendly name stored in Active Directory.

Registry-Based Policies

The user interface for registry-based policies is available through Administrative Template (.adm) files. These files describe the user interface that is displayed in the Administrative Templates node of the Group Policy snap-in. These files are format-compatible with the .adm files used by the System Policy Editor tool (Poledit.exe) in Microsoft Windows NT^® 4.0. With Windows Server 2003, the options available in registry-based policies have been expanded.

Note:  Although it is possible to add any .adm file to a GPO, if you use an .adm file from a previous version of Windows, the registry keys are unlikely to have an effect on Windows Server 2003.

By default, only those policy settings defined in the loaded .adm files that exist in the approved Group Policy trees are displayed; these settings are referred to as true policies. This means that the Group Policy snap-in does not display any items described in the .adm file that set registry keys outside of the Group Policy trees; such items are referred to as Group Policy preferences. Preferences are indicated by a red icon to distinguish them from true policies, which are indicated by a blue icon. The approved Group Policy trees are:

Note:  Using non-policies within the Group Policy infrastructure is strongly discouraged because of the persistent registry settings behavior mentioned previously. To set registry policies on Windows NT 4.0, and Windows 95 and Windows 98 clients, use the Windows NT 4.0 System Policy Editor tool, Poledit.exe.

By default, the conf.adm, inetres.adm, system.adm, wmplayer.adm, and wuau.adm files are loaded and available for configuration as shown in Figure 5.

Figure 5.  User Configuration

The default .adm files offer the following configuration options.

Adding Administrative Templates

Administrative Templates (.adm files) contain a hierarchy of categories and subcategories that together define how options are organized in the Group Policy user interface.

To add an administrative template (.adm files)

Configuring Administrative Templates

The following steps provide a simple example of using Administrative Templates to remove the Run command from a user’s desktop. You should become familiar with all the available settings offered in the Administrative Templates. Additional step-by-step guides in this series will use settings available in the Administrative Templates.

To set registry-based settings using administrative templates

1.	In the Group Policy Object Editor for the HQ Policy GPO, click the plus sign (+) next to the Administrative Templates in the User Configuration node.
2.	Click Start Menu & Taskbar. Note that the details pane shows all policies as Not configured.
3.	In the right pane, double-click the Remove Run menu from Start menu policy.
4.	In the Remove Run menu from Start menu dialog box, click Enabled (as shown in Figure 6). Click OK to finish. Figure 6.  Remove Run menu from Start Menu

Note the Previous Policy and Next Policy buttons in the dialog box. You can use these buttons to navigate the details pane for setting the state of other policies. You can also leave the dialog box open and click another policy in the details pane of the Group Policy snap-in. After the details pane has the focus, you can use the Up and Down arrow keys on the keyboard and press Enter to quickly browse through the settings (or Explain tabs) for each policy in the selected node.

Note the change in state to Enabled in the Setting column of the details pane. This change is immediate; it has been saved to the GPO. If you are in a replicated domain controller environment, this action sets a flag that triggers a replication cycle.

If you log on to a workstation in the contoso.com domain with a user from the Headquarters OU, you will note that the Run menu has been removed.

Note:  At this point, you may want to experiment with the other available policies. Look at the text in the Explain tab for information about each policy.

Deploying Scripts Through Group Policy Objects

You can define a GPO setting that runs scripts when users log on or log off, or when the system starts or shuts down. All scripts are Windows Scripting Host (WSH)–enabled. As such, they may include Java Scripts or Microsoft Visual Basic^® Scripts, as well as .bat and .cmd files.

Creating a Logon Script

Note:  This procedure uses the welcome.js script described in the Appendix. Create an Included Items folder, and then create the file welcome.js within the Included Items folder by copying the script from the Appendix in this guide.

To define a logon script Group Policy setting

1.	Close the Group Policy Object Editor for the HQ Policy.
2.	In the Headquarters Properties dialog box, click Close.
3.	In the GPWalkthrough console, right-click the contoso.com domain, click Properties, and then click the Group Policy tab.
4.	On the Group Policy properties page, select the Default Domain Policy GPO from the Group Policy objects links list, and then click Edit to open the Group Policy Object Editor snap-in.
5.	In the Group Policy snap-in, under User Configuration, click the plus sign (+) next to Windows Settings, and then click the Scripts (Logon/Logoff) node.
6.	In the details pane, double-click Logon. The Logon Properties dialog box displays the list of scripts that run when a designated user logs on. This is an ordered list, with the script that is to run first appearing at the top of the list. You can change the order by selecting a script, and then using the Up or Down arrow keys. To add a new script to the list, click the Add button. This displays the Add a Script dialog box. Browsing from this dialog box allows you to specify the name of an existing script located in the current GPO, or to browse to another location and select it for use in this GPO. The script file must be accessible to the user at logon, or it does not run. Scripts in the current GPO are automatically available to the user. To create a new script, right-click the empty space, select New, and then select a new file. To edit the name or the parameters of an existing script in the list, select it, and then click the Edit button. This button does not allow the script itself to be edited. To edit the script, use the Show Files button. To remove a script from the list, select it, and then click Remove. The Show Files button displays a Windows Explorer view of the scripts for the GPO. This allows quick access to these files or to the place to copy support files to if the script files require them. If you change a script file name from this location, you must also use the Edit button to change the file name, or the script cannot execute. Note:  If the View Folder Options for this folder are set to Hide file extensions for known file types, the file may have an unwanted extension that prevents it from being run.
7.	Click the Start button, click All Programs, click Accessories, and then click Windows Explorer. Navigate to the welcome2000.js file in the Included Items directory, right-click the file, and then click Copy.
8.	Close Windows Explorer.
9.	In the Logon Properties dialog box, click the Show Files button, and paste the welcome.js script into the default file location. It should appear as shown in Figure 7. Figure 7.  Welcome.js Script Included in the Default Domain Policy See full-sized image
10.	Close the window containing welcome.js.
11.	In the Logon Properties dialog box, click Add.
12.	In the Add a Script dialog box, click Browse. In the Browse dialog box, double-click the welcome.js file.
13.	In the Add a Script dialog box, click OK (no script parameters are needed), and then click OK again.
14.	Close the Group Policy Object Editor.
15.	On the contoso.com Properties page, click Cancel.

This script will be immediately available to any member of contoso.com since it was defined within the Default Domain Policy. You can log on to a client workstation to verify that the script is run when a user logs on.

Defining a Logoff or Computer Startup or Shutdown Script

You can use the same procedure outlined in the section Creating a Logon Script to set up scripts that run when a user logs off or when a computer starts or shuts down. For logoff scripts, you would select Logoff in step 6 in Creating a Logon Script. For computer Startup or Shutdown scripts, switch to Computer Configuration – Windows Settings – Scripts (Startup/Shutdown) in the Group Policy Object Editor.

Other Script Considerations

By default, Group Policy scripts that run in a command window (such as .bat or .cmd files) run hidden, and legacy scripts (those defined in the user object) are, by default, visible as they are processed, although there is a Group Policy setting that allows this visibility to be changed. The policy for users is called Run logon scripts visible or Run logoff scripts visible, and is accessed in the User Configuration\Administrative Templates node, under System\Scripts. For computers, the policy is Run startup scripts visible and Run shutdown scripts visible, and can be accessed in the Computer Configuration\Administrative Templates node, under System\Scripts.

Security Group Filtering

You can refine the effects of any GPO on users or computers by stipulating how a selected GPO is applied to security groups. To do this, use the Security tab on the Properties page of a GPO to set DACLs. DACLs are used primarily for performance reasons, although the feature allows for tremendous flexibility in designing and deploying GPOs, and the policies they contain.

By default, GPOs affect all users and machines that are contained in the linked site, domain, or OU. By using DACLs, the effect of any GPO can be modified to exclude or include the members of any security group.

To filter GPO application based on Security Group membership

1.	In the GPWalkthrough console, under the Accounts OU, right-click the Headquarters OU, and then click Properties.
2.	In the Headquarters Properties dialog box, click the Group Policy tab.
3.	Right-click the HQ Policy GPO in the Group Policy Object Links list, and then select Properties from the context menu.
4.	On the Properties page, click the Security tab.
5.	On the Security property page, click Add.
6.	In the Select Users, Computers, and Groups dialog box, type Management in the Enter the object names to select, and then click OK.
7.	In the Security tab on the HQ Policy Properties page, select the Management group, and view the permissions. Note:  By default, only the Read Access Control Entry (ACE) is set to Allow for the Management group. This means that the members of the Management group do not have this GPO applied to them unless they are also members of another group (by default, they are also Authenticated Users) that has the Apply Group Policy ACE selected. At this point, everyone in the Authenticated Users group has this GPO applied including members of the Management Security Group as shown in Figure 8. Figure 8.  Authenticated Users

To configure the GPO to apply only to members of the Management group

To deny GPO application to members of the Management group

Note:  Use the Deny ACE with caution. A Deny ACE setting for any group has precedence over any Allow ACE given to a user or computer because of membership in another group. For more information about this interaction, see the Windows 2000 Server online Help and search for Security Group.

1.	Clear the Allow check box and select the Deny check box for the Apply Group Policy ACE for the Management group.
2.	Select the Allow check box for the Allow Group Policy ACE for the Authenticated Users group. Figure 9 shows an example of the security settings that allow everyone to be affected by this GPO, except the members of the Management group, who are explicitly denied permission to the GPO. If a member of the Management group were also a member of a group that had an explicit Allow setting for the Apply Group Policy ACE, the Deny setting would take precedence and the GPO would not affect the user. Figure 9.  Deny GPO Assignment Based on Group Membership
3.	Click OK and then click Yes to acknowledge the warning about using Deny ACLs.
4.	Click OK to close the Headquarters Property page.

Variations on this procedure may include:

Note:  You can use these same types of security options with the Logon scripts you set up in the preceding section. You can set a script to run only for members of a particular group or for everyone except the members of a specific group.

Security group filtering has two functions: the first is to modify which group is affected by a particular GPO, and the second is to delegate which group of administrators can modify the contents of the GPO by restricting Full Control to a limited set of administrators (by a group). This is recommended because it limits the chance of multiple administrators making changes at any one time.

Policy Inheritance

In general, Group Policy is passed down from parent to child containers within a domain. Group Policy is not inherited from parent to child domains. If you assign a specific Group Policy setting to a high-level parent container, that Group Policy setting applies to all containers beneath the parent container, including the user and computer objects in each container. However, if you explicitly specify a Group Policy setting for a child container, the child container's Group Policy setting overrides the parent container's setting.

If a parent OU has policy settings that are not configured, the child OU does not inherit them. Policy settings that are disabled are inherited as disabled. In addition, if a policy setting is configured (enabled or disabled) for a parent OU and the same policy setting is not configured for a child OU, the child inherits the parent's enabled or disabled policy setting.

If a policy setting that is applied to a parent OU and a policy setting that is applied to a child OU are compatible, the child OU inherits the parent policy setting, and the child's setting is also applied.

If a policy setting that is configured for a parent OU is incompatible with the same policy setting that is configured for a child OU (because the setting is enabled in one case and disabled in the other), the child does not inherit the policy setting from the parent. The policy setting in the child is applied.

Blocking Inheritance and No Override

The Block Policy inheritance option blocks GPOs that apply higher in the Active Directory hierarchy of sites, domains, and OUs. It does not block GPOs if they have No Override enabled. The Block Policy inheritance option is set only on sites, domains, and OUs, not on individual GPOs. These settings provide complete control over the default inheritance rules.

In the following section, you set up a GPO in the Accounts OU, which applies by default to the users (and computers) in all child objects within the Accounts OU. You then establish another GPO in the Accounts OU and set it as No override. These settings will apply to all child objects even if settings conflict with other settings applied through a GPO. You will then use the Block inheritance feature to prevent group policies set in a parent site, domain, or OU (in this case, the Accounts OU) from being applied to the Production OU.

To create new GPOs

1.	In the GPWalkthrough MMC and under contoso.com, right-click the Accounts OU.
2.	Click Properties, and then click the Group Policy tab.
3.	Click New, enter Default User Policies for the GPO name, and then press Enter.
4.	Click New again, enter Enforced User Policies for the GPO name, and then press Enter.
5.	Click the Enforced Users Policies GPO, and then click the Up button to move it to the top of the list. Note:  The Enforced Users Policies GPO should have the highest precedence. Note that this step only serves to demonstrate the functionality of the Up button; an enforced GPO always takes precedence over those that are not enforced.
6.	Select the No override setting for the Enforced User Policies GPO by double-clicking the No override column or using the Options button. The Accounts Properties page should now appear as in Figure 10. Figure 10. Enforced User Policies with No Override

To enable settings in the Enforced User Policies and Default User Policies GPOs

1.	On the Accounts Properties page, double-click the Enforced User Policies GPO.
2.	In the Group Policy Object Editor, under User Configuration, expand Administrative Templates.
3.	Expand System, and then click Ctrl+Alt+Del Options.
4.	In the details pane, double-click the Remove Task Manager policy, click Enabled in the Remove Task Manager dialog box, and then click OK. For more information about the policy, click the Explain tab. The setting is now Enabled as shown in Figure 11. Figure 11.  Disabling the Use of Task Manager
5.	Click File, and then click Exit to close the Group Policy Object Editor.
6.	In the Accounts Properties dialog box, on the Group Policy tab, double-click the Default User Policies GPO in the Group Policy objects links list.
7.	In the Group Policy Object Editor, under User Configuration, expand Administrative Templates, expand Desktop, and then click Active Desktop.
8.	In the details pane, double-click the Disable Active Desktop policy.
9.	Click Enabled, click OK, and then click OK.
10.	Click File, and then click Exit to close the Group Policy Object Editor.

Logging on to a client workstation as any user under the Accounts OU, including child OUs, will apply both the Default User and Enforced User GPOs. Both Task Manager and the Active Desktop will be disabled.

Increasing the Performance of GPOs

Because these GPOs are used solely for user configuration, the computer portion of the GPO can be disabled. Disabling the computer configuration settings reduces the target computer’s startup time as the computer GPOs do not need to be evaluated.

If no computers exist within the Accounts, or any child OUs, disabling the computer portion of the GPO has no immediate benefit. However, since these GPOs could later be linked to a different container that may include computers, you may want to disable the computer side of these GPOs.

To disable the computer portion of a GPO

Blocking Inheritance

You can block inheritance so that one GPO does not inherit policy from another GPO in the hierarchy. The following example shows how to block inheritance so that only the settings in the Enforced User Policies affect the users in this OU.

To block inheritance of Group Policy for the Production OU

To verify that inherited settings are now blocked, you can log on as any user in the Production OU. Note that the Active Desktop is available, however, the Task Manager remains disabled since its disabling GPO was set to No Override in the parent OU.

Linking a GPO to Multiple Sites, Domains, and OUs

This section demonstrates how you can link a GPO to more than one container (site, domain, or OU) in Active Directory. Depending on the exact OU configuration, you can use other methods to achieve similar Group Policy effects; for example, you can use security group filtering or you can block inheritance. In some cases, however, those methods do not have the desired affects. Whenever you need to explicitly state which sites, domains, or OUs need the same set of policies, use the following method.

To link a GPO to multiple sites, domains, and OUs

You have now linked a single GPO to two OUs. Changes made to the GPO in either location result in a change for both OUs.

Loopback Processing

Loopback provides alternatives to the default method of obtaining the ordered list of GPOs whose User Configuration settings affect a user. By default, a user's settings come from a GPO list that depends on the user's location in Active Directory. The ordered list goes from site-linked to domain-linked to OU–linked GPOs, with inheritance determined by the location of the user in Active Directory and in an order that is specified by the administrator at each level.

Loopback can be set to Not Configured, Enabled, or Disabled, as can any other Group Policy setting. In the Enabled state, loopback can be set to Merge or Replace.

To enable Loopback processing

The next section defines restrictive settings for the user’s Start Menu & Taskbar and Desktop environments as might be applied in a Kiosk scenario. To navigate policies efficiently, use the Next Policy navigation buttons in the policy dialog boxes.

To define a restrictive Start Menu & Taskbar environment

To define a restrictive Desktop environment

All users who log on to computers in the Desktop OU have no policies that would normally be applied to them; instead, they have the user policies defined in the Loopback Policies GPO. You may employ the procedures outlined in the Security Group Filtering section to restrict this behavior to specific groups of computers by creating a security group, and then denying GPO application to that security group.

Top of page

Appendix

Welcome.js Sample Script

// Script Sample for Windows Scripting Host
//
// Define constant values.
//
var MB_ICONINFORMATION  = 0x40;
var MB_ICONQUESTION     = 0x20;
var MB_ICONYESNO        = 0x04
var IDYES               = 6;
var IDTIMEOUT           = -1;

var POPUP_WAIT          = 5;   // close popup after 5 seconds.

//
// Create ActiveX Controls
//
var Shell = WScript.CreateObject("WScript.Shell")
var Env = Shell.Environment("PROCESS")

//
// Set greeting message.
//
var strTitle = "Sample Login Script";

var strMsg = "Welcome \"" + Env("UserName")
strMsg += "\" to the \"" + Env("UserDomain") + "\" domain\r\n\r\n"


Shell.Popup(strMsg, POPUP_WAIT, strTitle, MB_ICONINFORMATION);

//
// Launch Internet Explorer if user wants.
//
strMsg = "Do you want to visit the Windows Server 2003 web site?";
var strURL;

strURL = "http://www.microsoft.com/windowsserversystem/default.mspx";

var intAnswer = Shell.Popup(strMsg,
                POPUP_WAIT,
                strTitle,
                MB_ICONQUESTION | MB_ICONYESNO );

if (intAnswer == IDYES) {
Shell.Run(strURL);

}

Top of page

Additional Resources

For more information, see the following resources.

Top of page