Article

ukdtom's picture
article
Reads:

9299

Score:
3.25
3.3
4
 
Comments:

5

Speeding up Nal Initialization time

Author Info

16 June 2008 - 5:00pm
Submitted by: ukdtom

(View Disclaimer)

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:

http://www.etlengineering.com/installer/activesetu...

And here:

http://www.appdeploy.com/articles/activesetup.asp

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]
"Version"="1"
"StubPath"="NAL.EXE : /H /U! /A=.SwitchToFF.NalApps.MyOU.MyO"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\DisableMSN]
"Version"="1"
"StubPath"="NAL.EXE : /H /U! /A=.DisableMSN.NalApps.MyOU.MyO"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\SwitchToOO]
"Version"="1"
"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 ;-)

AttachmentSize
registry.jpg77.73 KB

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

jorn_tnf's picture

Run once and forced run are

Submitted by jorn_tnf on 17 June 2008 - 11:35am.

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!

skapanen's picture

what makes it slow.. in your case?

Submitted by skapanen on 29 June 2008 - 10:41pm.

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

ukdtom's picture

Well....the title might be

Submitted by ukdtom on 30 June 2008 - 7:18am.

Well....the title might be misleading.....

It's not a matter of been slow, but a matter of cutting down the initial initialization

Anonymous's picture

nal spinning issue run it first offline and then online.

Submitted by Anonymous on 9 October 2008 - 8:17am.

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
SETNALSTATEW OFFLINE
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
HKLM\software\microsoft\windows\currentverion\run

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

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

kranzera's picture

Problem with SetNalStateW

Submitted by kranzera on 30 September 2010 - 1:28am.

setNalStateW deliver me an error -> "CoCreateInstance failed 0x80040154"
Can you give me a fix?
I need the NAL offline at login time!

help andreas

© 2013 Novell