[Intel Navigation Header]

    LANDesk(R) Management Suite v2.x: Distribution Usage Tips

    Contents:

    • CONTENTS
    • SOFTWARE DISTRIBUTION PACKAGES CAN ONLY BE CREATED ON AND DISTRIBUTED FROM THE SYS: VOLUME
    • "SD3060: NO PATH MACRO ASSIGNED TO DRIVE. CREATE A MACRO AND REBUILD THE PACKAGE"
    • DISTRIBUTION STILL WAITS FOR STEP 2 AFTER AN ABNORMAL END TO A PACKAGE CREATION
    • "CALL TO UNDEFINED DYNALINK" OR "BLACK SCREEN OF DEATH"
    • PROBLEMS TRACKING A WINDOWS* RESTART
    • "ERROR LANS011: INVALID TEMPORARY PATH" OR UNABLE TO LOAD POPUPTSR /T=SELTEMPBEFORE LOGIN IS RUN
    • HOW TO AVOID BUILDING INCOMPLETE PACKAGES
    • |COULD NOT CREATE/OPEN TEMP FILE|
    • "CAN'T SPAWN WINDOWS C:\WINDOWS\WIN.COM"
    • "DATABASE ERROR: KEY NOT FOUND"
    • DISTRIBUTE COMPLAINS ABOUT INSUFFICIENT RIGHTS
    • INSTALLING FILES NORMALLY HIDDEN FROM SNAPSHOT
    • DISTRIBUTION: TROUBLESHOOTING TIPS
    • MANAGING A LARGE NUMBER OF PACKAGES
    • WHY IS A JOB REPORTED AS |IN PROGRESS| FOR SEVERAL DAYS, NEVER CHANGING TO |COMPLETED|?
    
    

    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