Novell Home

Saving Techs from Rebooting

Novell Cool Solutions: Tip

Digg This - Slashdot This

Posted: 19 Apr 2000
 

Current Version: ZENworks 2

There is a strong sentiment amongst our readers that PC Technicians shouldn't do any more than they have to, to get apps installed on the machines of the world's teeming endusers. We, of course, heartily agree, since that is the whole raison d'etre for ZENworks. Here are some thoughts about saving Techs from having to reboot a system when they are installing apps. If you've got something to add, (and we'd be shocked if you didn't) fire away.


Original Question

Techs don't want to reboot when they install an app

Gregg V. wrote: We would like to make our application installation packages available to all users so that our PC Techs don't have to reboot a system when they go to install the application.

The ideal solution would be if we could somehow put a password requirement on the application to require a password to be entered before it can be launched. I have not been able to locate any way to do this. Please let me know if this is possible or if there is some other solution that would work.

Like I said, we want the IS Department people to be able to install the applications and not our general users.

Sorry, but ZEN really isn't designed to work like this. The whole idea is that the Techs don't have to go and install the software anymore. If you still like having them there (or if the end-users do), you still don't have to reboot. In fact, if you configure NAL correctly, you can just use the login command from the drop down menu to have your techs log in as themselves (or a special utility account), and install the apps. You really don't need to do a reboot at all. When they are done you can either log out or reboot then (which you will probably want to do after installing most applications anyway).


Stephen Hawkins' Idea

Regarding the "Techs don't want to reboot when they install an app" Ask the Experts question. If the person doesn't want their techs having to take the extra step of logging in on top of the current userid to get access to NAL folder, the NAL apps could have lines in the pre script to check if the user belongs to a special group for installers and if so the app runs, otherwise it terminates with an error message. We have several NAL apps in our globally available folder that, when executed, check the rights of the user to install the app.

The error message that is generated by the TERM command cannot be modified, as far as I know, and it is not user friendly. What we do to get around this is to have two NAL apps per application. The first NAL app runs a Winbatch-based program that executes the second "true" NAL app with the NAL.EXE or NALRUNW.EXE command. By having a program call the second "true" NAL app, a user-friendly message can be displayed if the user does not have the proper access before the second "true" NAL app ever runs. In addition, the program is also used to display user-friendly beginning and end prompts, with the number of the customer support desk in case of any problems encountered.

If you have questions you may contact Stephen at stephen.hawkins@ny.frb.org


Joe Sears' Idea

Regarding Techs don't want to Reboot. All you need to do is associate the app to a group that only the Techs are members of. Then the Tech can go to the users desk, right click on the "NetWare Service" icon in the system tray, choose "NetWare Login..." and login. Then you can run a NAL window or use NAL Explorer to install the application.

In our office every app has a group and we grant rights to the Apps via the groups, this work extremely well. We also have some apps that are only for the Tech group, they include things like OS's update and other intrusive install (IE).

If you have questions you may contact Joe at Joe.Sears@Nextel.com


Julian Greenwood's Idea

Joe Sears' Idea of having each Application associated with a group is ok until you hit the 64 group limitation that Novell has for group association ( at least they are not sure what will happen after 64). A better way would be to use ZEN to its full potential for filtering Applications.

You can do this with a control file for the Application that is a requirement just like the operating system requirement for an AO. You then put this "CONTROL FILE" into the user's home directory. This can be controlled from a central point so when a user needs an Application you just drop the file in and hey, presto, the app appears in the application explorer. Did I jump too fast there? Let me go back a little because I think I forgot some basic steps.

  1. Create a group -- Standard Applications.
  2. Associate all standard application AO's with this group.
  3. Associate all users with the Standard Applications group.
  4. Set the AO's enviroment to look for a control file in the user's home directory.
  5. Add or Remove control files as required for the user from their home directory.

This has a lot of benefits:

  • Removal of lots of group objects from the tree
  • Removal of associations from a user to apps
  • You have a visual cue of what apps a user has from the list of control files in their home directory.
  • Management of apps for a user is simplified ie. you do not have to go hunting for the correct group just drop the file to see the app.

Important Note: This setup is not for the user population above a certain number (250). This solution uses a control element outside of NDS (not a good thing for a large population). It can get extremely difficult to control, but for limited small user population control, especially for techs in the field, this one works a treat.

