The Mole #15: Technical Answers from Inside Microsoft - Scripting Remote on NTW, Discrete Networks, Logon Scripting

  • Article

August 16, 1999

Editors Note The questions and answers below are from the Inside Microsoft column that appears regularly on the TechNet Web site at the following location: https://www.microsoft.com/technet/community/columns/insider/default.mspx. To find out how to submit questions of your own, see the end of this article or go to https://www.microsoft.com/technet/community/columns/insider/default.mspx.

The TechNet Mole provides expert answers from deep within Microsoft to questions from IT professionals. This installment focuses on these issues:

  • Scripting Remote, Silent Patch Installation on NT Workstation (not for the faint of heart!)

  • Connecting to Two Discrete Networks with NT

  • That Doggone Logon Scripting

On This Page

Scripting Remote, Silent Patch Installation on NT Workstation
Remote Patch Installation: The Macho Way
A Tale of Two Libraries, or Connecting to Two Discrete Networks with Windows NT
That Doggone Logon Scripting
Got Questions? Mail the Mole

Scripting Remote, Silent Patch Installation on NT Workstation

Dear Mole,

I want to be able to install patches on our Windows NT Workstations remotely, but our security scheme requires that the users do not have local administrative privileges and the installs will not complete successfully without them. My company is reluctant to shell out the bucks for SMS. Any ideas?

Need a TCO savior

TCO:

Some correspondents, like Celeste Aguayo (below), have begun to sniff out solutions of their own:

I need to have my own custom-made executable run on an NT machine as a service. How do I install this executable as a service?

Now, if Mole were a piker, he'd simply tell you all to go out and buy System Management Server—a bit pricey, yes, but not necessarily a bad idea, since it's the ready-to-wear deployment solution of choice for Windows NT. In fact, you can get a 120-day evaluation version of SMS 2.0 at https://www.microsoft.com/smserver/downloads/20/default.asp to see how well it fits your needs. The labor intensive fallback is to have a domain administrator personally visit each client, log on and install the patch.

But wait! There is a third way, one Mole's unearthed by "badgering" assorted Microsoft insiders until they came acrossU.

Remote Patch Installation: The Macho Way

This, according to Mole's informants, is an exhilarating solution for the savvy domain administrator with good scripting skills—and a pain in the #@% for everyone else. Mole trusts you know which you are. Be warned, too, that you're going to burn some cycles—creating, testing, implementing—should you choose to do this. That is, even if you really know your way around Windows NT administration, you're still going to be investing several days of your life in this activity. Ready? If so, here's the basic concept.

  • Create a silent installation script file for the application, patch or update that you would like to place on your client Windows NT Workstation machines.

  • Copy this silent install script onto a network share.

  • Create a service remotely on the client Windows NT Workstations. This service will run under the context of a domain account that is a member of the local Windows NT machine Administrator group.

  • At the desired time a Network Admin launches the created Updater service on multiple workstation machines. This service checks for any updated installation scripts on the specified network share.

  • The installation script will audit a successful installation and stop the client machine Updater service.

Up to the job? Good for you. Specifics follow:

What the service on the Client Windows NT Workstation does

The service running on the machine itself is an executable, but a very, very simple one. Here is what the .exe will have to accomplish (please note that this was written in Windows NT command line language for ease of understanding, but the file the client service references MUST be an executable):

\\Server\Share\InstallScript.exe

So, we see that the service really only does one thing: runs another file. The file referenced on \\Server\Share could be a .bat or .cmd—the format is irrelevant at this point. This allows the administrator to create one install package and have a variety of machines connect and run the installation package. After installing the package, the InstallScript will audit a successful installation by creating a text file titled with the %COMPUTERNAME% variable in a network share created for such a purpose. The last thing the InstallScript file above should do is stop the Updater service that is running on the client Windows NT Workstation. This way, an administrator can have a program run locally on each machine and determine what this program is by placing it on a specific network share.

Remotely installing the service

Now that we know what the service will do (run a simple .exe file that will point to a file on a network share), we need to know how to install the service without physically going to each machines' console. In order to install a service remotely, you must be logged on as an account that has local machine Administrator rights. Use the XNET.EXE utility included with the latest version of KiXtart in a batch file similar to the following example that we will call INSTSVC.bat:

@echo off
rem INSTSVC.BAT
rem
rem Sample file demonstrating how a service can be
rem installed on a remote system.
rem
rem Note : This code sample is provided for demonstration purposes only.
rem Microsoft makes no warranty, either express or implied,
rem as to its usability in any given situation.
IF "%1" == "" GOTO ERR0
ECHO Press Enter to install your Updater service on %1...
MD \\%1\C$\Update
IF ERRORLEVEL 1 GOTO ERR1
COPY Update.exe \\%1\C$\Update
IF ERRORLEVEL 1 GOTO ERR2
XNET INSTALL \\%1\Updater /b:C:\Update\Update.EXE /n:"Updater" /u:Administrator /p:Password /s:Demand
REM ** IMPORTANT: XNET.EXE must use an .EXE file!
ECHO Your service successfully installed on %1!
GOTO END
:ERR0
ECHO INSTSVC : Installs service on a remote server.
ECHO Usage : INSTSVC (name of machine to install service on)
ECHO Example : INSTSVC MACHINENAME
GOTO END
:ERR1
ECHO Failed to create directory on %1!
GOTO END
:ERR2
ECHO Failed to copy Update.EXE to directory C:\Update on %1!
GOTO END
:END

Some notes about this service:

  • It is manually started (i.e. it does not start at system startup).

  • In this example, the service runs under the context of an Administrator account. You should probably create a custom domain account that has the advanced right to run as a service for this purpose. This account will need to have rights and access to the local machine as a local administrator, as well as access to the \\Server\Share\InstallScript.exe file, and the audit share (see above).

Putting it all together and Testing, Testing, Testing!

Once the service has been installed on all client Windows NT Workstation machines, the administrator of the network will need to create a package to silently (read: no user interaction whatsoever) install the application or update. Since an application install is in reality just file copy and registry changes, you could use the SYSDIFF.EXE resource kit utility to create a list of the registry changes and files copied. Because of space limitations, though, we leave the topic of SYSDIFF.EXE for another time.

After the service is installed on all client Windows NT Workstation machines and the silent installation file is complete, the administrator is ready to begin the automated deploymentU. Or is she? This is the time to stop and repeat after Mole: NOTHING SHOULD EVER BE PUT IN A PRODUCTION ENVIRONMENT WITHOUT THOROUGH TESTING!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This means test every step. This means YOU.

Okay, now that all steps have been tested and work properly, the administrator is ready to start the Updater service on the client Windows NT Workstation machines. A few points to keep in mind:

  • It is possible to use Server Manager to turn on the Updater service on each client Windows NT Workstation, BUT it will prove exceptionally tedious for more than two or three clients. Writing a batch file that uses the Windows NT Resource Kit tool SC.EXE to start the service created above on each machine is recommended. SC.EXE, like SYSDIFF.EXE awaits explication in a future column.

  • It is theoretically possible to have users logged in and perform the silent install in the background. But, hey, some problems may exist if you decide to try this route:

    The user may be running applications that have files locked which need to be copied over by the silent install package, thereby causing errors.

    A reboot may be necessary to complete installation of the application—this would be an unpleasant surprise for users.

    The capacity of the file server that holds the silent installation package (remember "\\Server\Share\InstallScript.exe"?) should be taken into account. Using SC.EXE, it is possible to turn on the Updater service on hundreds of client NT Workstation machines simultaneously—which could exceed the capacity of some file servers. Perform your client updates in manageable chunks. (You already knew that, right?)

Et voilà! Identical changes have been made to all specified client Windows NT Workstation machines via a single silent installation script. Administrators have a list in the audit directory of which machines have been updated. All updates have been done as a local administrator without increasing the level of user permissions. At first glance, this method may seem like a security breach, but remember that a Domain Admin must perform the remote service installation on any client machines.

Mole would like to credit Adam Henderson and Chuck Anderson in Microsoft Premier Support for their contribution. You gotta love those guys!

A Tale of Two Libraries, or Connecting to Two Discrete Networks with Windows NT

Dear "MOLE"

I have what I think to be a unique problem. I am currently in charge of the network services for three academic libraries. In addition to connecting our computers to our university network, our libraries maintain a backup connection via leased phone lines to another university which provides us with access to the shared consortium online catalog.

This connection to two discrete networks is managed by the fact that the library hubs are connected to two distinct routers, one for our university network and also to a separate router for the backup connection to our consortium partner's network. We are currently running Windows 3x and have allowed for this dual connection by configuring a boot choice in the AUTOEXEC.BAT and CONFIG.SYS files.

We are currently moving to Windows NT and would like to maintain this dual connectivity to two discrete networks. My question thus is this:

