Chapter 10: The Shared Computer Toolkit in Domain Environments

Article
09/11/2009

This chapter of the Handbook focuses on using the Shared Computer Toolkit on computers in a domain environment, and handling other enterprise-level requirements.

The Shared Computer Toolkit and Active Directory

The Active Directory® directory service offers significant benefits for shared computers on a network. Active Directory gives network users controlled access to resources anywhere on the network using a single set of credentials. It also provides network administrators with an intuitive, hierarchical view of the network, and a single point of administration for all network objects.

Active Directory provides a better environment for centrally managing user accounts that require access to network resources or need to log on with the same credentials on multiple computers, as many educational institutions require. For these reasons, the Shared Computer Toolkit has been designed to work as favorably in domain environments as it does for workgroup computers.

Note Note
The Toolkit provides a Group Policy template (SCTSettings.adm) that includes most of the settings found in the User Restrictions tool. You can use this template to configure users in a Group Policy object.

Windows Disk Protection works well out-of-the-box on domain-joined computers, greatly easing the administrative burden of securing and maintaining Internet kiosks, employee self service systems, and public access computers in a domain.

Most of the settings and restrictions available in the User Restrictions tool are available through the Group Policy template (SCTSettings.adm) provided with the Toolkit. Group Policy is more effective than the User Restrictions tool for restricting multiple user accounts across numerous computers at one time.

Windows Disk Protection on Domain-Joined Computers

When a computer running Windows XP Professional is joined to an Active Directory domain, the computer uses a machine account password to authenticate with the domain and gain access to domain resources. By default, the domain-joined computer initiates a change to the machine account password automatically within every 30-day period. A domain controller accepts the password change and allows the domain-joined computer to continue to authenticate. The new password is stored locally on the domain-joined computer and can be confirmed by Active Directory. If a password change fails, or if a domain-joined computer attempts to use an incorrect password, the computer will not be able to access the domain.

Note Note
Windows Disk Protection disables the automatic client initiation of machine account password changes in the domain. To remedy this, Windows Disk Protection updates the password automatically every time disk changes are saved. At a minimum, this happens during the scheduled critical updates process.

Machine Account Passwords in a Domain Environment

When Windows Disk Protection is turned on, the tool disables the automatic client-initiated machine account password updates on the computer. Windows Disk Protection then automatically initiates a password change every time disk changes are saved. This happens one time when Windows Disk Protection is turned on. Thereafter, the update occurs at each restart where disk changes are saved. At a minimum, this happens during the scheduled critical update process.

The reason for this change in functionality is that if a shared computer with Windows Disk Protection turned on were to initiate a machine account password change, a new password would be created in Active Directory. Upon restarting the computer, Windows Disk Protection would revert to the previous password. This would result in an inability to access all domain resources.

If you turn on either of the Retain changes options in Windows Disk Protection, no changes to the Windows partition are saved. If a machine account password change is made while one of these options is turned on and changes are not saved within the maximum number of days allowed for a password change by the domain (30 days, by default), the machine account passwords will become out of sync. Therefore, you should not run with either Retain changes restart option for 30 days or longer.

Important
Domain-joined clients running Windows Disk Protection must not run for 30 days with either Retain changes restart option, otherwise they will become unjoined from the domain due to a stale machine account password.

One other issue to be aware of is the result of changing the Restart Option. If you configure Windows Disk Protection to Save changes with next restart, it changes the domain password immediately in anticipation of being restarted. If you then configure Windows Disk Protection to Clear changes with next restart, the computer discards the new password and can no longer log on to the domain.

Central Software Management and Windows Disk Protection

When Windows Disk Protection is on, software updates to the computer are ideally performed through the critical updates process offered by Windows Disk Protection. Windows Disk Protection keeps the computer trustworthy by first performing a regularly scheduled restart to clear all disk changes, and then downloading and installing the required updates on top of this trusted base. This model is a little less flexible than some central software management models in which updates can be initiated centrally and scheduled to occur at any time.

A centrally managed software distribution system, such as Microsoft Systems Management Server, can provide the flexibility to schedule software updates to occur at any time, but this flexibility cannot be easily matched by Windows Disk Protection.

If your organization has a strong need to regularly change the schedule for software updates, rather than following a fixed schedule you set within Windows Disk Protection, you might want to consider whether Windows Disk Protection is right for your environment.