One thing that did come to mind was that ZEN 2 has filtering capabilities built right into it so that you can set filtering inside the AO itself without having to look for an outside control file. And the best way to deliver Applications to users is via direct association. You eliminate groups just for applications reducing clutter in the tree and you control everything within NDS. Of course there are going to be a few groups for rights and also for catchalls ie - standard apps - that everyone gets. But to leverage ZEN to its max, and get all of the reporting you can, direct association is the way to go.

If you have any questions you may contact Julian at tekjules@bellaltantic.net


Terry Smith's Idea

To reboot a workstation you can create an application in ZENworks that is a simple reboot. Start by creating a simple batch file that does nothing. Then create a simple application using it as the executable. After the application is in, set as install only in Identification. Set distribution as distribute always and reboot. You decide if you want to ask in case they hit it on accident for ask or not. Don't forget to set the system requirements, associate it, start it and the computer reboots.

Chris Smith

If I understand the question properly, the "Original Question" was how to avoid a reboot when the application forces a reboot. The only thing my tech crew has discovered is that locking the NT workstation prevents the machine from rebooting.

After you hear the "Ding.wav" you can unload the station, select 'No' to the reboot prompt (remember, even if you select "don't prompt" it still prompts, although it will reboot without any response to the prompt) and carry on with your regime of applications you still have to install. That's my tip. Good luck to all zenadmins out there!

If you have any questions you may contact Chris at csmith@citci.com

Steve Banks

We have a simple VB5 app that we associate to all users to run in the 'unsecure system' context.

The app asks for a password that only IT staff knows, and if correct presents a menu with several options: Control Panel / network/display/services, CMD prompt, RegEdit etc.

Since the app is run by NAL as an user with system privellages, the processes that they spawn run with that privilege too. A result of this is that all users have only 'user' access to their PC's but IT staff can access & install software without having to log the user off.

It needs NAL 2 and an application should be associated to all users that runs secure.exe, and is set to run as unsecure system user. It first asks for a password (currently hard-coded to 'freddy') and then displays a menu of things to do. This inherits the system privileges of the calling process, so the application can do things the user may not be able to (run Regedit, change Network & display settings, install software).

Comments / Issues

  • It's for NT only.
  • If you are to run software installs from the CMD window, the workstation object needs to have rights to the installation directory on the LAN.
  • Password is hard-coded. Ideally I guess it would validate it against a NetWare user (A job for Daniel Stricharz, I think...).
  • The printers control panel option doesn't seem to inherit system privileges (I don't know why, one day I may work it out, but it would only take 30 seconds to remove the button). Oddly if you run a .LNK file (if you drag the printer to the desktop) to open the printer dialog it works.. The services control panel needs a shortcut to run - drag the services icon onto the desktop and copy the shortcut into z:\public.
  • It's potentially insecure - if anyone can replace the exe with their own then it will run with system privileges.

I attach the EXE and VB5 source for SECURE.EXE. This is probably the crudest (but one of the most useful) VB programs I have bodged up.



New Question

We are setting up to forcerun about 30 applications to a 20,000 user enviroment and 15 of the 30 ask for a re-boot. Is there some way to send these apps down without re-booting till all 30 are down? Do we have to reboot? Or is there a way to automate the re-boot (NT). On Win95 we have no problem we just use the reboot.com but NT being G2 compliant needs the ctr-alt-del key sequence.

John Harrell

Re: Saving Techs from Rebooting (New Question").

You can temporarily configure the NT machine to AutoAdminLogon (requires Novell Client 4.6 SP1 or later for NT; see TID 10013350).

Using REGEDIT /S (no prompt) you can modify AutoAdminLogon values in the registry at the beginning to use the UserID/password you wish to log in with. Then after the last "real" application is installed, you can run an application that removes the AutoAdminLogon information from the registry, again using REGEDIT /S. You can use VBScripts to modify the registry instead of REGEDIT.

At a minimum you should modify the registry on the last step to set AutoAdminLogon = 0 and clear the DefaultPassword value, for security, even if you don't want to remove the other AutoAdminLogon parameters.

If you have any questions you may contact John at johnh@dnr.state.la.us


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell