Trigger Your Logon Script

On a hectic day in ABC Company's support center, the vice president of manufacturing calls in because he can't review an important Request for Proposal (RFP) before the deadline. He dials into the network to find his V drive missing. Infections of the latest virus are rampant; apparently, about 25 percent of the company's computers haven't run the virus software update that the logon script launches. The Windows XP project team needs a current hardware inventory for planning purposes, but the inventory database is out-of-date.

Logon scripts perform many tasks, such as mapping network drives, connecting printers, and scanning for viruses. Logon scripts also let you centrally manage which resources computers should connect to after they authenticate to the network. For many organizations, logon scripts are the most reliable way to run management tasks on thousands of computers.

Windows logon scripts are challenging because they're triggered reliably only when the computer that authenticates the user account is hard-wired to the network. Logging on over VPN and RAS connections usually fails to trigger logon scripts properly. Faulty triggering occurs in part because the user has already authenticated to local cached credentials and the network logon is a secondary authentication. On XP and Windows 2000 machines, logon scripts also aren't triggered properly because both OSs can use the NIC to connect to the network dynamically after the computer is booted and fully operational. Regardless of why a system startup doesn't trigger a logon script, its failure to do so can keep users from accomplishing their tasks and administrators from effectively managing mobile systems.

The script I present uses Windows Management Instrumentation (WMI) event monitoring to solve this problem. The script monitors for connections to the corporate network, then triggers logon-script execution. Although the script requires that WMI and Windows Script Host (WSH) be installed, you can deploy these services even with Windows 95. To ensure backward compatibility, I tested the script on a Win95 OEM Service Release 2 (OSR2) machine with WMI and WSH installed—and it worked well. Windows versions before Win2K don't include WMI and require that you install the runtimes. You can obtain the runtimes at http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/576/msdncompositedoc.xml. (Any machines that are Microsoft Systems Management Server—SMS—clients will have the runtimes, and you shouldn't update them with the downloadable runtimes.) Now, let me introduce the script goals, take you through the script, discuss how it's executed, and describe how to implement it.

WMI Event Monitoring
I won't review the fundamentals of WMI; they've been well covered in print and on the Web. However, I briefly discuss WMI's relevant event-monitoring abilities to show you how WMI lets this script accomplish its task. WMI's built-in event-monitoring system tracks events in any of the WMI classes. Any script can subscribe to these events and perform actions based on the occurrence of monitored events. Event-based systems generally reduce the CPU cycles used and the delays associated with polling a system element for changes in state. If designed correctly, a WMI event-monitoring script doesn't need to spin in a loop to monitor events; therefore, the script's CPU overhead is virtually unnoticeable. Internally, WMI performs some polling operations for event monitoring. However, the operations take place within the efficient WMI namespace. Your script doesn't need to start additional processes, reactivate idle processes, connect to external data sources, or wait for disk latency.

WMI event monitoring can enable event monitoring even where that capability wasn't designed into the original API. When a WMI provider is built for the API, the provider will automatically notify WMI when instances of its class are created, updated, and deleted. Even if you could employ a crack Windows system programmer, he or she might not find a combination of base APIs that allows reliable hooking and monitoring of VPN, RAS, and dynamic connection events across all versions of Windows (XP through Win95). Such a complex undertaking is in stark contrast to writing a short VBScript to monitor these events and take appropriate actions.

The Script Design Goals
Typically, when I create a script to be used in many companies, I make as few assumptions about the run environment as possible. In keeping with this approach, I adhered to the following design goals for the logon monitor script. The script should

• offer a reliable solution to a complex problem
• provide maximum compatibility for multiple versions of Windows
• have minimal performance impact on client computers and on user experience
• support simple tailoring that would let it run in other environments
• provide for easy implementation (e.g., no Administrator rights required)

A set of design goals that defines the nature of the scripting effort helps you create flexible scripts that you can adapt to additional environments and uses.

   Previous  [1]  2  3  Next