When applications try to update files that are in use, they will frequently copy the new file to a temporary location and then add an entry the following key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]

This key lists the name of the temporary file name and the name of the file to be replaced. Next time Windows is restarted, the rename operation will occur before the file becomes locked and the registry entry will be removed.

A problem can arise if SNAPSHOT captures and uses the temporary file and the rename registry entry. ZENworks will copy down the temporary file to the workstation and the entries to perform the rename function even if this will backdate the DLL since ZENworks cannot compare the time/date or version of different named files. Thus if the file MSVCRT.DLL is dated 1/1/99 on the target machine and the Application object copies the file MSVCRT.NEW dated 1/1/98 to the workstation with the necessary registry entries, this system DLL will become backdated.

ZENworks 1.1 or greater is normally able to handle replacing in-use files on its own. Therefore, just rename the file MSVCRT.NEW to be the correct file name of MSVCRT.DLL and remove the rename entries from the registry update section of the application object.

If you find ZENworks is still having difficulty replacing in-use files, you can use the rename registry entries with the help of a little extra forethought. Using the MSVCRT.NEW example above, make sure the target directory is "%*WINSYSDIR%\MSVCRT.NEW". Then create an additional file to add which is also named MSVCRT.NEW. Set the second file’s source location to be the MSVCRT.DLL from the "%*WINSYSDIR%" and a destination location of "%*WINDIR%\SYSTEM32\MSVCRT.NEW" with the "COPY IF NEWER VERSION" option selected. Next set the original MSVCRT.NEW which is located with the source files located on the network to "COPY IF NEWER VERSION".  Notice that the two references to MSVCRT.NEW have a single logical location, though it is expressed differently.  Zenworks will not allow two identically named files to listed with identical destination locations without this little naming trick.  ZENworks will now guarentee that the MSVCRT.NEW will not be an older version than MSVCRT.DLL and cause back dating.  

Here is a copy of a sample AXT that safely performs the DLL rename procedure. 
RENAME.AXT
 

One thing that makes an administrators job easier than anything else is standardization. Unfortunately, this is not always achievable. As administrator’s we are often asked to overcome a lack of standardization. One problem that can occur is that some users have a second drive or second partition that they use to install software because their "C" drive is full.

When performing a snapshot of locally installed software, Drive "C" is usually hard-coded as in "C:\PROGRAM FILES\Microsoft Office". What happens when a user has a machine in which his "D" drive is normally his "Program Files" location and one in which "C" cannot handle receiving all of the "SNAPSHOT APPLICATIONS". Normally the answer involves reworking the users system to correct the problem.

There is another solution, however, that can easily and cleanly handle the situation.

In the launch script place the following commands.

REGREAD "HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion,ProgramFilesDir"
DOS SET PROGDIR="%99"

This will read a standard Windows registry entry to find the location of the "Program Files" directory and pass this to a variable. Then use this variable to copy files, set registry entries, or create text files. Here is an AXT that will read this registry entry and use it to create a small text file in the "Program Files" directory.

When an snapshot captures the install of software to a network drive it will usually create an uninstall which when run, will remove all of those files from the network drive. A normal user will not have the necessary privileges to perform the uninstall and they will get an error while trying to run the uninstall. An unwitting administrator who is simply trying to clean up a local workstation, may run the uninstall which removes the entire application from the server. To prevent these two possible problems, I simply ensure that the uninstall portion of the application does not get pushed to the client.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall is the registry key that needs to be removed to prevent the uninstall from appearing on the add/remove program list. This key will also list a file that is pushed the client that is the actual uninstall utility. I also take care to remove this from the list of "Application Files" to be distributed to the workstation.

When capturing PATH updates, the NAL sometimes will destroy the path of the target station. This is because NAL will capture the existing path of the "Clean Machine" and place this path on the target station, overwriting any previous path that existed instead of simply adding the additional entry. Be sure to check any snapshot for an entry in : 

[HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Session Manager\Environment]"Path"=. 

Pushing this entry will overwrite the target path. This entry should be noted and then removed. The path will need to be updated in a different manner.

Here are a list of a few possible solutions –

1)Edit the Autoexec.bat file on Win95/98 machines using the "Text Files" option of the application to add the line "Path=%PATH%;C:\MYAPP" to the end of the file.

2)Use the "Environment Variables" tab to modify the path while launching the program from the NAL window. In the value name place "Path." Enter "C:\myapp" for the value. Select the checkbox to use the append character ";".

3)Create an "APP Path" registry entry for each program installed. Below is a sample entry for MS-Word. Modify the entry to correspond to your application.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe]
"Path"="C:\\Program Files\\Microsoft Office\\Office"

4)Use the Pathman utility from the NT Reskit – supplement#4. This will
require Admin rights on the local workstation so this must be run either with Zen20 as a "system impersonation" app or be called using the SU utility w/supplement

#4 PATHMAN – A simple utility to modify a workstation’s path.
/as path[;path[;path ...]] Adds the semicolon-separated paths to the system path
/au path[;path[;path ...]] Adds the semicolon-separated paths to the user path.
/rs path[;path[;path ...]] Removes the semicolon-separated paths from the system path
/ru path[;path[;path ...]] Removes the semicolon-separated paths from the user path.
 

5)Create a search drive for the application.

Of all of the path management options, NUMBER 3, is the one I prefer.  In fact, it is the method many application suites such as MS-Office currently employ for adding applications to the path.  The only read draw back to options #3 is that it does not work for 16-bit apps and also may be tedious for an application that is actually comprised of many small applications.