This came to haunt me today - like a ghost of Christmas-coding past.. \:D I have come up with a solution will work well for this install process, as well as my workstation management system's maintenance needs.

I am pushing out a procedure to do daily maintenance on various workstations, using a centralized network management tool. The procedure can invoke a process on the target system in either the currently logged-on user context or the SYSTEM context. It needs to run in the SYSTEM context to have the correct rights.

I needed to be able to A) inform the user that maintenance was starting, and B) allow the user to defer the maintenance (and any possible reboot) by 30 minutes. This implied two-way communication.

I started with the PSExec process above, but on Windows 7, the screen would flash, blink, and turn grey, followed by an ominous message that another process was attempting to communicate from the great beyond (or at least another session). Only after approving communication did the KiXtart MessageBox appear. This was not smooth, slick, and comforting to the user in any manner! If they did not allow the communication, they would not be alerted to the maintenance or reboot process and might lose work.

I needed a method to run in the user context, yet generate messages from the SYSTEM context.. what to do??

Well, in a nutshell, I created a user process that was invoked as the logged on user (run & continue method) just prior to the SYSTEM context maintenance script. For logon-based installs, the user process could be started by the login script, and would wait up to several hours for the SYSTEM process to start.

The user-context script basically needed to
  • Wait for a file that contained the parameters for the MessageBox function
  • Determine when a new message appeared in the message file
  • Sleep a reasonable amount of time when the file was present, and just a little longer between checks when it wasn't. (I used 10 and 20 seconds, which worked well and caused little impact.)
  • Wait a specific amount of time for the message file to show up. Since the management system runs at noon to collect data and schedules the invasive maintenance for 7pm, I allowed the process to wait up to 8 hours for this file to appear.

The SYSTEM writes the parameters of the message to the file, then reads an INDEX value from the message file (message.ini), increments it by one and writes the value back. Writing the index value last insures that the most current message data is written before the INDEX value changes. The SYSTEM process then waits 10 seconds (for good measure) plus 20 seconds (the worst-case time it takes for the user-message process to detect a new message, plus the timeout value of the MessageBox function. So - for a 5 minute timeout (300 seconds), the delay is 330 seconds.

The user process wakes up after the 10-20 second sleep, reads the INDEX value and compares it with the previous value. If it's larger, a new message is present. It reads the message, title, status, and timeout values and pops them into a MessageBox function. The result of this function is then written to a different file (since the user probably won't have write access to the SYSTEM generated message file). I use RESPONSE.INI, with a RESPONSE section and a Value parameter.

The SYSTEM process, after sleeping, reads the response, deletes the response file, and processes the response.

There's a special value - 9999 - that when written by the SYSTEM process is used to inform the User process that it is no longer required. The user process terminates.

If the SYSTEM process needs the user process to remain, but knows it won't be needed for a while, it simply deletes the message file. The user process doubles its sleep interval from 10 to 20 seconds until the message file re-appears or the max runtime value is exceeded.

I used WKix32.exe to call the user process with the -I parameter. It works very well - there's no flash or stutter - the MessageBox simply appears. The overhead of the user process is so low that when monitoring the active processes, it never shows any utilization.

I'll be posting the code for the user process and the mechanics of calling it from the SYSTEM process in the Script Vault in the next day or so, maybe right after the Ghost of Christmas Presents ;\) makes its appearance. \:D

Merry Christmas to all, and to all - bug free code!!

Scrooge McCoder (er.. Glenn)
_________________________
Actually I am a Rocket Scientist! \:D