Software Deployment

restricting user access during an install is frustrating the the user and typically necessary. What application are you updating? Does it contain office file updates or just wants all applications closed? Will it cache the files to be applied on reboot? What tool are you using to potentially lock out users?

The application is called ChangePro from Litera. It compares two versions of an Office document (usually in Filesite). The setup runs silently but closes out word and excel. I guess it needs to update some files that are locked by those applications. I am trying to install it with SMS (SCCM). I am not using any tool to lock out the user, that's where I need help. I would rather do it with a script than use a tool.

For example, something similar to this:
1. We send a notice to user asking them to restart their computer to get the update.
2. User reboots the computer
3. User logs in to windows
4. A script kicks in that does not let the explorer.exe (or something) to launch thus preventing access to desktop
5. ChangePro old version is removed and the new version is installed.
6. explorer.exe is launched

Hello, i had the same problem when i tried to update adobe acrobat program, office programs had to be closed, i've solved the problem by launching a vbs scriptwho launched the update at user logon with the runonceex method. it is a registry key you have to set. It shows the user a customisable message too during the update

there are a number of option if you are dead set on locking out access: AutoIT, Winbatch and VbScript all have standard methods for blocking input. In addition there are a couple of other tools that can be used by searching on "locking out keyboard/mouse input". Any of these will get you what you want. Although some are dificult to implement in an SMS scenario.

Based on your response though I think you are heading in the wrong direction: Silent application installs that may prompt users to shutdown applications are a good way to get your help desk flooded with calls. Your install should be at maximum unattended with a progress bar. If the application is created properly it should prompt to close any open instances of office applications. This is the proper conditioning model to 1) let you users know that something is happening and 2) give them direct input on what happens.

If you know an install is happening and are prompted to do something you are less likely to try and jump back into outlook or word. I'd add an SMS/SCCM reboot at the end as a CYA if this is for a large user base. Outside of that let the technology that you already have work the way it is intended.

jyoung_usa, thanks for your reply. I agree with not messing with the installer or the system. But you are making several assumptions here that will only word in an ideal scenario. The first assumption is that the application will be created properly, which is not always true. Second assumption that the user will not try to open anything while the installer runs is not always true too. Some users cab be very impatient, plus everyone is always pressed on time. So even if 5% of our 1200 users open Office applications while I am running the upgrade, either the upgrade or the Office application will corrupt on those 60 computers.

Preventing any access to the desktop while upgrading the application is the best I can think of right now.

perimic01, runonceex only works if an admin user logs in!

mayurkirti, runonceex (with Windows XP, Windows 7 I don't know, never test it) works for every user, also standard users with no admin rigths, it is the msiexec process who needs admin rights for installing the application, to get around this you need that runonceex launch a vbs script who call a RunAS (any account with admin rights) of the msiexec command

perimic01, they changed it in W7. It only launches when an admin user logs in.

http://support.microsoft.com/kb/2021405