An Application Launcher Autostart Strategy
Novell Cool Solutions: Feature
By Ted Haeger
Digg This -
Posted: 20 Mar 2002
Version: ZENworks for Desktops 3.2
Update: See additional Q&A about this article.
This write-up helps you to:
- Automatically enable workstations to use the Application Launcher
- Eliminate your dependency on login script commands
- Avoid share-locking your Application Launcher files on the server
- Start taking advantage of the Application Launcher's disconnected capabilities
You're probably already using Disconnected mode in the ZENworks Application Launcher. (If you're not, it's probably because you haven't upgraded to the 3.x generation of ZENworks for Desktops -- shame on you!) You probably have also discovered a limitation in setting the Launcher Configuration attribute "Auto-start NAL" to ON. This brief write-up documents a method for enabling all users on a workstation to Auto-start NAL through a couple of different means.
This write-up will be referenced in the Novell BrainShare 2002 session TUT 313, "Advanced ZENworks Application Management." If you like the tricks in this article, then you should come to BrainShare. More than 20 break-out sessions will be directly related to the ZENworks product line. It's a brimming cornucopia of pure ZENworks geekiness.
- In the 3.x generation of ZENworks for Desktops, running either NAL.EXE or NALEXPLD from the server's SYS folder automatically puts the files required to run disconnected NAL onto the local workstation.
This does not include installing the Application Launcher Service on Windows NT/2000/XP machines. That's still part of ZfD 3.x -- the client install.
- Once the Application Launcher files are copied locally, you can run NALDESK.EXE from the Windows system folder (usually c:\winnt\system32 or c:\windows\system) in order to start your preferred Application Launcher mode.
- The Launcher Configuration attribute "Auto-start NAL" allows you to immediately enable the Application Launcher for disconnected use by putting a shortcut to NALDESK.EXE into the user's startup group. (However, this is not necessarily the best way to go. Keep reading.)
- If you start the ZENworks Application Launcher from the local NALDESK.EXE and you are not logged into the directory, the Application Launcher will automatically work in disconnected mode.
- If you start the Application Launcher while logged into the directory, the Launcher will:
- Check the server's Application Launcher file versions and update automatically
- Read application associations from the directory
- Save bandwidth by reading application attributes (and files, if cached) from local cache
- Login scripts are not the best way to manage the Application Launcher. Sure, it's an initial way to get the Application Launcher deployed. However:
- It does not support offline users.
- If you're also starting the Application Launcher from the Startup programs group, it sometimes starts two instances of the Application Launcher, which can cause a crash.
- Managing login scripts sucks. The fewer commands you have in login scripts, the better. (And there's no login script like no login script.)
Novell has made it easy to use and administer Disconnected Mode. However, fact number 3 (from above) has a shortcoming. Fortunately, it is easy to fix.
The Launcher Configuration attribute "Auto-start NAL" puts the NALDESK.EXE shortcut into the current user profile instead of the All Users' profile. Because it uses current user, only a single user will get the benefit of the Auto-start at that workstation. Other users on that same workstation won't get the Application Launcher automatic start unless you're starting the Application Launcher from a Login Script.
Putting the NALDESK.EXE shortcut in the All Users Start menu is a much better method for enabling the Application Launcher to auto-start because it enables the Application Launcher for the whole workstation, instead of just the individual user. That means every user who logs in will get their applications delivered and won't need the login script to start the ZENworks Application Launcher.
You can use a three-pronged approach for enabling workstations with this shortcut:
For new workstations:
- Put the Application Launcher files and shortcut into your workstation disk images so all new workstations will be Application Launcher-ready from the get-go.
For existing workstations that have never run the Application Launcher before:
- Use a conditional login script command to run the Application Launcher once per workstation. Try a script strategy something like this:
#FIND /I "device" e:\winnt\system32\naldesk.exe
IF "%ERROR_LEVEL"="0" THEN BEGIN
(Truth be known, I did not test this script. It's meant just to give the idea.)
After you get your existing workstations Application Launcher-enabled, dump this part of the login script and deploy to new workstations when you image them.
To enable the Application Launcher to Auto-start on workstations that already have the Application Launcher files stored locally:
- Force-run an application that inserts the NALDESK.EXE shortcut in the All Users Start menu. An example AXT is shown in the sidebar.
By using this three-pronged approach, you can quickly enable workstations to use the Application Launcher for all users, eliminate your dependency on login script commands, avoid share-locking your Application Launcher files on the server, and start taking advantage of the Application Launcher's disconnected capabilities.
Example Application Template (AXT) for enabling a NALDESK.EXE shortcut in the All Users start menu. (Includes local workstation logging of who has launched the application.)
If you prefer to have the AXT file directly, get it from this link.
Value=Push NALDESK to All Users' Startup
Value=Push NALDESK to All Users' Startup
Value= 47 NULL
Flag=Not a Disconnectable Application
Link File Path=%*CommonPrograms%\Startup\NALdesk.lnk
Separate Memory Space=No
[Text File Add Begin]
Flag=No Reboot Needed
String=NALDESK.EXE shortcut was added to All User's Startup group by %FULL_NAME% on %MONTH%/%DAY%/%YEAR% at %HOUR24%:%MINUTE%:%SECOND%
[Application Icon Order]
[Application Association Flags]
[Application Version Number]
Chad L. wrote: I have a question in reference to Reverend Ted's application launcher autostart document. My users are used to seeing the NAL open with their applications displayed when they log in so I used nalwin32.exe instead of naldesk.exe.
I have put nalwin32.exe in the startup group and everything works fine.
My question is how do the local files that NAL copies to the workstation get updated if I am running nalwin32 or naldesk from the local workstation?
The way I understand it is these two files do not copy files they just launch the application launcher or explorer.
Do I need to run nal.exe on the workstations to up the workstations with new files after a service pack or patch is applied?
Reverend Ted: Two pieces to make sure you have:
First: the document was for ZfD 3.2. If you don't have that version, the files will not copy at all.
Second: NALDesk launches whichever interface you last launched. While it is true that NAL.EXE and NALEXPLD.EXE both are merely shell applications, in the 3.x versions of ZENworks for Desktops, they share common libraries. NALDESK therefore becomes a shell for the Application Launcher window, or for the Application Explorer shell extension. That means that the method described in the article will work just fine for you.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com