Main Scripting Challenges | Unicode Explained

Delivering massive registry changes involves the following challenges:

Security context under which the script runs. Security is the most important among all scripting challenges. As you recall, starting with Windows 2000, the security model has undergone some changes, one of which is the introduction of the new built-in Power Users security group. The Users group has limited privileges. Thus, when running a script that delivers changes to a part of the system registry to which a normal user account doesn't have sufficient privileges, you must consider the security context under which that change can be successfully introduced. For example, many keys under HKEY_LOCAL_MACHINE have default permissions, which restrict non-administrative user accounts from modifying them. Only Administrators and Power Users can change these keys (and, consequently, perform such tasks as installing services and applications for all users of the system). One possible answer to this problem would be to reduce normal security to ease the registry change distribution, but this is highly undesirable. A much better approach would be to use the right tools at the right time.
The timing problem. To illustrate this problem, consider the following situation. Suppose that you need to make changes to a specific user profile (HKEY_CURRENT_USER). To achieve this goal successfully, either that user must be logged on or, at least the hive of that user's profile must be loaded into a temporary registry key. Now consider a more complicated situation — you need to modify both HKLM and HKCU, and do it simultaneously. Thus, your script will have to operate with two different security contexts at the same time, not to mention ensuring that the target user is currently logged on.
Logging of changes. Logging and, possibly, reporting of registry changes is a must, especially in large corporate networks, which need a centralized way to report the result of the changes. Unfortunately, tools such as Regeditexe are at least inadequate for reporting on the failure or success of the introduced registry changes, and this situation didn't change significantly, even with the arrival of Windows XP and Windows Server 2003.

Now, after discussing the main challenges and pitfalls of registry scripting, let us consider the ways that you can address them using newer mechanisms introduced with Windows 2000 and continuing in later editions.

The Windows Installer uses the Event Log and text log files at each target machine to report on an installation. However, the details are limited, you have to collect them 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 will discuss alternative logging mechanisms that you can include in your registry scripts.

Addressing the Problem of the Security Context

Starting with Windows 2000, Microsoft introduced several ways to resolve the problem of security context when distributing registry changes. The first of these tools is the Secondary Logon service (installed by default on Windows 2000 and in later editions), which we briefly considered in Chapter 10. Besides Run As GUI functionality, there is a runas.exe command-line tool (somewhat similar to the su command existing in UNIX). This command lets you start a process using the security context of a user other than the one currently logged on.

The runas command-line tool uses the following syntax:

 runas   [{/profile|/noprofile}] [/env] [/netonly] [/savedcreds] [/smartcard]   [/showtrustlevels] [/trustlevel] / user:UserAccountName   program

where:

/profile — loads the user's profile (the default option).

/no profile — specifies that the user's profile is not to be loaded. This allows the application to load more quickly, but it can also cause a malfunction in some applications.

/env — when used in combination with the /user option, instructs the Secondary Logon service to execute the specified command using the environment variables available to the user who initiates the Runas command.

/netonly — indicates that the user information specified is for remote access only.

/savedcreds — indicates if the credentials have been previously saved by this user. This option is not available (and, therefore, will be ignored) on Windows XP Home Edition.

/smartcard — indicates whether the credentials are to be supplied from a smartcard.

/showtrustlevels — lists the /trustlevel options.

/trustlevel — specifies the level of authorization at which the application is to run. Use /showtrustlevels to see the trust levels available.

/user: UserAccountName — specifies the name of the user account under which to run the program. The user account format should be user@domain or domain\user.

program — specifies the program or command to run using the account specified in /user.

/? — displays help at the command prompt.

One of the simplest ways to use runas in scripting is to import a previously exported REG file. For example, you can use it to deliver a REG file to a user's HKCU subtree as follows:

 Runas /profile   /user:test\olga "regedit /s d:\temp\regpatch.reg"

Or:

 Runas   /user:test\administrator "reg add HKLM\Software\NewApp\   NewVal=100"

Note

When the runas line executes, you are prompted to supply the user's password. Once you provide it, the change is made.

Logon/Logoff and Shutdown/Startup scripts provide another way to get around the security context problem when delivering registry scripts. For example, to deliver user-specific changes (HKCU), you can use logon and logoff scripts, which run in the security context of the currently logged on user, and for delivering registry changes to HKLM, you can use startup and shutdown scripts, which run under the LocalSystem security context.

Both logon/logoff and startup/shutdown scripts are part of Group Policies. As was outlined in Chapter 11, Group Policies can be applied at the local machine, site, domain, and OU levels, which means that you can assign any number or scripts executing for each machine or user.

Tip

Because there can be any number of logon/logoff and startup/shutdown scripts, you can easily run into problems with managing and troubleshooting them. Therefore, try to keep it as simple as possible, and use as few locations as possible to define scripts. Avoid using local GPOs, particularly if your computers are joined to a domain.

The command-line scheduler provides yet another way to deliver changes in the security context other than that of the currently logged on user.

Note

In the Windows Server 2003 family, the newer tool, Schtasks.exe, replaces the familiar At.exe scheduler. Although At.exe is still included in the Windows Server 2003 family, Schtasks is the recommended command-line task-scheduling tool.

Addressing the Timing Issues

Generally, the problem of script-timing involves answering the following questions:

Do users need to be logged on (or, on the contrary, must they be logged off) for the change introduced by the script to occur?
If your script makes changes to the registry, is the key to which the changes are introduced available at execution time?

Similar to script security issues, these problems can be addressed by using Startup/Shutdown and Logon/Logoff scripts. The general rule is as follows: if you need script modifications to HKCU, use logon and logoff scripts, while if you need to make changes to HKLM or HKD, use startup or shutdown scripts.

Note

For the most part, it is possible to 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 for the currently logged on user.

Addressing the Logging Issues

Logging and reporting of the changes is essentially important. However, as was already mentioned, tools such as Regedit.exe lack this capability, both in Windows 2000 and in Windows XP/Windows Server 2003. Furthermore, depending on the method that you use to introduce changes, logging mechanisms are different. Therefore, when it comes to registry modifications, including registry scripting, it is advisable to use the following approaches:

If you use simple batch scripts to deliver registry changes, you can use simple redirection. To illustrate this approach, let us return to our example with enabling or disabling EFS. The listing provided below shows how to use simple redirection to enable logging in batch script:

 @echo reg add   "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS"_ /v EfsConfiguration /t   REG_DWORD /d 1 /f >reg.log reg add "HKLM\SOFTWARE\Microsoft\Windows   NT\CurrentVersion\EFS" /v_ EfsConfiguration /t REG_DWORD /d 1 /f   >>reg.log if errorlevel 1 @echo command failed >> reg.log @echo reg   delete "HKLM\SOFTWARE\Microsoft\Windows_ NT\CurrentVersion\EFS" /v   EfsConfiguration /f >>reg.log reg delete "HKLM\SOFTWARE\Microsoft\Windows   NT\Current Version\EFS"_ /v EfsConfiguration /f >>reg.log if errorlevel 1   @echo command failed >> reg.log

Note

The Resource Kit comes with the Logevent.exe command-line tool, which you can use to generate custom events and log them into the system event log. In addition to using the Windows 2000/XP/Windows Server 2003 system event-logging, Logevent.exe also supports sending the event to another machine's event log. This capability is especially useful in a corporate environment, where you might need to have a central collection point for the results of this script on many systems.

If you use the Windows Installer to install applications on your workstations, it is recommended that you enable the verbose logging mode (see Chapter 13).
Finally, you can use third-party tools providing powerful logging capabilities (one of which is the Regmon.exe freeware tool considered in Chapter 14).