Appending to a Win NT Registry Entry
Novell Cool Solutions: Trench
Digg This -
Posted: 12 Apr 2000
Current version: ZENworks 2
It seems some of you have devised tricky ways to stick extra things onto registry entries, rather than having to create new ones. Check out the cool solutions below, and if you have another idea, send it in and we'll add it to the list. Is this a great community, or what?
- Christopher P's Original Question
- Brian M.'s Idea: Use kix32.exe
- Kelly H. and Steve A. and Pia S's Idea: Use PATHMAN.exe
- Geoff D's Idea: Use REGREAD in Pre-Launch Script
- Bruce R.'s Idea Posted May 10, 2000
Christopher P. wrote: Applications that install on Windows NT 4.0 will sometimes add a directory to the system PATH. Because this gets snAppShotted as a regkey change, it will overwrite a computer's existing path with the app object one. In a homogeneous environment, this works. But, in an environment that can't assume what applications you have installed, a method of appending to the current regkey settings is the desired action. How can you append to a reg. entry instead of replacing the existing one?
Currently, NAL does not support appending to a registry setting. Sorry.
You may be able to get around this by using the working directory or the environment variables page of the application object. This way you can change the path for just that application, but it would have to be launched through a NAL icon. You might also want to try using %path% to get the current path. If you have the application object write to your registry with the change, plus %path%, you should get the complete current path, plus the change you want. Be really careful with this one, because it will pick up any and all drives that the user has mapped at the time they run the install (some of which may not always be there in the future.)
Brian M. wrote: This is in response to the question posed by Christopher P. entitled "Appending to a Registry Entry".
I use kix32.exe (kixtart - Windows NT Server 4.0 Resource Kit) to append the path statement in a Windows NT registry. Kix32.exe and my script file are copied to the c:\temp directory on the workstation. The script file is run from the post distribution script. The logic I use is to check for the existence of the string I want to add to the path. If it already exists, I don't add it. If it does not exist, I add my new string to the existing path and write it to the registry. The following is what I use for my Oracle 7.3.3 32-bit footprint.
Post Distribution Script:
$oldpath = ReadValue("HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ Session Manager\Environment","Path")
$newpath = $oldpath + ";c:\orant.733\bin"
If you have questions you may contact Brian at email@example.com
To use Pathman with snAppShot, call Pathman.exe from the Distribution Scripts of the application object you are distributing. In the Run Before Distribution script, call pathman using the following syntax:
@Z:\PATHMAN.EXE /AS C:\WINNT\SYSTEM32;C:\NOVELL\CLIENT32;ETC
Replace Z:\ with the path to your exe and replace the example paths with whatever paths that you need appended to the System path statement. Pathman can also be used to append and remove paths from both the user and system paths:
/as - adds the semicolon-separated paths to the system path
/au - adds the semicolon-separated paths to the user path
/rs - removes the semicolon-separated paths from the system path
/ru - removes the semicolon-separated paths from the user path
"Pathman can modify any number of paths in a single call and includes error checking that can handle path abnormalities such as repeated entries, adjacent semicolons, and missing entries."
Currently this is the only reliable way I have found to append to the NT path statement. Hope that helps someone.
Steve A. wrote: Christopher P asked about appending to the path environment variable. We've had the same problem here. Our solution is to use pathman from the NT resource kit and launch a batch file at the appropriate point in either distribution or launch scripts.
The syntax is:
pathman /ru (remove user path)
pathman /au (add to user path)
Swap the u for an s to alter the system path. We put the command in a batch file and call it with @addpath.bat.AND
NEW on April 19, 2000:
Pia S. wrote: In relation to "Appending to a Win NT Registry Entry", I also had this problem a couple of years ago when we first began distributing applications (such as Oracle) via NAL that needed to append to the WinNT4 System path. I got around it also by using the PATHMAN.EXE utility but in a slightly different manner. I created a .BAT (OraPath.BAT) file containing e.g. the following line -
c:\winnt\pathman.exe /as c:\apps\orant\bin
that I distributed with the application to the local application directory, and then ran using the RunOnce option from the Registry key (also delivered with the application) -
Setting the key -
The .BAT file is then executed when the machine is next rebooted i.e. usually at the end of a NAL application delivery.
This method works well and we've been able to successfully distribute applications such as Oracle to 1000s of users across the WAN.
You may publish my e-mail address.
If you have questions you may contact Pia at Pia.M.Sherwood@transport.qld.gov.au
Geoff D., Melbourne, Australia, wrote: I had the need to perform this function and got around it by using the REGREAD command in the Pre-Launch script. I have included the AOT file if anyone is interested.Download AOT.
If you have questions, you may contact Geoff at Geoff_Durham@workcover.vic.gov.au
Bruce R. wrote: I've a method to add to the "Appending to a Win NT Registry Entry" item within "From the Trenches."
Kixtart (Kix32.Exe) is invaluable when you need to make an intelligent choice regarding registry updates.
I wanted to create an application object that would install a Lexmark printer driver on a NT terminal server, without actually creating any printer objects. The problem was that the snAppShot wanted to rewrite the HKLM\System\CurrentControlSet\ Enum\HTREE\Root\0\ AttachedDevices (REG_MULTI_SZ) value as the driver installs a device called LEXBCES.
The concern here is that this list of devices is particular to the server I was installing the driver on. If I ran the app. object on another different type of box it would have stuffed it totally.
To overcome this I first removed the whole key from the app. object. Then I wrote a Kixtart script that reads the reg. value into a string, checks if the device has already been added and if not tacks it onto the end of the string and rewrites the value. The script is executed as a post distribution script.
Distribution scripts (not launch scripts) run as the workstation object as detailed in TID 2953773. They cannot access the logged on user's drive mappings, only UNC paths. Make sure the WS object has file system RF rights to the files it needs.
Another catch here is the script processor does not support long file names for an executable (even when enclosed in double quotes). The short file name representation of the long file name will work OK, however, this can be an issue if you start creating many similar sub dirs. eg. Install App1, Install App2, Install App3 etc. To overcome this run kix32.exe from a .bat or .cmd file that is copied to, say, C:\Temp during file distribution. For simplicity copy the .kix file here as well. I had the .cmd file delete the .kix file and then delete itself as part of a cleanup routine.
### Regfix.Kix file ###
;Check to see if the LEXBECS device is already installed. If not append it to the end
;of the registry value.
$Lex = "Root\LEGACY_LEXBCES\0000"
$RegKey = "HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Enum\ HTREE\Root\0"
$RegVal = "AttachedComponents"B ;Read the attached devices
$Devices = ReadValue($RegKey, $RegVal)
;Check for LEXBCES. If already in the list exit
If InStr($Devices, $Lex)
? "Device already added, exiting"
;If we're here we should append the string
$NewDevices = $Devices + $Lex + "|"
WriteValue($RegKey, $RegVal, $NewDevices, REG_MULTI_SZ)B
### Regfix.Cmd file ###
\\FS1\Apps\Utils\Kixtart\ Kix32.Exe C:\Temp\ Regfix.Kix
If you have any questions you may contact Bruce at firstname.lastname@example.org
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com