Using ZENworks to Distribute Windows NT Service Packs
Articles and Tips: article
Consulting Manager
Novell Consulting
ANDREW ROOK
Senior Consultant
Novell Consulting
01 Mar 1999
Looking to install a Service Pack update on hundreds of NT workstations? This AppNote provides a methodology for automating the process using ZENworks.
- Introduction
- Using ZENworks to the Fullest
- Creating the Service Pack Update Action
- Running the Service Pack Install Action
- Conclusion
Introduction
This AppNote describes how to automate the installation of Windows NT Service Packs without compromising NT workstation security. The task is accomplished by leveraging the power of Novell's ZENworks and Novell Directory Services (NDS). The result is a properly applied Service Pack on your NT desktops, achieved without logging on with administrator access or even visiting the PC.
This information will help you efficiently deploy Service Packs to the NT desktops that may already be installed on your networks. The focus of this AppNote is to assist you with the creation and distribution phases using ZENworks.
The steps in this methodology can easily be adapted for any application or update that may have parameters to pass to allow an automated, hands-off installation.
This AppNote assumes that the reader has a basic understanding of the concepts behind ZENworks and how it operates. For further information, refer to the ZENworks Web site at:
http://www.novell.com/products/nds/zenworks
Using ZENworks to the Fullest
The creation, management, and enhancement of enterprise computing remain a top priority and concern for today's managers. As more users are added and applications are updated, the management of these items become extremely time consuming and expensive. Given the dynamics and complexities of today's enterprise applications, the network clients (workstations) must be stable and secure, while providing robust network applications and client functionality.
Novell's ZENworks builds on the industry leading enterprise functionality of NetWare 4.x that first introduced Novell Directory Services (NDS), the lifeblood of the enterprise model. When ZENworks is deployed according to proven methodologies such as the one outlined in this AppNote, customers can expect reduced cost of ownership and excellent return on investment.
As an example that is easily understood, consider what is involved in applying a Service Pack to update Microsoft's Windows NT Workstation software. Not counting the time it takes to physically travel to the PC's location, it takes about 10 minutes to power up the computer, log in as an administrator equivalent user, and run the executable or a batch file to apply the Service Pack. The Service Pack itself takes about 3 to 5 minutes to install. It's another 5 minutes to reboot the workstation, whereupon the original user can log in again to continue working. All told, the entire process takes about 20 minutes per NT desktop. If you have 1000 workstations, it would take one person 333.3 hours (about 8 weeks) to apply the Service Pack on all those workstations.
Now let's look at the same example using ZENworks. Adding a service or action to a policy take about two minutes to complete. All you have to do is create the action(s) in NDS, customize as necessary, and schedule the service. ZENworks does the rest. Applying the Service Pack on 1000 workstations takes only two minutes of your time, compared to 8 weeks without ZENworks. That's quite a return on investment.
The beauty of the ZENworks method is that, if you so choose, actions such as NT Service Pack updates can happen in the background, invisible to the users. Once the action is completed, you can either prompt the user to reboot or force a reboot of the workstation.
A Note About Adding New Components to an NT System
One important item many network administrators overlook is information contained in the README.TXT file of the Service Pack updates. Below is an excerpt from NT Service Pack 4's README.TXT file, which basically states that if you add or remove components from your system, you should re-apply the service pack.
"If you change or add new software or hardware components to your system after you install SP4, you'll need to install the SP4 again. This is because the files included on the original Windows NT 4.0 media may not be the same as the files on the Service Pack CD. You can't install new components, such as a new keyboard or printer driver, directly from the Service Pack media. You must install new components from the original product media and then reinstall the Service Pack.
"For example, if you install the Simple Network Management Protocol (SNMP) service after installing SP4, you'll need to reinstall the Service Pack. If you fail to do so, you'll receive the error message "Entrypoint SnmpSvcGetEnterpriseOID could not be located in Snmpapi.dll." This is because some of the files in the SNMP service have been updated in the SP4 and you have a version mismatch. Reinstalling the Service Pack fixes the problem by copying the newer versions of the files to your system."
Creating the Service Pack Update Action
Windows NT Service Packs are installed by running the accompanying UPDATE.EXE program. To set up ZENworks to deploy such an NT Service Pack automatically, complete the following steps.
In the NetWare Administrator 32 (NWAdm32.exe) utility that comes with ZENworks, create an NT User Policy and enable the Workstation Import Policy and Dynamic Local User.
Import the NT workstations into the NDS tree.
Create an NT Workstation Package and associate this to the workstation, workstation group, or container where the NT workstations exist.
Once you have created the Workstation Package, you can add an action to its list of policies. In our example, the action will be running the UPDATE.EXE file. To do this, click on Add Action as shown in the screen shot below. Name the action "NT Service Pack".
In the list of policies, highlight the action you just added (NT Service Pack). Click on Details, as shown below, to configure this newly created service to run the Service Pack UPDATE.EXE.
If you want to have this action occur at a schedule different from the default, you can easily change it. Select "Use this Policy Schedule" and choose when you want the action to occur from the drop-down list: Event, Day, Weekly, Monthly, or Yearly.
In this example, you want the action to initiate upon the occurrence of a particular event, so you select Event.
Since the Service Pack README.TXT file states that the Service Pack must be re-applied if changes are made to the system, you could also select Daily, Weekly, or Monthly as well.
Under "Run this policy when the following event happens", select the event you want to trigger the action. In this example, choose "User Desktop is Active".
At this point, you have specified that this action will occur on an event and that the event the Workstation Policy is waiting for is "User Desktop is Active". But you have not yet defined which action to initiate. This will be done later via the Actions page.
For now, you need to configure the schedule a bit by clicking on Advanced Settings. The Advanced Schedule screen opens on the Completion tab (shown below), where you can specify what you want to happen upon completion of the action. In our example, you want to enable (check) the "Disable the action after completion" option so that action will run one time only.
You can also determine if this action should reboot the workstation upon successful completion. The "Reboot after completion" option should be enabled (checked) for our example. In most cases, you would also want to prompt the user if a reboot is necessary. However, you do not want to do that for UPDATE.EXE. If an action reboots the workstation before Workstation Manager can write information back to the workstation to close the process, the action could run again because it was never completed in Workstation Manager's view.
From the Fault tab, you can determine how Workstation Manager should handle the action if there is an error or if it does not complete successfully. Your choices are listed when you click on the down-arrow box. For our example, select "Ignore the error and reschedule normally", as shown below.
From the Impersonation tab, you can select what type of "user" an action should impersonate on the workstation: interactive user, system, or unsecure system.
Interactive User causes the action to run in the context of the user who is logged in to that workstation. It gives the action whatever rights the workstation's User object has been assigned. Usually, this is just the user access rights. If the default user rights have been granted, the action cannot change settings that require administrative rights.
For Windows 95, choosing Interactive User specifies that the user's rights are used for access.
System causes the action to run in the background as a local service. When the action is dispatched, it runs under the context of that local system. The action is granted administrative rights to the workstation. Use this option only if the action does not require any user intervention (it does not display a user interface that requires input).
For Windows 95, choosing System specifies that the workstation's rights are used for access.
Unsecure System (NT only) allows actions to run in the background but, at the same time, they can interact with the user if interaction is needed. Use this option for applications that require user interaction. This method is unsecured, because the operating system permits address mappings between the user and system space. However, this option should be avoided if possible.
If you decide to use System, the user will see nothing displayed on the desktop. You may decide to use the Unsecure System where the action has system rights but the User still has the defined User security from NT -- for example, users who are members of the "Users" group in NT still cannot add users in User Manager. With this option users will see the action running, so you may want to display a text file to notify them of what is taking place. An example of how you could do this is given in step 17.
From the Persistence tab (shown below), you can choose if you want this action to remain persistent after a reboot. In this case, this option should be disabled (unchecked).
From the Priority tab, you can set the action's priority as Normal, Above Normal, or Below Normal. Normal is fine for our example.
On the Time Limit tab, you can select a time within which the action should complete. For the example shown below, if the action is not completed within 10 minutes, it is terminated and rescheduled to run again based on your policy schedule.
Now that you have defined when the action will occur and how Workstation Manager will manage the action, you need to configure what you want the action to do. To proceed, select the Actions page and click Add, as shown below.
In the Item Properties window, you can specify the name, working directory, parameters, and priority for the action. In the Name entry box, enter the full path and filename for the file you want the action to process. In this case, it is easier to use the Browse button to select the UPDATE.EXE file. No working directory is necessary.
The UPDATE.EXE program allows the use of command line switches to install the Service Pack in various ways. The parameters shown in the sample screen above are typically used for a hands-off, automated install.
The following is a list of switches UPDATE.EXE recognizes:
-u Unattended mode
-f Force application to close at shutdown
-n Do not create uninstall directory
-o Overwrite OEM files without prompting
-z Do not reboot when update completes
-q Quiet Mode (no user interface)
Whatever other parameters you decide to use, be sure to test the outcome before deploying an action to all of your workstations.
When you are finished configuring the action, click OK. Then click OK again to save the policy action you have added.
At this point, you have added the action "NT Service Pack" to your Workstation Policy. What you are doing is simply telling ZENworks to deploy the Service Pack to any NT desktops that are associated with this policy in NDS.
If you need to add other actions, you could do that here as well. For example, if you selected Unsecure System for the impersonation, you might add an action to run NOTEPAD.EXE and open a text file to notify the user of what is taking place. An example of the text file might be:
"This workstation is currently having the NT Service Pack 4 installed. Please do NOT start any applications until the workstation has completed the install and rebooted. At that time you may log in and continue with your normal schedule."
The full string for the Name entry box is:
C:\WINNT\Notepad.exe\\ZENSRVR\SYS\PUBLIC\SP4Info.Txt
After clicking OK in the Item Properties window, you will be returned to the Scheduled Action list. Note that two actions have been added for this policy: one for running UPDATE.EXE, and one for displaying the text file in the Notepad.
If the actions are not listed in the order you want them to be run, enable (check) the "Run items in order listed" option. Then highlight an action and click Move Up or Move Down to place them in the desired order.
When you have finished adding and configuring your actions, you can run the Workstation Manager Scheduler (WMSCHED.EXE) program to verify that the NT Service Pack action has been added to the workstation scheduler.
Running the Service Pack Install Action
The next time the desktop is active on an NT workstation, the Service Pack will be installed to the workstation via ZENworks. Interestingly enough, the user of the NT workstation does not have to be administrator equivalent. After the Service Pack has run, the machine prompts the user for a reboot, after which the action will be disabled. With the action configured this way, the Service Pack is installed only once. If you need to have the Service Pack update run again, simply reactivate this action.
The following screen shots illustrate how this all happens. First, when the user logs out and logs in again, the policy will execute, as can be seen from the WMSCHED.EXE screen shown below.
After the policy runs, the user will be prompted (based on this policy example) for a reboot, as shown below.
After the workstation has rebooted, you can check in WMSCHED.EXE to verify that the action has completed and is not scheduled to run again.
If an administrative user decides the update action should be run again, the action can be rescheduled from the NDS Workstation Policy object using NWAdmin.
Conclusion
By using ZENworks, you can easily distribute Service Packs to the Windows NT desktop without granting administrator rights on the NT machines. Because ZENworks uses NDS, you can manage all of your resources from one single utility in one common Directory, without having to touch every workstation.
Although this methodology refers specifically to NT Service Packs, it can be used to distribute other types of updates as well. For example, you might use a similar technique to upgrade Client 32 with the /ACU (Automatic Client Update) and /U options (Unattended text file that can be generated from NCIMAN.EXE). Again, you benefit from having a single Directory and a single point of management, using one simple administrative tool to deploy updates to any number of workstations.
For more information about developing network solutions with Novell Consulting, visit their Web site at:
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.