Installing Software on a Remote Computer

Microsoft® Windows® 2000 Scripting Guide

microsoft windows 2000 scripting guide

« Previous | Next »   

Installing software remotely frees technical support personnel for other duties (such as installing new hardware) that cannot be carried out remotely. Remote software installation also enables you to install software from a central site, without having to copy the scripts and the Installer packages to each computer. Although you can use WMI to install software on remote computers, you must be aware of the potential security issues involved in performing these remote installations.

When you use the Win32_Product class to install software on a remote computer, you might receive an Access denied error message, even though you have full administrative rights to the remote computer. This can occur in a scenario with three computers involved, as follows:

  • You are running a script from your computer (Computer A).
  • The script is designed to install software on a second computer (Computer B).
  • The Windows Installer package for the software to be installed is stored on a third computer (Computer C).

The Access Denied error message occurs because of the way distributed security works in Windows 2000. When your script (running on Computer A) begins the software installation process, it connects to Computer B by using your user credentials. Assuming you are an administrator, you can perform any operation you want on Computer B. This is known as single-hop security because the security credentials used to start the script from your computer are being used on one remote computer (a single hop from your computer to the remote computer). If the installation process requires no more than two computers, then the software can be installed on a remote computer using the same procedure used to install software on the local computer.

However, suppose the Windows Installer package is located on a third computer, Computer C. To access the package, the WMI service on Computer B must connect to Computer C. This involves multihop security:

  1. Computer A passes the script credentials to Computer B.
  2. Computer B must then present security credentials to Computer C in order to access the Windows Installer package.

The problem occurs in step 2, when you might expect the script to present your security credentials. (This is multihop security because the credentials must pass through several points.) By default, multihop security is not supported in WMI scripting. This means that Computer B does not pass your security credentials on to Computer C. Instead, the WMI service makes this network connection using the LocalSystem account of Computer B. Because a LocalSystem account has no network credentials, it is denied access to the computer storing the Windows Installer package (Computer C). Because the package cannot be retrieved, the script fails.

By default, you can use your security credentials to connect to a remote computer. However, without additional configuration, that remote computer cannot use your security credentials to connect to a third computer. Default security is limited to a single hop.

There are several ways to work around this problem:

  • Run the script using delegation, which allows remote Computer B to pass your user credentials to Computer C.
  • Copy the Windows Installer package to the remote computer, and then install the software, referencing the local path. The script copies the Windows Installer package from Computer A to Computer B, installs the software, and then deletes the package. Security is then limited to a single hop.

    This method works, but it creates additional network traffic as the Windows Installer package is copied between computers.

  • Allow the computer hosting the Windows Installer share to accept Null sessions.

    This method is not recommended because allowing a computer to accept Null sessions is a potential security risk: It opens the door for anyone on the network to connect to a computer.

Trusting Users and Computers for Delegation

To implement multihop security, you must do the following:

  • Make sure that all the computers involved in the procedure have been trusted for delegation. This is a property of the Active Directory® directory service computer account.
  • Make sure the user account that will be employed in the operation is also configured for delegation.

You can use Active Directory Users and Computers to trust both users and computers for delegation.

Scripting Steps

Listing 8.15 contains a script that installs software on a remote computer. Because this script installs software that is stored locally (and not on a third computer), delegation is not required.

To carry out this task, the script must perform the following steps:

  1. Create a variable to specify the name of the remote computer (atl-dc-02).
  2. Use a GetObject call to connect to the WMI namespace root\cimv2, and set the impersonation level to "impersonate."
  3. Retrieve an instance of the Win32_Product class on the remote computer.
  4. Install the software, referencing the local path where the Windows Installer package is stored.
  5. Echo the success or failure of the installation.

Listing 8.15   Installing Software on a Remote Computer

1 2 3 4 5 6 
strComputer = "atl-dc-02" Set objWMIService = GetObject("winmgmts:" _     & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set objSoftware = objWMIService.Get("Win32_Product") errReturn = objSoftware.Install("c:\scripts\database.msi",,True) Wscript.Echo errReturn

send us your feedback Send us your feedback « Previous | Next »   


Microsoft Windows 2000 Scripting Guide(c) Automating System Administration 2003
Microsoft Windows 2000 Scripting Guide(c) Automating System Administration 2003
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 635

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net