I support over 200 NT Workstations and I'm looking for an Automated way for the users to Connect to an NT Server to access Softwars Install Pgms/Patches; and then execute Software Installs/Patches.
Unfortunately, with NT they'll need ADMIN Rights (locally) to install the SW. Ideally, I'd like an automated way for them to: 1) be Granted ADMIN Rights (locally) 2) Execute the Install/Patches and 3) Revoke their ADMIN Rights (locally).
If MSUSRMGR.exe is a possible solution, what would be the proper Command Line syntax to execute these procedures in a Batch file (or VBScript?). If Windows Scripting Host is a possible solution, is there any sample code available to perform these operations?

Who is Participating?

What I did for a customer was create a service on each workstation with instsrv and srvany from the NT reskit.
This service runs under an account that has local admin rights, and thus can install any software package.
The script that the service starts can be maintained central (one script for all users) and because the service is set to automatic startup the installation starts even before the user can logon to the workstation.
What you can and cannot do: (if you don't want to spend money on SMS)
- you can install any software, as long as no GUI interaction is required
- in most cases you cannot prevent a reboot in the case a manual installation (of the software)requires one, supressing a reboot can leave a system unstable.
- you 100% sure want to use winstall or wise install (i use the last one very often), sysdiff can do something for you, but doesn't see every change to a system, and cannot install services.
- you cannot make changes to the user environment direct, what I do in such a case is split the installation in 2 sections (where the Current_user settings are a different file) and run the user section from the login script.

I use these methods with success for the last 3 years with 2 of my customers, with a large number of connected workstations. (2000 for one customer and 500 for the other spread around 14 countries in europe).

Something like SMS or WinInstall is designed to do this.
They're far more secure.
This way, a service account (which has constant admin rights) does all the installs.
If users are given admin rights, for no matter how long, who knows what they'll get up to - don't go there !

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

In my opinion there is a way with "system account", and scheduled job with AT command.

0

bdemarzoCommented: 2000-03-15

In the NT Resource Kit, use the SU utility when running your packages. From the RK: "SU provides the ability to start a process running as an arbitrary user." It takes a little setup and preparation but once in place it's a great way to run packages and other tools from a user's desktop as an Administrator (or other user account).

0

BFU2Author Commented: 2000-03-15

I believe the answer would be "Yes" - they'd have to be logged on to the NT domain so they could access the SW Installation programs on the NT Server. Ideally, we were thinking:

1) User logons to their workstation as usual.
2) They'd go to an NT Server to access a Batch File/ Script.
3) The Batch File / Script would Grant the User temporary ADMIN Rights (Locally) so they could install any software patches.
4) After all installs are done, the local ADMIN Rights would be taken away(via the Script!).

The company is trying to avoid the costs if buying additional programs (like Winstall).

We'd like to do something like what SuNT does but, with an inexpensive, built-in option - like Windows Scripting Host. We're also looking for a "streamlined" approach where multiple reboots are not required (LOL).

Just remember if you try the method you outlined, that if you assign admin rights to the users account, the user will have to logoff/on for these rights to take effect. Also when removing the rights from the account the user would have to logoff/on again for this to take to take effect.