NAL File System Access in an Agent-Only environment
Novell ZENworks for Desktops 4 - ZFD4
Novell Application Launcher (NAL)
Error: "Could not launch <application_name> (using <path_to_network_file) (id=5). Access is denied."
Error: "Could not launch <application_name> (using <path_to_network_file) (id=51). Windows cannot find the network path. Verify that the network path is correct and the destination computer is not busy or turned off. If Windows still cannot find the network path, contact your network administrator."
Error: "Problem: Install Failed. MSI returned error code: 1612."
Since the introduction of ZENworks for Desktops 4, Client32 is not required to reside on the workstation. This has posed several questions from Administrators as to the rules they need to abide by when developing NAL application objects in a clientless environment. The following guidelines should be kept in mind when developing the file system access strategy in your application objects.
MSI application object distribution
The workstation will try to access the source path listed in the application object. This path could have been a mapped drive or a UNC path. If the path could be accessed, the application will be delivered without the use of the MiddleTier for file system access. If the path cannot be accessed, then a request to the MiddleTier will be made. The MiddleTier is then used to Force Cache the application to the workstation, and then the MSI application will be installed from C:\NALCACHE\<TREE>\<DN of APP>\Install.
There are a few important facts in this behavior:
>If the Source Path is a mapped drive, no attempt to resolve the path will be made through the MiddleTier (as the MiddleTier will not have the user's drive mappings).
>Before a Force Cache of an application will occur, one of two criteria will have to have been met: the associated object has the Force Cache association inside the NAL app, or the access mode of the logged in user was determined to be Remote. If Remote mode is determined, Checkpoint Restart will automatically force cache the application, therefore not requiring the Force Cache association. The Remote Access Detection is configured in Launcher Configuration.
>If the MiddleTier is a NetWare server, and the middletier will be used for file system access, then the source files for MSI applications must reside on a NetWare box. This is because there is no CIFS client on the NetWare middletier server to access Windows servers with.
>If the MiddleTier is a Windows server, and the MiddleTier will be used for file system access, then the source files for MSI applications can reside on either a Netware server or another Windows server.
AOT application object distribution
If the source path listed contains a drive letter, then the workstation will try to use that mapping when retrieving the files. If that mapping is not available from the workstation (ie- outside the firewall), then an attempt will not be made to access the files through the middletier - as the middletier cannot be expected to know what the mapping represents.
If the source path listed contains a UNC path, then only the middletier will be utilized to access the file system.
There are a few important facts in this behavior:
>The AOT application object is not required to be Force Cache when accessing it throught the middletier.
>If the MiddleTier is a NetWare server, the Source files for AOT apps must reside on a NetWare server. This is because there is no CIFS client on a NetWare box to access a Windows server with.
>If the MiddleTier is a Windows server, the Source files for AOT apps can reside on either a NetWare server or a Windows server.
Launching an application through a NAL app object
If the application object is configured to run a program from the network (in the Run Options - Application tab, Path to File line), then the workstation must have CIFS access to the network path (by default CIFS doesn't cross a firewall). The source location can reside on either a NetWare server (configured with CIFS) or a Windows server. There will be no attempt to run a program through the MiddleTier. If you are trying to launch (for example) a SETUP.EXE from a network location, and you don't have direct access to that network location (which means you are depending on file access through the midtier), then your strategy would change to copying the install program to the local machine and launching it from there. A firewall will prevent a workstation with CIFS from accessing the network resource with the file (ex: SETUP.EXE) and the solution will also be to configure the application to copy the install program to the local machine and launch it from there. Keep in mind that you can use the "Uninstall if not used within x days" feature to get rid of programs you copy down for the purpose of launching.
File System rights used
The associated object (user or workstation) has to have the file system rights to the Source Path on the network. However, if it's associated to the workstation object, then the workstation object will need to be granted File System rights to the NetWare Source Path. If the Source Path is a Windows server, then NULL Session Shares will have to be allowed (see Microsoft article 289655) if the workstation is not a member of the domain. If the workstation is a member of the domain in this scenario, then the computer account must have share and NTFS permissions to the source path. However, if an application is associated to the workstation object, and file system access is coming through the middletier, then the credentials used for file system access will be the Proxy user credentials found in HKLM\Software\Novell\Xtier\Configuration\XSRV\LMAUTH if the source files reside on a Windows server.
ZENworks Desktop Management 6.5 and 7 work slightly differently when accessing files - search the documentation for ZENMUP