next »

[Niek]

Hello,

I think it would be a great feature if Res Wisdom could run jobs under the current user. I've tried to make a job that locks the workstation of the currently logged in user, but it doesn't work.

Niek

[Airdeca]

Niek,

My guess is that you want to lock a user's desktop while you are installing software? Assume you succeed in locking his desktop, how would you prevent him from unlocking it again and go on with his work? If you don't want a user to be working on a desktop where you are installing software here is how I would do it:

- Send a postpone job notifying the logged on user and give him the chance to postpone or cancel the installation if you want.
- Enable AutoAdminLogon in the registry and specify a admin account to logon with.
- Place a cmd file in the Startup folder of this admin user that contains the command to lock the desktop.
- Reboot the machine.
- Use execute command and msg.exe to display a message that logon attempts will be futile (the Show Message Box task doesn't show the message when the desktop is locked)
- Perform the installation. During this action the desktop is locked and only administrators are able to log off this admin in order to unlock the desktop (and they should know better).
- At the end of the installation, disable AutoAdminLogon again and reboot.

I know it's rather drastic with the 2 reboots and all, but you can be sure that nobody interferes with the installation.

[Niek]

Hello,

thanks for your reply. We do an unattended installation (Windows Deployment Server) of Windows 7. The Res Wisdom Agent is the only software in the image. When the image is installed the agent connects to the server and joints the Windows 7 team. The default job of the team is to install Oracle client / Office 2010 etc. My idea was that the first job was lock the screen. In this way users see that the workstation is not ready for use and that IT is "fixing" it.
The workaround is to lock the workstation from the WDS part as last job, instead of the first job of the Res Wisdom part.

We also have a problem with installing a fax plugin for Office 2010. There are some current user key in it. When we install the job with Res Wisdom the current user keys are not installed in the current user part of the logged on user, but in the current user part of the user (service account) who is installing the software.

The workaround is a) temporary give the user local admin rights or b) strip the msi file and schedule a job in Res Powerfuse.

Let me know if there are any other good alternatives.

Kind regards,
Niek