This site uses advanced css techniques
With the Lincoln release, the mechanism for activating a new version has changed somewhat, and it's introduced a new requirement to seek and kill some stray report-writer processes that may be left behind after the rest of Evolution has shut down.
If either isRWEngine.exe or isRWPreview.exe are running when the new version is installed, it will fail because these processes prevent the old version from being removed. Failed upgrades usually leave Evolution in a state requiring repair.
The straightforward — but tedious — process to clean these up after stopping al the services is to visit each middle tier machine, launch the task manager, and look for these processes.
There are two processes that might be left behind, and each has two forms of a name:
The funky names with the ~1 format are a short form compatible with MS-DOS 8.3 names, and we've never figured out why they still show up in modern operating systems.
It's usually easiest to click the Name column in Task Manager to sort the list alphabetically and group the report-writer parts together, then right-click each name and select End Task.
Note: sometimes the end-task request will fail with an Access Denied error: in this case the machine must be rebooted in order to clear it up. We've not figured out why this is necessary.
We've found that the manual approach is very tedious, so we've crated a batch script with the SysInternals process tools to handle this with one click.
Building on his lead, we've created a simple batch script that does this simply and elegantly: using the pskill program, the script runs through all the possible processnames on all the middle tier servers, killing errant processes that it comes across.
As a bonus, it's also able to kill processes that Task Manager cannot.
This does require a one-time installation of the SysInternals "PsTools", which are available on the SysInternals Miscellaneous Utilities page.
Though we only really need the pskill utility, we typically load the whole collection: they're generally useful to have around. The tools need only be downloaded on the main server (not on each middle tier machine).
Our practice is to put all of our Evo-specific tools in a C:\BIN directory and add this directory to the system's %PATH%. This makes the tools available from anywhere on the system and make scripts easier (no full path required for calling the command names).
Each of the tools has a one-time EULA dialog box the first time it's launched; we normally run the tool once just to get this out of the way. From a command window, just type pskill and acknowledge the licensing dialog box.
With our process tools in place, we're ready to create the command script. From a command prompt, change to the C:\BIN directory and launch notepad kill-isrwengines.cmd. One can probably cut the script text from this web page and paste it into Notepad.
@FOR %%P IN (isRWEngine isRWPreview ISRWEN~1 ISRWPR~1) DO @( @pskill \\EVO1 %%P «« — Edit server names! @pskill \\EVO2 %%P @pskill \\EVO3 %%P ) pause
The script has a FOR loop that cycles among each possible process name to seek and kill, and the body of the loop contains individual pskill commands for each middle tier server in the Evo system. Just replicate the lines for as many machines as are required.
Save the script, and paste a shortcut on the desktop: we normally name the shortcut "Kill RW Engines".
With the script in place, one can now kill all the report writer processes by double-clicking the shortcut. It will open a CMD window and produce a substantial amount of output; this includes PSKILL copyright notices, plus error messages if processes are not found.
All of this output — including the error messages — are routine and can be ignored: we don't normally even really look at the output.
Press RETURN when prompted to dismiss the dialog box.
Please note that this process should only be run when all of Evolution is shut down: running it on a live system will surely do bad things.
A tip o' the hat to Ben at iSystems Technical Support for suggesting this very useful approach.
First published: 2008/12/09