Is it possible in Windows NT to configure a workstation with ONE NIC card to find two discrete networks? Each workstation has a fixed IP address for each network. We would like to use the IP address of our own university network as the primary Gateway. Is there any way to configure the workstation such that when our university network goes down, we can switch to the consortium gateway as a backup? I am aware that Windows NT can be configured to detect a dead gate, but can this feature be only used when connected to a single network?

David S. Perry. Director Network Service, New School University Libraries

David,

Mole supposes you can provide this same functionality using Windows NT Workstation at the client. The approach would be conceptually the same as you have been doing with Windows—a multiple boot scenario. However, with Windows NT Workstation, you would need to do more than have a boot choice. You would install Windows NT Workstation twice on each workstation, configuring one installation for the specific network settings to access the university network and the other installation configured to access the second university (the "backup" connection.) The bottom line is—this would be a headache to install and support.

Here's a better alternative: Configure a Windows NT Server to run the Routing and Remote Access Service (affectionately known as RRAS.) You would set up this server as a dual-homed (two NICs) machine and assign one NIC to one network and the second NIC to the "backup" network. This scenario even allows clients to access either network without rebooting.

Even more good news—Routing and Remote Access Service is already available to Windows NT Server 4.0 operating system customers at no additional charge as a released-to-Web product. TechNet provides the Routing and Remote Access Service Update for Windows NT Server 4.0.

The white paper Routing and Remote Access Service for Windows NT Server 4.0 and 5.0: New Opportunities Today and Looking Ahead is a good technical source for RRAS:

And for TONS of information on Installing, configuring, and administrating RRAS, please check out Chapter 1 - Introduction to Windows NT Routing with Routing and Remote Access Service from the Microsoft Routing and Remote Access Service for Windows NT Server Administrator's Guide.

And now, David, if Mole might ask you a question return. Do you have a favorite recipe for cleaning and preparing Bookworms? Is it true they "taste just like chicken?"

That Doggone Logon Scripting

Dear Mole,

We have several Domain Controllers utilizing replication for the netlogon. We also use relative paths for our scripts. For different conditions, we call batch files from the script, however, we must use the complete UNC path to the batch files or place them in the scripts directory, up one folder from the relative directory the logon script is in (defeating the purpose of relative path).

  • Is there a variable representing the Domain Controller the user is login into at the time?

  • Is there a way to set the path to the relative path the logon script is in while the script is executing?

  • And finally, is there any way to prevent the user from closing the script window prior to its completion?

To be specific, we have a directory c:\winnt\system32\repl\imports\scripts\users. The logon scripts are in the users directory, but to execute a batch file from the logon script, we have to place it in the scripts directory or call the complete UNC path. We would like to place the batch file in the same directory as the script file.

Ben Harbour, Lan Manager

Ben,

How about %LOGONSERVER% ?

Here's a good KnowledgeBase article that goes into some detail, including gotcha's (Mole's Dictionary of Technical Terms defines gotcha as "that which will bite you in the #@%."):

  • 141714: How to Use %LOGONSERVER% to Distribute User Profiles

The following article addresses the issue of making the LOGONSERVER available after the logon script runs.

  • 183495: %LOGONSERVER% Variable not Available After Logon Script

And finally, how to prevent users from terminating the logon script window prior to completion?

One approach is by way of System Policies. In User policy, there is an option to "Run logon scripts synchronously", under the "Windows NT System" in the Profile Policy Editor. What "Run logon scripts synchronously" means is "Wait for the logon scripts to complete before starting the user's shell."

Here's the guide on system profiles and policies. Appropriately named Guide to MS Windows NT 4.0 Profiles and Policies.

Another way to prevent users from interrupting the logon script is to use KixTART utility. The KiXtart (Kix32.exe) tool included on the Windows NT Server Resource Kit version 4.0 CD-ROM provides some networking functionality for Windows NT that is not built-in to the Windows NT user interface. KiXtart is a login script processor and enhanced batch language for Windows NT. However, depending on how the logon script is started (for example, from a batch file) there still may be a short period of time between when the batch file calls the logon script that the user may be able to cancel the batch. More information on KiXtart can be found in KnowledgeBase article:

  • 175732: Installing and Using the KiXtart Login Processor Tool

Got Questions? Mail the Mole

Communicate with Mole at [closed account]. Send him your toughest questions. And if you think you have a better answer than Mole's, or a different one, send that along, as well. Please include the following:

  • Your name

  • Your title

  • Your company

  • Your e-mail address

  • Your question/solution/compliment

Credits

Credits. Mole is, as usual, much in the debt of Mr. Lon Collins.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.