![[Intel Navigation Header]](/CONTENT/PIX/HEADER.GIF)
LANDesk(R) Management Suite v2.x: Distribution Usage Tips
Contents:
CONTENTS
This document discusses common Software Distribution issues. It
supplements the files in LANDesk(R) Management Suite's Readme Viewer.
SOFTWARE DISTRIBUTION PACKAGES CAN ONLY BE CREATED ON AND DISTRIBUTED FROM THE SYS: VOLUME
Software Distribution In LANDesk(R) Management Suite creates application
packages in the SYS:LOGIN/LANDESK/LANSD/PACKAGES directory. Packages
will be created in and must be distributed from this directory. This is
not configurable. If you wish to keep an application package for use in
the future, and want to save space on the SYS volume, copy the entire
directory containing the package to another volume, local hard drive or
file server. When you want to distribute it, copy it back to the SYS
volume and refresh the package view.
If you want to distribute a package from different Management Server,
you can copy the entire package directory to the new server, run the
Management Console from that server and execute the distribution. You
must be logged into and running Software Distribution from the server
you are distributing from.
Moving packages from one server to another applies to application
packages only, not file collection packages. It would work with a file
collection package only if the files themselves were moved into the same
directory structure on the other server and properly macroized. If you
distribute file collection packages once, a DAT file (compressed version
of the files) will be generated that could be copied to the other
server. In this case the files should be correctly distributed but an
error will still be generated that the files were missing - a fresh
version of the files wasn't available so it used the stale .DAT file.
"SD3060: NO PATH MACRO ASSIGNED TO DRIVE. CREATE A MACRO AND REBUILD THE PACKAGE"
LANDesk(R) Management Suite v2.x
Error message:
SD3060: No path macro assigned to drive. Create a macro and rebuild the
package.
Description:
The script for the distribution package contains a drive letter or UNC
path that does not have a macro assigned to it in the default
personality file (BASE.PER) or local personality file (ADMIN.PER). This
reference may have been to a directory actually containing a changed
file, or it may simply appear in a modified text file.
Solution for file Collection Packages:
If the package is a File Collection Package, this error indicates that
files have been selected from a path that is not macroized. In this
case, the error can be easily found from the interface, since it is in
the .DF file. Simply select the package and chose Package|Edit
Distribution Control File. Use the "Find" button to search for "Error".
You should see the word "Error" highlighted under the AddedFiles
section, and right above it will be a path for which a macro was not
provided. Search for any other errors, noting the paths that need
macros. Add the needed macros to the personality files (see below), and
rebuild the package.
Solution for Applications Packages:
If the package is an Applications Package, this error may indicate one
of two things:
* Changes were made in a text file that references a non-macroized
drive. An example is an entry in WIN.INI that references
F:\WIN\USER, where F: has no macro assigned to it. Editing the
package, under the ModifiedTextFiles section, you will see a
reference to a drive letter, such as "F:". The existence of this
drive letter (and not a macro) indicates an error, but the word
"Error" will not appear, so the error is not easily found here.
Alternatively, you can open the file
SYS:\LOGIN\LANDESK\LANSD\ADMIN\<PACKAGE_NAME>.LOG, and search on
"Error", and this same error will appear with the error message.
Again, an appropriate macro must be created for each of these
drives (see below). Choose Package|Remove Local Installation to
restore the workstation configuration, delete the package, and
rebuild it.
* Changes were made to a drive for which macros do not exist. The
most likely case here is that the user is scanning a network drive
and has not created a macro for it. An error may not appear here,
but if the package is edited (from the interface) and UNC paths
exist, a macro should be written (see below) and the package
rebuilt.
ASSIGNING MACROS TO DRIVE LETTERS OR UNC PATHS
Having found the drive letter that requires a macro, go into the
Distribute interface to define the drive letter macro in both the
Default and Local personality files (renamed in the next release to Base
and Administrator, respectively). From the main screen in Software
Distribution, choose Network|Personalities|Default, choose Insert, and
enter something like TEMPDRIVE=L:\. Do the same under
Network|Personalities|Local.
Having found the drive letter path that requires a macro, go into the
Distribute interface to define the path macro in both the Base and
Administrator personality files. From the main screen in Software
Distribution, choose Network|Personalities|Default, choose Insert, and
enter something like TEMPUNC=\\SERVER1\SYS and TEMPDRIVE=L:\. Do the
same under Network|Personalities|Local. You should enter both a UNC
macro and a drive letter macro for each network location that might be
considered.
DISTRIBUTION STILL WAITS FOR STEP 2 AFTER AN ABNORMAL END TO A PACKAGE CREATION
LANDesk(R) Management Suite v2.x
Symptom:
If during the creation/installation of a new package you decide to abort
the installation, Software Distribution still expects to run STEP 2 to
complete the package building process. Even if you exit Software
Distribution and re-open it, Software Distribution will show the
half-built package. You may want to clear it from the package list.
Solution:
If for some reason STEP 2 cannot be completed, you must manually delete
any files and directories created in the package building process.
* In the LANDESK directory, delete the file called <PACKAGENAME>.PRM.
* In the LOGIN\LANDESK\LANSD\PACKAGES directory, delete the
subdirectory named <PACKAGENAME>.
"CALL TO UNDEFINED DYNALINK" OR "BLACK SCREEN OF DEATH"
This condition appears in LANDesk(R) Manager Suite v2.0 when the
NetWare* (VLM, NETX)/ Windows* (DLL) drivers on a workstation are from
mismatched sets. A complete matching set could only mean that you have
installed all 3 sets of drivers: VLMUPx.EXE or NET33x.EXE, WINDRx.EXE,
and NWDLLx.EXE, where x is the same number for all sets. These drivers
are available on the LANDesk CD-ROM in the \NWCLIENT\DOSWIN directory.
When Microsoft Windows looks for DLL files to load, it searches the
WINDOWS directory before the WINDOWS\SYSTEM directory. Look for
mismatched NW*.DLL files in the WINDOWS (not SYSTEM) directory or
elsewhere in the search path.
For example, this error appeared when the following files were found in
the WINDOWS directory:
NWCALLS.DLL 5-18-93
NWNETAPI.DLL 5-18-93
NWIPXSPX.DLL 5-18-93
NWLOCALE.DLL 5-18-93
NWPSRV.DLL 10-20-93
Other ways to indentify the error:
After the "call to undefined dynalink" error, you may get a General
Protection Fault.
After you exit Microsoft Windows, the error "Emm386 error #06 in an
application at memory address 00b8.0bcflTo minimize the change of data
loss, EMM 386 has halted your computer. For more information, see the
README.TXT file. To restart your computer, press ENTER."
PROBLEMS TRACKING A WINDOWS* RESTART
Symptom:
If the installation of an application asks you to restart Windows* to
complete the installation, the PC may hang; the next time Distribute
runs, it prompts, "Corrupt package, delete?"
Solution:
To avoid this, terminate the installation of the software at the point
that it asks if it can restart Windows. Close your Windows applications
including Distribute, close Windows, follow the software directions on
what to do manually while in DOS. Restart windows and run Step 2.
Remember that Software Distribution will track any changes made to the
PC between Steps 1 and 2 whether part of a package installation or not.
Before Step 2, you can do any further manual "adjustments" you desire,
regardless of the tool you use to make the change (for example, setting
FILES=80 in CONFIG.SYS could be done with EDIT.COM, NOTEPAD.EXE,
SYSEDIT.EXE, etc.).
Whenever Distribute is ready for Step 2, you can close Distribute. Next
time it launches, it remembers where it was and is still ready for Step
2. Therefore, you can specify a "dummy" installation command that
terminates immediately, such as "PROGMAN.EXE". You can now close down
Distribute and the Windows session and do the installation. When the
installation and any other changes you desire are done, launch
Distribute and run Step 2.
"ERROR LANS011: INVALID TEMPORARY PATH" OR UNABLE TO LOAD POPUPTSR /T=SELTEMPBEFORE LOGIN IS RUN
LANDesk(R) Management Suite v2.0x
Symptom:
Error message:"Error LANS011: Invalid temporary path" or Unable to load
POPUPTSR /t=SELTEMP before LOGIN is run
Description:
POPUPTSR requires sufficient rights to store a temporary file during DOS
workstation processes like chat, file transfer, and software
distribution.
When POPUPTSR.EXE tries to load before a workstation is logged into a
file server, it checks to see if the temporary file can be stored in a
default location (SYS:\LOGIN\LANDESK unless the
/t=SYS:\LOGIN\LANDESK\SELTEMP switch was used). Because the users
aren't logged in yet, the check for write privileges fails, and POPUPTSR
checks the DOS environment for a TEMP=DIRECTORYNAME setting. If one
does not exist, POPUPTSR cannot load and this message appears.
Solution:
Create a DOS setting TEMP=C:\ (or another existing directory where the
workstation can write files) or load POPUPTSR with the /t=DIRECTORYNAME
option. For example, POPUPTSR /t=C:\ or POPUPTSR /t=C:\TEMP.
HOW TO AVOID BUILDING INCOMPLETE PACKAGES
LANDesk(R) Management Suite v2.x
To build complete packages effectively, use a clean Windows* environment
on the workstation you use to build packages. To avoid any pitfalls
associated with a "dirty " Windows install, see Hint #3 of the Software
Distribution readme text (SDCONSOL.TXT).
|COULD NOT CREATE/OPEN TEMP FILE|
LANDesk(R) Management Suite v2.0x
Symptom:
Error message:*Could not Create/Open temp file,* when distributing to a
workstation *not-logged-in*
Description:
When you attempt to PUSH a distribution to a user, POPUPTSR tries to
create a file in the directory specified by POPUPTSR /t=DIRECTORYNAME.
If POPUPTSR is pointing to a network drive (default) and the workstation
is not logged in, you will encounter this error.
Solution:
For NetWare* 3.x servers, edit LD_LOGIN.DAT to change the command line
parameter for POPUPTSR to a local path instead of the default network
path. This parameter is the path for a temporary file.
For NetWare 4X servers, you must load the TSRs locally. For users who
require this feature, you will need to change the system login script
and load POPUPTSR and USERTSR from a local directory that contains the
following files.
POPUPTSR EXE
USERTSR EXE
LANMENU PIF
LANMENU OVL
LANMENU EXE
LANMENU BIN
LANMENU DAT
It may also be necessary to have a subdirectory that contains the
unicode tables:
NLS <DIR>
"CAN'T SPAWN WINDOWS C:\WINDOWS\WIN.COM"
Error message:
"Can't spawn Windows c:\windows\win.com" even though the directory and
file exist.
Solution:
Make sure the Target Workstation has sufficient memory. It should have
at least 530 KB before entering Windows*.
"DATABASE ERROR: KEY NOT FOUND"
Error message:
Database error: key not found
Description:
The error message means that the LANDesk(R) Management Suite v2.01x
software distribution database is corrupted.
Solution:
To resolve this:
1. Change to the \login\landesk\lansd\database directory.
2. There should be six files in here (gta.reg, gta.lnk, gta.dat,
lansd.reg, lansd.lnk and lansd.dat) delete all six files. The next
time you restart the software distribution database these files
will automatically be created.
DISTRIBUTE COMPLAINS ABOUT INSUFFICIENT RIGHTS
Symptom:
The user being distributed to is a member of the LANDESKGROUP but
Distribute complains about insufficient rights.
Description:
This may be a NetWare* 4.x issue. The user is logged into the server
with a bindery connection and LANDESKGROUP is an NDS object so
Distribute can't grant rights to the user.
Solution:
Make sure that user you want to distribute to is logged in to the tree
and has a NDS context (full distinguished name).
INSTALLING FILES NORMALLY HIDDEN FROM SNAPSHOT
The Snapshot technology used by LANDesk(R) Management Suite v2.01x
Distribute is vulnerable to the following problem: a file that already
exists on your workstation before the presnapshot and then installed by
an application's setup program will not be detected if the new file is
exactly the same as the old one. The file will also be missed if the
application does not install its file because a newer one exists on the
workstation. This problem cannot be completely avoided by trying to
keep the workstation clean since LANDesk Management itself uses a few of
these common files.
The problem can be completely avoided if a separate, clean Windows*
installation is used exclusively for package building. This
configuration is especially recommended when distributing large
applications to new PCs that do not have any existing software
applications.
1. Install Windows to your management console in a different directory
than your existing Windows installation. This installation should
be absolutely minimal. Choose a customized setup that does not
configure your pre-existing Windows applications or install
printers. Don't allow the setup to modify your system files.
2. Add the following lines to the WIN.INI of the minimal Windows:
[CoreServices]
ClientDomain=<Your Management Server Name>
3. Modify the PATH statement in your AUTOEXEC.BAT to include your
previous Windows SYSTEM directory (the previous WINDOWS directory
should already be included).
4. After rebooting to allow the path change to take effect, change
directory to the minimal Windows directory and type "WIN" (be
sure to change to the correct Windows directory when you type WIN,
otherwise, DOS will default to the first directory in your path
that contains a WIN.COM).
5. Create an ICON for <Network Drive>:\LANDESK\SDCONSOL.EXE
6. Edit <Network Drive>:\LANDESK\SDPKG.INI and change the values for
windowsDir and WindowSystemDir (found at the end of the file) to
point to your minimal Windows directory.
7. Launch SDCONSOL.EXE. Edit the Administrator's personality file.
Change the WINDOWS macro to point to the minimal Windows directory.
When you are building critical packages, use your minimal Windows
installation. Remember to remove these packages from your workstation
after they are built. All other Distribution (and LANDesk Management)
tasks can be performed from your original Windows installation.
DISTRIBUTION: TROUBLESHOOTING TIPS
LANDesk(R) Management Suite v2.01x
Complicated/Misunderstood Features: Personality Files and FILEFLT.INI
Personality Files
Those who are new to LANDesk typically have a hard time with the
Personality Files. The purpose of these files is to provide the
flexibility to install packages in a variety of different environments.
The Administrator Personality File reflects the environment of the
computer building the packages.
Note: If there are multiple administrators using this, it might have to
be changed each time, depending on the drive mappings of the
administrators.
The Default Personality File (called "Base" in v2.01) is meant to
reflect the environment of the majority of the targets. If there are
exceptions to this default environment, the targets need a Target
Personality File. If a Target Personality File exists, its macros can
override the Base Personality File. The Base Personality File is
inserted into the package at build time and becomes a static part of
that package. Making changes to the personality file after the package
is built will not affect the package behavior. You must either edit the
package, put the desired changes into the Target personality files to
override it, or edit the Base Personality File and rebuild the package.
The Master Target Personality File (called "Target Template" in v2.01)
is a template used to create the Target Personality Files. The Master
or Target Template is never used; it's just copied into Target
Personality Files. In v2.0 there is a problem with distributing the
Master Target Personality File: the dialog to do so only allows the
file to be distributed to users currently logged in to the Core Server.
This is fixed in v2.01, which uses the Netmap View to select targets for
this file.
The Target Personality File, as stated above, is for the "exceptions to
the rule" of the base. In a homogenous environment, this file might
never be used.
FILEFILT.INI:
While the Distribute interface may appear simple, don't ignore this
file; it needs to be read and possibly customized. Specifically, you
may need to:
1. Filter out unwanted files created or changed between snapshots. An
example of this is the file WINFILE.INI. This file may be
unintentionally modified by a user who is manipulating files between
snapshots. It may also cause a non-macroized drive error if network
directories are used. I added to my FILEFILT.INI the temporary files
generated by SQA Robot, since they would otherwise be distributed to
targets when I ran my automated tests.
2. Customize Backup Directories. FILEFILT.INI comes preconfigured with
these lines:
windowsDir=c:\windows
windowSystemDir= c:\windows\system
These lines will attempt to back up these two directories during a
package build, to help the administrator back out if his Windows* files
are modified. Unfortunately, the first thing some users will see when
they build a package is an error dialog indicating that these
directories don't exist. If they have Windows installed to any other
directory, we hope they will see our initial Welcome dialog and modify
these entries before they build a package.
Generating a Package Without a Setup Application
Distribute's interface seems to imply that the only way to build an
Application Package is by running an applications setup program. In
fact, all changes between the snapshots are detected, whether they made
by the launched setup application or by hand. The most convenient way
to begin a hand-crafted package is, when the dialog appears to choose
the setup application, choose either DOS or select a Windows program
such as WINFILE or PROGMAN. Then make the desired changes before
choosing Step 2.
Alias Name Files
Most users quickly notice that we currently have no support for NetWare*
Groups. Make sure they are aware that the Alias Name File feature can
serve a similar purpose. These files are shared between Distribute and
Desktop Manager.
Backup Directories
Contrary to what is stated in the manual, the location of the
administrators backup files cannot be changed. Using the FILEFILT.INI
features described above, the administrator can control which of his
directories are backed up. The target's backup location can be changed.
These backups are typically small since they consists only of those
files which are overwritten by the other files of the same name. By
default, we back them up on the server. The administrator can change a
personality flag and a drive macro to cause these to be backed up on the
targets themselves.
Multiple Server Issues
1. Staging Server
This feature is not fully implemented, but would eventually allow for a
package created at one server to be sent to a number of other servers as
a package, where it could then be scheduled by other administrators for
distribution to the clients that they manage. This is the extent of our
current support of this feature: Distribute has "self detecting
packages". That is, packages that are added to or removed from the
appropriate directories will be detected by Distribute as valid
packages, regardless of whether or not they were created by this
console. The important thing here is that the entire package directory
structure (default \LOGIN\LANDESK\LANSD\PACKAGES\PACKAGE_NAME) must be
entirely copied to the new server. It is not possible to change the
name of the package's directory since the .DAT file (where the
compressed files are stored) will contain this directory name.
Note: This same feature helps us to archive packages. Currently,
Distribute only allows packages to be stored on a single volume, under
the shared directory. Many of our customers have complained about this,
since their disk space is limited. Our only current work around is that
they move unneeded packages to other volumes for safe keeping. When
they are needed again, they can move them back into their proper
directory structure, and Distribute will detect these packages and be
able to use them again.
2. Distribution Directly to Servers.
Again, this feature is only partially supported. Distribute currently
offers only a client-based distribution, but provides an awkward
workaround to distribute to servers. The key features that Distribute
offers in this area is package building, specifically, the ability to
scan network drives and parse changes to AUTOEXEC.NCF. We do not
currently detect changes to the bindery (an application, like LDMS, may
create new groups or users, or other bindery objects, which Distribute
would not detect). Clever manipulation of personality files can then
deliver the package through a client to a server. There is no means
deliver the package directly to a server.
Note: Selecting a server using the Netmap View will deliver the package
to all expanded clients of that server.
A. Personality Files
(Also Important for client-based distributions where the package source
is a server, such as a file collection package that transfers files from
a server to targets.)
The key to any distribution to a server is the drive macros in the
personality files. They must be properly configured before the package
is built. Unfortunately, the drive macros setup is not the same for
File Collection Packages and Application Packages.
1. File Collection Package Example
File collection packages require drive letters in macros. Suppose our
task is to copy the Distribute package files from Management Server A,
directory S:\login\landesk\lansd\packages\word60, to Management Server
B (the hoaxed staging server method described above). Suppose we have a
target who has necessary rights and maps G: to Management Server B.
Server B has a different directory structure and stores the files in
\login\admin\landesk.20\lansd\packages (Word directory does not yet
exist). We would create the following macros:
Administrator: PACKAGE=S:\login\landesk\lansd\packages
Base/Target: PACKAGE=G:\login\admin\landesk.20\lansd\packages
Note: If the directory structures had been the same, the macros could
have consisted of only the drive letters.
Build the File Collection package as usual. The macros will replace the
references to physical drives. When distributed to the target, he would
copy the files to his PACKAGE directory, which points to the desired
LDMS server.
2. Application Packages Example
Unlike File Collection packages, Application Packages require the UNC
path, instead of drive letter, in the macro. So, given the above
example, we might have
Administrator:
PACKAGE=\\SGW_402\SYS\login\landesk\lansd\packages
Base/Target:
PACKAGE=\\RAC_312\login\admin\landesk.20\lansd\packages
Don't forget to go into preferences and add the desired network drive to
the scanned drives. You can take out 'C:' to speed things up, but you
will get a series of error dialogs warning you about not backing up your
Windows directories.
B. To Multiple Servers
Typically, this limited server support will not be useful to customers
that plan to distribute to a large number of servers. This can be done,
but would consist of repeatedly distributing the package to the same
target, each time either changing its drive mappings or changing the
macro in its Target personality file so a different server would be
selected. In most cases, copying the files by hand would be easier.
C. Same Server, Multiple Directories
There might be some application here for our feature. In an environment
where Windows is running on the network, and each user has files stored
in a subdirectory under his login name, Distribute might be useful. In
this case, a personality file would have to be created for each user.
Then, multiple Windows applications could take advantage of this
personality file and be distributed to the proper user directories.
Problems and Bugs
These are well documented in the readme file (SDCONSOL.TXT).
Of particular concern:
Connection Limit
No DOS Pull.
Licensing broken
2.01 Changes
Nomadic Users
MANAGING A LARGE NUMBER OF PACKAGES
Tech note: Versions of Distribute through at least LANDes(R)
Management Suite v2.01 have the limitation of requiring all packages to
be stored on the SYS: volume, in the directory
\\{SERVERNAME}\SYS\LOGIN\LANDESK\LANSD\PACKAGES.
The following solution may be helpful in managing a large number of
packages:
Distribute uses a "self-identifying" package technology that allows
packages to be moved to other locations and later re-identified by
Distribute. If there is sufficient space on another volume, unused
packages can be moved to that volume. Later, when the packages are
needed again, they can be moved back to the package directory. Either
re-invoking Distribute or selecting View|Rebuild from the Distribute
Console will cause these packages to be appear in the package view.
Precautions:
* Packages should be treated as entire directories. They should be
copied as directories and not as the files that comprise them. In
this way, the name of the directory remains unchanged. Changing
the name of a package directory will cause a number of failures, so
it is important that it be restored as the same directory name.
* A package should never be moved if it there are still targets that
require it. To determine if this is the case, go into report, view
the Distribution Status, filter on Package, and view the log to see
if there are any jobs with status "Pending" or "In Progress". "In
Progress" typically means that a job is actually executing; it must
be allowed to complete. "Pending" typically means that the job is
scheduled for the future.
If the job was scheduled for Pull to a specific target and the
package is moved or deleted, WSDPULL will GPF upon invocation on
that target.
Note: The same concept can be used in copying core to core as long as
the directory structures remain the same.
WHY IS A JOB REPORTED AS |IN PROGRESS| FOR SEVERAL DAYS, NEVER CHANGING TO |COMPLETED|?
"In Progress" means only that the job was initiated on the workstation.
If a job gets the status "In Progress," but the workstation was somehow
disrupted and not allowed to complete and report back, Distribute can
only discern that the job started and was not completed (not necessarily
that it is still going).
Trademark information