1. Start NWAdmin32
2. Select the container in which you want to create the application
3. Select Object – Create from the menu and select "application"
4. Select "Create an Application object with an .aot/.axt file"
5. Select the AOT file that was just created.
6. Verify the "Object Name" which will be used to create the application object.
7. Verify the "Source Path", ensuring it points to the distribution server.
8. Verify the "Target Path", ensuring it points to the location where the application was installed or where you want to install the application from.
9. Select "Next" to create the application object.

The registry tab lets you view all the registry changes that occurred to your machine during the snapshot process. The changes recorded here will be set on the target workstation. Any recorded changes can be removed to prevent those settings from being pushed to the client station. The value of the target entry can also be changed or replaced with a variable, which will be replaced at install time with the current value of the variable. Also, additional registry changes can be manually added to this section.

Each registry entry can have one of four different actions associated with it: create always, create if does not exist, create if exists, and delete. "Create if does not exist" will not modify any current values for a registry entry. "Create if exists" will only modify current values, but will not create an entry if one does not exist. "Create always"

There are three main areas of the registry, which frequently are changed during the installation of software. These areas are [HKEY_CURRENT_USER\SOFTWARE], [HKEY_LOCAL_MACHINE\SOFTWARE], and [HKEY_LOCAL_MACHINE\SYSTEM.

All settings recorded under [HKCU] will only effect the current profile on the PC. If a different user attempts to run the software with a different profile on the machine without reinstalling the software, the registry settings previously made in [HKCU] will not be in effect for this user.

All settings recorded under [HKLM] will effect all users on the current PC regardless of the user's profile. A different user with a different profile will be able to use the installed software and have access to all the previously made registry entries in [HKLM].

[HKEY_CURRENT_USER\SOFTWARE]

Settings in this area are frequently junk. The reason for this is that any settings here will not be available for all users on the PC, just the single user who installed the software. Most software is designed to work for all users on the computer, not just the one who installed the software. One way to test to see if these entries are needed is to try running the software just installed on the "Clean Machine" using a different profile. If the software still operates perfectly, then the entries were not needed. Frequently the software will dynamically create these settings if they do not currently exist. This allows for each user to have his own unique settings.

[HKEY_LOCAL_MACHINE\SOFTWARE]

This is the primary location for most registry changes that need to be made to the machine for various applications. I would browse through these entries and make sure all of the entries look correct.

Occasionally when software is installed to a "Drive Letter" on a Novell server, registry entries will still point to the UNC path of that server. This is not always a problem, but depending on your site, you may want to change this to the correct drive letter, to prevent users from accessing an incorrect drive letter. Furthermore, you may desire to replace all network drive letter designations with a macro variable to easily allow the application to be modified to support the use of different network drive letters for different divisions. The desired changes can easily be found and made by using the search and replace utility in NWADMIN32 under TOOLS->APPLICATION LAUNCHER TOOLS.

It is quite common to find entries that are not needed here. They usually arise from unneeded activity on the "clean machine" during the software install process. The existence of these registry entries should not cause any harm, however, and can be left alone until one is more comfortable with identifying stray registry entries.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet]

This is a very important area to inspect. This is where NT services are installed, file rename operations are set for updating "in-use" files, and PATH updates occur. All of these are possible sources of problems. Do not try to install an NT service on a 95/98 box. The file rename operations, can actually backdate DLLs if you are not careful. The PATH updates can wipe out previous path information on client machines. Please be sure to read the "TIPS, TRICKS, and PITFALLS to AVOID" article for more information.

[HKCU\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER] – These settings tend to record the recently accessed files, window positions, and other volatile information, which does not need to be passed to the client workstation.

[HKCU\SOFTWARE\NETWARE]

[HKLM\SOFTWARE\NETWARE]

[HKLM\SOFTWARE\NOVELL] – These settings record various information about mapped drivers, printers, applications deployed, etc. These generally do not apply for the application being distributed and can be removed.

[HKEY_LOCAL_MACHINE\SYSTEM\Controlset00X] – These settings are not valid. All entries under any of the controlsetxxx are backup entries. Only the entries under CurrentControlSet effect the operations of the workstation. Either these entries belong under CurrentControlSet or they were picked up when the CurrentControlSet was backed up to a saved registry location. These should usually be deleted, but if a snapshot is not working, it may indicate that they belong in the CurrentControlSet portion of the registry.

The "Application Files" tab displays all of the files that are associated with an application. It lists all the files and directories that will either be created or deleted during the install of the application. There are nine different settings for each file to determine how to handle the file: "copy always", "copy if exists",
"copy if does not exist", "copy if newer", "copy if newer and exists", "copy if newer version", "request confirmation", "copy if different", and "delete."

The array of choices can be dizzying, but I tend to use "copy if newer version", "copy if does not exist", and "delete". The "copy if newer version" checks the internal version number of DLLs and EXEs to check for the newest version, but in all other respects it is the same as "Copy if newer" which causes the file to be updated based upon the time/date stamp. (It is best to set all files to this setting unless you have a specific reason to set it to one of the other settings) "Copy if does not exist" is useful for making sure user data files are not over-written, such as bookmark.htm, but still allow for a default data file if one does not exist on the client machine.

Often stray files are captured during the snapshot process. The most common file is "MSCREATE.DIR". If you see this file, simply remove it. You may sort the file list by directory clicking on "Target Directory" at the top of the file list. Then check all the directories to make sure you are not creating unneeded temp directories or placing unneeded files in temp directories. Also, you may see many files name ".BAK" or ".OLD" which can be deleted. They are backup copies of DLLs made by your install program, but they will not necessarily be backups of the DLLs of the target station, to which you are deploying, so they can be deleted. Make sure text files such as autoexec.bat or config.sys are not accidentally distributed. Remove them from the "application files" section and add them under the "text files section"

The "Text Files" tab shows all changes made to text files. The text file section allows for text files to be modified instead of simply replaced. The best way to modify the path statement in an autoexec.bat file is to "Add text to the file" and select "Add to the End of the file". The text to be added should be "PATH=%PATH%;C:\MYPROGDIR;." To delete a line of text, you need to match the entire line exactly, which is usually very difficult. The solution is to use the search and replace option. An example would be to replace "Files=" with ";FILES=" to comment out any FILES command in the config.sys. The line "FILES=40" would be changed to ";FILES=40". Any valid system variable can be used to help customize the text file changes for individual workstations.

The changes for INI files are pretty straightforward and do not usually need tweaking. It is still best to examine these settings to ensure they exactly what you desire. On occasion it will be useful to change certain settings to "create if does not exist" to prevent the overwriting of existing values if you do not want current values changed. Also, variables can be placed as values for INI entries, which will be evaluated at run-time, which allows for customization of the INI files uniquely for each workstation.

This section is a little tricky and one must be careful with this section. Rights assigned to the application will grant whoever is associated with the application those same rights. Anyone unassociated with the application will have those file rights revoked. If someone already has already been granted the same file rights as the application and then they are associated with the application, their rights remain intact. If they are then unassociated from the application, they lose those rights, even though those rights were not originally given by that application. Furthermore, rights are not dynamic. The rights granted apply both inside and outside of the application. Furthermore, those rights do not apply to workstation objects, just users, user groups, or container.