In contrast, if you can integrate your centrally managed software update process into the client-driven Windows Disk Protection update process, you might find a happy medium in which central software distribution and Windows Disk Protection can co-exist.

Mobile Computers and Windows Disk Protection

It is important to note that the software management model used by Windows Disk Protection might not be appropriate for environments with portable computers such as notebooks and tablets that are routinely disconnected or turned off at the time when the Windows Disk Protection critical updates process is scheduled to occur.

Managing Windows Disk Protection Using DiskProtect.wsf

To automate the configuration of Windows Disk Protection on multiple computers, you can use the DiskProtect.wsf command-line tool included with the Shared Computer Toolkit. This tool can be used in batch files and scripts to configure Windows Disk Protection.

The syntax for this tool is:

DiskProtect.wsf [/Status] [/On] [/Off] [/Save] [/Clear] [/Retain] [/Once] [/Restart] [/MU] [/NoMU] [/AV] [/Other] [/Time] [/Day]

The following example would turn on Windows Disk Protection, enable Microsoft Updates, and install McAfee Antivirus updates—all at 2:00 A.M.:

DiskProtect.wsf /On /MU /AV:”C:\Program Files\Microsoft Shared Computer Toolkit\scripts\update\SCTMcAfeeVirusUpdate.vbs” /Time:2

DiskProtect.wsf can be called from batch files, logon scripts, and software installation scripts. One use would be to set Windows Disk Protection to Save changes with next restart to allow the scripted installation of a program. Upon restart, the program would be saved to the Windows partition.

Note Note
Running the DiskProtect.wsf tool with the /? option will give a description of each command-line option.

Create a Persistent Local User Profile for a Domain Account

For some domain accounts that log on to shared computers, you may find it necessary to create a persistent local user profile that is not affected by the default restart behavior of Windows Disk Protection when it clears all disk changes made to the Windows partition. This might be necessary, for example, to allow a teacher to save her documents and Windows settings on a computer protected by Windows Disk Protection.

Note Note
When you use ProfileMgr.wsf to create a profile on a persistent partition, it creates a Documents and Settings folder to contain the new profile (if one does not already exist).

To create persistent local user profiles for domain accounts, use the ProfileMgr.wsf command-line tool located in the Scripts subfolder of the Toolkit installation. To create a user profile, use the following command syntax:

ProfileMgr.wsf /create username password /domain:<domain name>
** /drive:<drive letter>**

For example, to create a profile on drive D for a user named User1 in the Contoso domain with the password UserPass5, you would use the following command:

ProfileMgr.wsf /create User1 UserPass5 /domain:Contoso /drive:D:

Create Persistent Local User Profiles for all Accounts

If you want to ensure that all of the local user profiles created for any accounts, including domain accounts, are placed on a persistent partition where they are not affected by Windows Disk Protection, you will need to customize the computer installation so that the default location for user profiles is not on the Windows partition.

It is possible to change the default location where user profiles are installed, but the only supported way to make this change is during Windows XP installation, and you must make the change by automating the installation of Windows with a special answer file. This method changes the location where all user profiles are stored, including the Default and All Users profiles. This allows you to have Windows automatically create profiles on a persistent partition instead of having to use the Profile Manager tool to specify the location of profiles as they are created.

Answer files are text files that contain responses to some, or all, of the questions that Setup asks during the installation process. After creating an answer file, called unattend.txt, you can apply it to as many computers as necessary.

The easiest way to create an answer file for an unattended installation of Windows XP is to use Windows Setup Manager, a deployment tool that provides a wizard-based interface for creating the answer file. For more information about using Setup Manager to automate installations, see the Automating and Customizing Installations chapter in the Windows XP Resource Kit. The answer file you create using Setup Manager can include other information, such as the time zone, network settings, and so on.

After you create an answer file, you can change the default location where user profiles are stored by adding the following entry:

[GuiUNattended]
ProfilesDir = drive:\foldername

Group Policy Restrictions for Domain Accounts

The Toolkit includes a Group Policy template called SCTSettings.adm in the bin folder of the install. This template reproduces most of the settings included in the User Restrictions tool and can be used to deploy these restrictions to users that are members of an Active Directory domain.

