Speeding up Nal Initialization time

By Tommy Mikkelsen

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.

What’s Microsoft Active Setup?

Microsoft Active Setup is described in these excellent articles found here:


And 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.

The Setup

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)

How to do it

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

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 ;-)

Comment List
  • in reply to MigrationDeletedUser
    setNalStateW deliver me an error -> "CoCreateInstance failed 0x80040154"
    Can you give me a fix?
    I need the NAL offline at login time!

    help andreas
  • You can also run the naldesk offline to get it fast.

    The problem with the nal program it will run online automatic when it detects a network connection and will look at the nds tree. Witch can take a long time Special if you have drive mappings to other sites and be member of other groups in other site containers.
    This can take a 30 min or longer at our environment.
    If you are at the other site of the world and you get a big update with run forced then its also a big problem because everthing has to go over the wan.

    So people had to wait very long before they got their menu.

    The trick is run it first offline and then online to get the updates.

    This statement in the registry HKLM\software\microsoft\windows\currentverion\run
    Will run the nal always offline.
    Put it before naldesk runs.

    To get the updates you have to put after the naldesk execution run it online.
    You can do this by run the command SETNALSTATE ONLINE
    with a command delay run program Naldesk will automatic start running again.
    You can do this by putting the delayed command after the naldesk in

    So in short: the statup from you workstation in registry entry "run" look like this.

    (delay run program witch execute command for example after 120 sec) SETNALSTATEW ONLINE

  • in reply to MigrationDeletedUser
    Well....the title might be misleading.....

    It's not a matter of been slow, but a matter of cutting down the initial initialization
  • when launching NAL, does it need to go across the WAN? lot of tree walking?

    and how long is long, how many seconds does it take to load?

    We have never had issues with slow NAL, just wondering..

  • Run once and forced run are great but this is a good idea to use a standard component to get these kind of settings pushed out!