This article has been tested on Windows 2000 and Windows XP using ZENworks 7.
If you are like me, you’ll probably find that over time, the NAL initialization takes longer and longer.
One reason for that is that more applications get added to the User, Groups or OU’s, and NAL has to check them every time to see if they need to be executed.
Now, and this is the clue………
If you, like me, have a lot of Run-Once/Forced run applications that are associated to the user, Groups or OU, then this article will provide you with the means to cut down initialization time.
In my case, I have 50 Applications, and out of those, 15 are Run-Once/Forced Run apps.
After I implemented this solution, the Initialization time was cut-down to approx. 1/3 of the time.
The solution is to use a combination of Microsoft Active Setup, and NAL.EXE Command Line parameters.
Microsoft Active Setup is described in these excellent articles found here:
In short, you might have noticed that every time you log on to a new workstation, there’s a lot of initial install going on, like configuration of Internet Explorer, etc.
Let’s say that you have an application that changes the default Internet browser from Internet Explorer to Mozilla Firefox. The Application is called .SwitchToFF.NalApps.MyOU.MyO
And you have another application that sets the *.doc extension from MS Word to OpenOffice. That Application is called .SwitchToOO.NalApps.MyOU.MyO
And yet another one that switches off MSN, and is called .DisableMSN.NalApps.MyOU.MyO
All the above applications are flagged as Run Once, Forced Run applications.
So to summarize, every time a user logs on to a new workstation, three applications will be run, and each time after that, those applications will be checked to see if they should run again. This takes up valuable seconds.
To see a screenshot of an entry for Active SetUp, look at the attachment for this article......
Funny enough, it shows you what key to delete in order to avoid Outlook Express to be setup, whenever a new user logs on to a workstation ;-)
(Hint...Go hunting in that branch of the registry)
So we’ll make a registry file that looks like this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\SwitchToFF]
"StubPath"="NAL.EXE : /H /U! /A=.SwitchToFF.NalApps.MyOU.MyO"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\DisableMSN]
"StubPath"="NAL.EXE : /H /U! /A=.DisableMSN.NalApps.MyOU.MyO"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\SwitchToOO]
"StubPath"="NAL.EXE : /H /U! /A=.SwitchToOO.NalApps.MyOU.MyO"
In the above registry-file, the version is whatever you decide, and the “StubPath” key specifies what to execute; in this case nal.exe with the instruction to run the application you specify.
Now make a NAL Application that can roll out the registry-file, and associate it to all your workstations.
Then remove the User, Group or OU association from the three applications mentioned above.
What happens now, is that the next time a user logs on to a workstation, the keys that you just put into HKLM will be compared against the keys in HKCU.
If they are missing, or the version number is lower, the install will kick off, and after that, the HKCU will be updated, so it will not run again.
Instead of checking over the LAN/WAN against eDirectory, and comparing towards the registry, it’s a built-in registry compare, and will, as such, be a lot faster.
Congratulations! Instead of checking 3 applications every time your users power on, you are now down to only one, the .ActiveSetup.NalApps.MyOU.MyO ;-)