Group Policy for a domain can be configured either with the Group Policy Management Console, an add-on tool available for download from Microsoft, or by using the Group Policy Editor built into Active Directory Users and Computers. By adding the SCTSettings.adm template into these tools, you gain access to account restrictions and settings that are appropriate for shared accounts.

The SCTSettings.adm Group Policy template included with the Shared Computer Toolkit also includes the ability to set idle and mandatory logoff timers, if the Toolkit is installed on your computers.

It is important that you only apply these settings to specific user accounts, so as not to restrict legitimate administrative activities on any computers.

Note Note
Microsoft recommends that you create an OU that stores the shared user accounts in your environment, and that you apply the SCTSettings.adm template to the User Configuration portion of a Group Policy Object linked to this dedicated OU.

To use Active Directory Users and Computers to manage Toolkit restrictions

To start Active Directory Users and Computers on a Windows Server 2003 computer, browse to Administrative Tools, which is located on the Start menu or in Control Panel.
In the Active Directory Users and Computers console, right-click the organizational unit (OU) for which you want to configure policy, and then click Properties.
On the Group Policy tab, click the policy you want to modify, and then click Edit.
Expand User Configuration, right-click the Administrative Templates folder,and then click Add/Remove Templates.
In the Add/Remove Templates dialog box, click Add and then browse to the location of the SCTSettings.adm template (usually the Program Files\Microsoft Shared Computer Toolkit\bin folder.)
Browse the settings in the All Shared Computer Toolkit Restrictions folder and note their similarity to the settings in User Restrictions. Note also the explanations given for each setting.
Make any restrictions changes that you want and then exit the Group Policy Editor.

Important
The SCTSettings.adm template was designed to be applied only to the User Configuration of a Group Policy Object. Do not apply the SCTSettings.adm template to the Computer Configuration because this will restrict all users of computers affected by the policy.

Figure 10.1 Configuring Group Policy templates in the Group Policy Editor

Using Group Policy to Configure Software Restriction Policies

Software Restriction Policies provide control over which programs are allowed to run on a computer. The Shared Computer Toolkit provides some Software Restrictions in the User Restrictions tool. This tool works well for a few computers, but becomes unwieldy to manage when the number of computers or locations increases. Configuring Software Restriction Policies in Group Policy is the best way to centrally manage software restrictions across many computers or users.

Note Note
Software restrictions can be tailored to individual users or groups of users by creating more than one policy and controlling which policy is applied to each user through security settings.

Software restrictions that are identical to those applied by the User Restrictions tool can be configured in Active Directory using Software Restriction Policies, which are located in Group Policy under Security Settings.

Figure 10.2 Use path rules to restrict software based on its name or location

Note Note
Software restrictions may also be applied Computer Configuration—use caution and ensure that legitimate administrators are not restricted by setting Enforcement to All users except local administrators.

To configure Windows XP software restrictions using Group Policy

To start Active Directory Users and Computers on a Windows Server 2003 computer, browse to Administrative Tools, which is located on the Start menu or in Control Panel.
In the Active Directory Users and Computers console, right-click the Active Directory domain or an organizational unit for which you want to configure policy, and then click Properties.
On the Group Policy tab, click the policy that you want to modify, and then click Edit.
Expand User Configuration, Windows Settings, Security Settings, and then click Software Restriction Policies.
If Software Restriction Policies have been defined, there will be an Additional Rules folder under Software Restriction Policies that contains rules.
You can edit an existing definition or right-click the Additional Rules folder, and then click New Path Rule (as shown in the following figure).
In the New Path Rule dialog box, enter the path and then choose whether the rule will Disallow or Unrestrict software in the path. The path entry can use environment variables (such as %ProgramFiles%) and wildcard characters (* and ?) to define the path.
Click OK to save the new path rule.

Note
For more information about software restrictions, see the Using Software Restriction Policies to Protect Against Unauthorized Software article on TechNet.

To duplicate the software restrictions put in place by the Users Restrictions tool, create the path rules defined in the two following sections. Optionally, you can also restrict Notepad and WordPad and prevent Microsoft Office programs from running using Software Restriction Policies as described below.

Note Note
Prevent Windows Messenger and MSN Messenger from running is included in the SCTSettings.adm Group Policy template and does not use a path restriction.

