Abstract
This chapter focuses on practical techniques for scripting and delivering Registry changes to large numbers of machines. If you support a small Windows 2000 environment, the techniques are still useful for managing Registry changes across multiple machines. I first consider ways you can get your Registry scripts to many machines at once. Then I discuss some options for logging what the scripts actually do. I then cover key security context and timing issues. I introduce the Windows Scripting Host (WSH), the preferred Win2K scripting environment, and provide examples of how you can use WSH to manipulate the Registry. This chapter is the last of a six-part series.
Distributing Mass Registry Changes in Win2K Networks
There are many circumstances in which you may need to deliver Registry changes to large numbers of Win2K workstations or servers. In Windows NT 4.0, there were a few good ways to do this, including the use of system policies, as well as various scripting techniques using Resource Kit tools that I discussed. In Win2K, there are some new and improved ways of delivering mass Registry changes — and better mechanisms for ensuring that needed Registry changes get delivered. Some of these methods include
- Group Policies for delivery of "Administrative Templates" and Registry Security
- Task Scheduler for scheduled execution of Registry scripts
- Resource Kit tools, such as Reg and Regini, in conjunction with tools running on the target systems, such as Rcmd and Rconsole
- The Microsoft Installer Service for delivery of application installations
- Microsoft’s Systems Management Server (SMS) or a third-party system management package for performing software distribution and configuration management
Several of the above mechanisms are simply ways to distribute changes to target systems. Whatever the distribution mechanism is, delivering Registry changes to large numbers of systems involves three main challenges: the security context under which the script runs, the timing of the script, and logging the script’s changes. In this section, I describe each of these challenges and how to address them.
The first and perhaps most important challenge in making Registry changes is security. Specifically, if you deliver changes to a part of the Registry to which a normal user account does not have sufficient privilege, you must think about the security context under which a specific change occurs. In many cases, that thinking drives the tool you choose to deliver your change.
For example, many keys in HKEY_LOCAL_MACHINE have permissions that restrict a normal, nonadministrative user from modifying them — for good reason. Specifically, if users can modify keys within HKLM, they can potentially install their own applications and services. Their doing so could have a negative impact on the proper functioning of the system — to the point of breaking it! You then have to fix the system, bringing it back to a supported state — which is costly in terms of both time and money. The biggest goal of the Zero Administration Windows (ZAW) initiative is to reduce this kind of "futzing." Security is one of the ways you can avoid changes that affect the system negatively. The answer is not to reduce normal security to ease Registry change distribution, but to make those changes using the right tools at the right time.
The second challenge in making Registry changes is the problem of timing. For example, if you need to make changes to a user’s profile (HKEY_CURRENT_USER), either the user must be logged on or the user’s profile (actually, the hive file in the profile) has to at least be loaded into a temporary Registry key. This puts restrictions on how and when you deliver an HKCU change. And if you have an application that needs to make changes to both HKLM and HKCU, you must deal with two different security contexts at the same time, not to mention ensuring that the target user is currently logged on. As I discuss in an upcoming section, timing user and machine changes became easier in Win2K with the advent of the Windows Installer Service, first discussed in "The Registry and the Active Directory," the second installment in this series.
The third challenge in making Registry changes involves reporting or logging. Most large infrastructures need an intelligent, centralized way to report on the results of changes made to a system, whether they are Registry or file system changes. If your environment has that need, that too drives which tool you use for Registry change distribution. Unfortunately, Win2K has few good ways to report on Registry changes, or on configuration changes in general. Tools such as Regedit are pretty inadequate for reporting on the success of Registry changes.
The Windows Installer uses the Event Log and text log files at each target machine to report on an installation. However, the detail is limited, you have to collect it from each machine, and you are unlikely to get the kind of information you need to tell whether a particular value in a particular key failed to register. As a result, I discuss alternative logging mechanisms that you can include in your Registry scripts.
Now that you know some of the pitfalls, I present the best ways to address them, including some new Win2K tools you can use to make life easier.
Security Context Issues
First, let’s look at the security context issues. Win2K includes a useful tool called the Secondary Logon service.
RegMon
If you are a Unix user, you are undoubtedly familiar with the su command. This command lets you start a process using the security context of a user other than the currently logged-on user. In Win2K, there is now a RunAs.exe command. RunAs lets you start a process, such as a Registry script, using a security context other than your own or that of a currently logged on user. RunAs requires that the "Secondary Logon Service" is installed and running on the device where you issue the command. This service is installed by default on Win2K Professional and the various other flavors of the Win2K server product. When you issue the RunAs command, the service starts automatically. Within the context of Registry changes, the power of RunAs is its ability to load the user’s profile when you issue the command. For instance, here is an example that uses RunAs to deliver a .reg file to user Jsmith’s HKCU subtree:
Runas /profile /user:jsmith@mycompany.com "regedit /s d:\temp\myapp.reg"
This command logs on as jsmith@mycompany.com, loading that user’s profile (if the profile is roaming, it downloads the profile from the server where it is stored) into the process space of RunAs and then executes the command regedit /s d:\temp\myapp.reg. Myapp.reg contains a registration to HKCU\Software\Myapp. Because the user is "logged on," with his or her user profile loaded at the time the reg script runs, the changes are made within that user profile. For this command to work in this case, you need the user’s password, for which you are prompted when you execute the command. I have yet to find a way to programmatically pass the password to RunAs.
You can also use RunAs in the opposite way. That is, suppose that for security reasons your normal user ID is nonadministrative. However, from time to time, you need to make Registry changes that require administrative access. Instead of having to log out of a system and log back in as an administrator, you can use RunAs to execute a Registry script as the administrator without ever logging out. For example, I want to add a registration to HKLM\Software. However my normal user account doesn’t have security access to it. The following command shows how I could do this:
Runas /user:mymachine\administrator "reg add HKLM\Software\Myapp\NewVal=10"
In this command, I log on using the local machine administrator account (mymachine\administrator), then execute a Reg command against HKLM. When this line executes, I am prompted for the administrator’s password. Once I provide it, the change is made.
You can use the /env option with the /user option and execute the command specified using the environment variables available to the user who initiates the RunAs command, rather than the user account specified. For example, let’s say I am user jsmith with my own set of user-specific environmental variables and I want to issue a RunAs command under the administrator’s security context. I can use the /env option to have that command use the environment variables that are available to me as jsmith, rather than administrator. Note that within the process space of the RunAs command, in this example, only jsmith’s profile and environment variables are available — the administrator’s security context and environment is not available.
Logon/Logoff and Shutdown/Startup Scripts
There are other ways to get around the security context issues when you deliver Registry scripts. For example, you can use logon and logoff scripts in Win2K to deliver user-specific changes to HKCU and, for HKLM, you can use startup and shutdown scripts to accomplish the same thing. Logoff, startup, and shutdown scripts are new to Win2K. Both logon/logoff and startup/shutdown scripts are part of Group Policies. As I described in "The Registry and the Active Directory," Group Policies are applied at the local machine, site, domain, and OU levels. This means you could have any number of logon/logoff and shutdown/restart scripts executing against a workstation or user.
|
Tip: Given that you could have any number of logon/logoff and shutdown/restart scripts executing against a workstation or user, the best advice I can give you to manage this is to keep it simple. Decide on as few places as possible to define scripts. If your Win2K machines are members of a domain and your users authenticate to that domain as a normal course of doing their work, avoid using locally defined GPOs. This holds true whether you are delivering Registry changes or mapping network drives. |
|
Note: By default, local machine GPOs are stored in %systemroot%\system32\GroupPolicy and have the same directory structure as Active Directory (AD)-based ones. However, local GPOs don’t support all of the nodes of functionality that AD ones do. |
One important point to keep in mind about scripts: Logon/logoff scripts run in the logged-on user’s security context, and shutdown/startup scripts run in the system’s security context. If you use scripts, you have to keep these restrictions in mind. Namely, certain Registry subtrees are not available or don’t provide sufficient security context to succeed. Table 1 gives an overview of those restrictions.
Schedule Service
The familiar AT command scheduler is another way to deliver changes in a security context other than the current user’s. Every Win2K system includes the Schedule service. In NT 4.0, when you loaded Internet Explorer 4.0 and later you were introduced to the Task Scheduler, a GUI-based interface into the Schedule service. Win2K continues support for this tool, which you can access via the Control Panel. You can also still use the command-line AT command to manage the Schedule service. In fact, for scripting, I prefer this method. By default, the Schedule service runs under the security context of the LocalSystem account (you can change the service account on this service to use another user context for startup). This means that any scripts that are executed by this service operate under that context. So, HKLM changes that require administrative (or LocalSystem) access can be run using AT. The following command is an example of using AT to deliver changes to HKLM:
AT \\ws10.test.com 19:00 "Reg Update
HKLM\System\CurrentControlSet\Services\SchedulingAgent\Start=1"
This command says that, on a workstation called ws10.test.com, at 7:00 p.m., execute the .reg update statement within the security context of the Task Scheduler service.
|
Note: Any service that runs using the service account of LocalSystem has its own "user profile" complete with its own HKCU — which is actually HKU\.Default. As a result, if you try to use AT (or any other service running in LocalSystem) to make a change to, for example, the currently logged on user’s HKCU subtree, you won’t get the results you expect. Namely, any changes to HKCU are made to LocalSystem’s user profile, rather than to the currently logged-on user on the target system. |
Timing Issues
Once we deal with the issue of security context, we need to think about the timing of script delivery. Do users need to be logged on for the change to occur? Or, conversely, must they be logged off?
Logon/Logoff and Startup/Shutdown Scripts
Script timing issues are similar to script security issues. Primarily, does your script make changes to a Registry key that is available at execution time? In general, the rule is that if you need script modifications to HKCU, use logon and logoff scripts. If you wish to make changes to HKLM or HKU, use startup or shutdown scripts. You can use logon and logoff scripts to make changes to HKLM or HKU, but the permissions on the affected keys must be open enough to provide access to the logged on user.
Keep in mind that in Win2K logon scripts get processed asynchronously by default. The Explorer shell is loading while your logon script is running. This can be an issue when you make changes to HKCU because certain applications and shell functionality may only check keys and values here once, during the initial logon process. If you make changes to HKCU using logon scripts, the changes may not take effect until the user re-logs onto the workstation.
|
Tip: You can use an Administrative Template policy to direct a Win2K workstation to process logon scripts synchronously, before the shell loads rather than asynchronously while your logon script is running. This is found in the Computer Configuration\Administrative Templates\System\Logon section of a GPO. |
Group Policy Administrative Templates
Group Policy-based Administrative Templates provide the same type of functionality as NT 4.0 System Policies. That is, they let you centrally deliver changes to HKLM and HKCU to control desktop and application settings for groups of users and machines. In Win2K, Administrative Templates are applied to machines at system startup time and to users at logon time. User policies can be applied synchronously before the user is allowed to log on to ensure that features such as Software Installation have completed before the user attempts to launch an application.
|
Windows IT Pro
Register