Only allow software in the Program Files and Windows folders to run

To use Software Restriction Policies to duplicate the effect of the Only allow software in the Program Files and Windows folders to run check box in the User Restrictions tool, set the Software Restriction Policy Security Level to Disallowed, then create additional rules to unrestrict or allow each of the following paths:

%ProgramFiles% (this allows programs to run)
%Windir% (this allows Windows programs to run
*.lnk (this allows Start menu and desktop shortcuts to work)

As an added security measure, you should also create an additional path rule that disallows files from running from the Temp folder, because all users have access to write files to this location:

%WinDir%\Temp

Prevent System Tools and some management tools from running

Note Note
You might want to research the paths of additional programs that you want to restrict. You can restrict other programs in addition to those listed here.

To use Software Restriction Policies to duplicate the effect of the Prevent System Tools and some management tools from running check box in the User Restrictions tool, create an additional path rule to disallow each of the following:

NTBackup.exe, Cleanmgr.exe, Migwiz.exe, MSInfo32.exe, Rstrui.exe, CACLS.exe, MMC.EXE, Diskpart.exe, Net.exe, Reg.exe, Regini.exe, GPEdit.exe, XCopy.exe, Rename.exe, Ren.exe, Control.exe, DiskMgmt.msc, NusrMgr.cpl, ConfigWizards.exe, DDEShare.exe, RegSvcs.exe, RegSvr32.exe, ShrPubw.exe, SPUninst.exe, FSquirt.exe, and DxDiag.exe

If the Shared Computer Toolkit is installed on your computers, create additional path rules to disallow each of the following:

ETPrep.exe, EWFMgr.exe, SrvAny.exe, NetDom.exe, UPHClean.exe, XPePM.exe, SchTasks.exe, CreateProfile.exe, DenyAccess.exe, WindowsUpdates.vbs, Banner.wsf, DiskProtect.hta, GetStarted.hta, CheckWDP.hta, ProfileMgr.hta, and Restrict.hta

Restrict Notepad and Wordpad (recommended for Restricted Administrators)

To use Software Restriction Policies to duplicate the effect of the Restrict Notepad and Wordpad optional restriction check box in the User Restrictions tool, create an additional path rule to disallow the following:

Notepad.exe
Wordpad.exe

Prevent Microsoft Office programs from running

To use Software Restriction Policies to duplicate the effect of the Prevent Microsoft Office programs from running optional restriction check box in the User Restrictions tool, create an additional path rule to disallow the following:

%ProgramFiles%/Microsoft Office

Restart at Logoff Using a Logoff Script

When a Windows XP-based computer is joined to a domain, it can become more difficult to ensure changes are cleared between user logons. Because the User Restrictions tool will not be used in a domain scenario, it becomes necessary to reproduce the Restart at Logoff function usually provided by this tool.

Note Note
You can use the shutdown command in a batch file to restart the computer. At the command line, issue the command
shutdown -r -t 00 The shutdown command is restricted when you restrict access to the command prompt. You can also use the ForceLogoff.exe tool included with the Toolkit to restart the computer.

To use Group Policy to force the computer to restart when a user logs off

Open the Group Policy object for the domain or organizational unit to which your users belong.
Under User Configuration, expand Windows Settings, and then click Scripts (Logon/Logoff).
Open the Logoff object and add a logoff script. The logoff script can be a script written in any scripting language supported by Windows that contains a command to restart the computer.

Figure 10.3 Group Policy allows the configuration of Logon and Logoff scripts for users

User Restrictions for Unrestricted Domain Accounts

Some organizations need to restrict domain accounts on specific computers, but these domain accounts are unrestricted by Group Policy. This often happens with shared facilities that are used briefly by domain users, such as media burning labs or other types of dedicated computer kiosks.

Similarly, operators may need to restrict domain accounts on specific computers but do not have the access rights to make the required changes within Group Policy to do so.

Other security conscious environments would like to ensure that default restrictions are applied to domain users even if network issues prevent Group Policy restrictions from being applied at an initial logon (usually caused by tampering, such as the well-timed removal of a network cable).

All of these scenarios can be addressed by using the User Restrictions tool to apply restrictions to the Default User profile on a computer. The Default User profile is used as a template when creating all new user profiles for both domain and local accounts. This particular technique does not work on domain accounts that are configured with roaming user profiles.

Important
Before you customize the Default User profile, create a backup of it in case of problems. To do this, make a copy of the Default User folder located in the Documents and Settings folder.

To create a custom Default User profile

Log on as the Toolkit administrator.
Create a new limited local user account.
Log off and then log on as the local user account that you just created.
Customize the profile. For example, you could:
- Customize the Start menu.
- Customize the desktop and taskbar.
- Install and configure printers.
Log off and then log on as the Toolkit administrator.
Use the User Restrictions tool to configure and apply restrictions for the newly created profile.
Click Start, and then click My Computer.
Click the Tools menu, and then click Folder Options.
In the Folder Options dialog box, on the View tab, under Advanced settings, click Show hidden files and folders, and then click OK. Several of the files in the new profile are hidden by default, so hidden files must be shown to be copied to the new custom Default User profile.
Click Start, right-click My Computer, and then click Properties.
In the System Properties dialog box, on the Advanced tab, under User Profiles, click Settings.
In the User Profiles dialog box, click the user profile that you just created and customized, and then click Copy To.
In the Copy To dialog box, under Copy profile to, click Browse, click the C:\Documents and Settings\Default User folder, and then click OK.
Under Permitted to use, click Change, click Everyone, and then click OK. If Everyone is not available, click Advanced, click Find Now, click Everyone, and then click OK. Windows XP will now assign the custom Default User profile along with its restrictions to any new user who logs on to the computer.

Note
If you copy the Default User folder to the NETLOGON share on a domain controller, all domain users will receive the settings and restrictions of this profile the first time they log on.
The folder will be replicated to all other domain controllers providing a Default User profile for all new domain accounts.

This technique cannot be used to lock new user profiles as they are created. However, you can use this technique in conjunction with Windows Disk Protection to clear the new user profiles that are created on the Windows partition with each restart of the computer.

User Profiles in Other Languages

The Multilingual User Interface Pack (MUI) is a set of language-specific resource files that you can add to the English language version of Windows XP Professional. Using MUI, your users can change the interface language of the operating system to any of 33 supported languages. After you install the Toolkit, you can specify the user interface language for your users.

MUI Requirements

MUI will run on computers that run Windows XP Professional, but not on Windows XP Home Edition.

Windows XP MUI is sold only through Volume Licensing programs such as the Microsoft Open License Program (MOLP/Open), Select, and Enterprise agreement. You can request an OEM version of MUI, although MUI is not available through retail channels. This is to ensure that customers have the English version of the operating system running on their computers before they install MUI.

For more information about MUI and its requirements, see the Windows Server 2003, Windows XP & Windows 2000 MUI page.

How to Install MUI

MUI includes six CDs: one that contains the English version of Windows XP Professional, and the remaining five for the MUI Resource Files. After you use the first CD to install Windows XP Professional, you can run the program MUISetup.exe from any of the five resource CDs to install the User Interface Languages. You can install as many of the languages as necessary. You can also remove languages at any time.

How to Change the Input Language

After you install MUI, you can use the Regional and Language Options dialog box in Control Panel to define the standards and formats the computer uses, a user’s location, and the input languages used by the user profile.

The input language configured for the computer tells Windows how to react when text is entered using the keyboard. With multiple languages configured, a user can toggle between languages as needed. You can add an input language in a user profile as long as you have installed the appropriate language from MUI.

To add an input language for a user profile

Log on as the user for which you want to add an input language.
Click Start, and then click Control Panel.
In Control Panel, double-click Date, Time, Language, and Regional Options.
In the Date, Time, Language, and Regional Options window,click Regional and Language Options.
In the Regional and Language Options window, on the Languages tab, in the Text Services and Input Languages section, click Details.
In the Text Services and Input Languages dialog box, click Add.

Figure 10.4 Add an input language for a user account
In the Add Input Language dialog box, click the language you want to add. To choose a specific keyboard layout, select the Keyboard Layout/IME check box and choose the appropriate layout. To add a keyboard layout or input method editor (IME), you need to have installed it on your computer first. Click OK.
In the Text Services and Input Languages dialog box, the Default Input Language drop-down list, click the language that should be the default language, and then click OK.