Unix, Linux and Macintosh Client Communication and Package Download Issues

Article:TECH46185  |  Created: 2009-10-26  |  Updated: 2014-02-06  |  Article URL http://www.symantec.com/docs/TECH46185
Article Type
Technical Solution


Issue



This article lists the known reasons for Unix linux and Macintosh (ULM) clients to fail to communicate, post events, download packages, etc. Some resolutions are provided in this document while others exist elsewhere in the knowledge base. Some resolutions are not specific to the ULM solutions but are more part of the general installation and configuration of the NS/SMP and package servers.

The issue can be manifest in several ways, including running the bootstrap or aex-swdapm commands from a shell prompt on the clients. The error messages may vary slightly. Other symptoms may not be readily apparant.

Note: This document should be used as a central repository of causes and resolutions for this issue.

 


Environment



Notification Server 6
Symantec Managemement Platform 7

Inventory Solution for Unix, Linux and Macintosh 6.x 
Inventory Solution for Unix, Linux and Macintosh 7.x.

* Other ULM solutions may be impacted by these issues.


Cause



See below.


Solution



NS and Client Configuration Issues:

·        Clients cannot resolve the name of the package servers and/or site servers.

 

·        Package and policy are corrupt on the NS.

o   Delete the existing package & policy on the NS and recreate them.

 

·        The date and time are incorrect on the NS or the client.

 

·        Clients are downloading via HTTP rather than HTTPS.

o   Rebuild codebases to change the urls from http to https.

o   Reinstall or reconfigure the ULM agent to use https. This is specified in the NS server name/url entry of the .aex-agent-install-config.xml, as a command line parameter to aex-bootstrap* or at the server name prompt of the utility 'aex-configure -iconfigure' prompt. 

 

·        Codebase and/or snapshots are stale on the NS

o   Rebuild/refresh packages, snapshots, codebases, etc. This may need to be done in a variety of similar situations.

 

·        Client codebase files only contain a UNC path.

o   Client codebase are found in the …/nsagent/var/packages/<guid> directory. The file names begin with a ‘.’ and are hidden.  Doing ‘cat .aex-pkg-codeb…’ will display the contents of the package codebase. It should contain both http and file entries. If not, the NS needs to be configured to allow http codebase entries, etc.

 

·        Client codebase files contain an invalid NS server name.

o   Check the registry on the NS for the PreferredNSHost value. See https://kb.altiris.com/article.asp?article=46940&p=1.

 

·        The package was configured to specify package servers individually but no package servers are specified.

o   In the ‘Package servers’ tab of the package configuration screen, either select another option, e.g., ‘All Package Servers’ or spcify one or more package servers. Otherwise, clients will download an incomplete codebase file.

 

·        Client proxy settings are blocking connections and/or traffic.

o   This is often related to an error in the log files similar to “Failed to get package {} snapshot.Error=-2147413111”. The ULM agent 6.x release notes state:

“If the environment variables all_proxy, ftp_proxy and http_proxy are set to a proxy server that cannto reach the Notification Server, you can get the following message “HTTP attempt returned -214741311’ Failed to connect to the specified URL’”. In this case, either do not use a proxy server or make sure that the proxy server can access the Notification Server.

o   Configure a no_proxy setting for the subnet on the client computer in order to allow traffic and to bypass other (perhaps, dmv) proxy.

 

·        ISA and VLAN server configuration.

o   These need to be configured to allow connection to <NSServer>:80 (or the currently configured port#).

 

·        Environment configuration.

o   The environment configuration includes things such as firewalls, port restrictions, group policies, etc. Anything that can restrict communication can be a contributing factor.

 

·        ULM client log error: No package sources returned by server.

o   The following KB articles may applyl: 27161, 39881, 45069, 20487, 32550, 20207.

 

·        Clients display the following error: “Package download failed because package was removed”.

o   This seemed to be resolved by disabling windows authentication in IIS for this package.

 

·        NTLMv2 is not supported. (Note: this is supported in 7.5.). To resolve the issue on the 7.1 platform, try any or all of the following: 

o    Disable Windows Authentication for IIS virtual directories being accessed.
o     Configure the NS/SMP to use SSL/HTTPS. 
o    Move the localhost or server name URL from the Trusted zone to the Local Intranet zone .

 

 

 

 

Authentication Issues:

·        The application identify on the Notification server has been locked down.

 

·        Anonymous access is not enabled on the IIS package directory(ies) being downloaded.

 

 

·        Clients are trying to download with credentials that the package server does not recognize.

o   Uncheck IIS virtual directory ‘Windows Authentication’ for the package. The credentials are stored on the client in the client.conf file’s pkg_access_username and pkg_access_password fields.

 

·        One or more clients are using old credentials causing the service account to be locked due to login failures.

o   Identify the culprit client machines and refresh policies or uninstall and reinstall the agent.

 

·        Clients get NS server credentials which do not exist on a package server.

o   Create identical app identity credentials on package servers as exist on the NS.

 

·        IIS virtual directory is set to use Windows Authentication.

o   Uncheck IIS virtual directory ‘Windows Authentication’ for the package(s) being downloaded.

 

IIS Installation and Configuration Issues:

·        IIS has not been installed on the package servers.

o   All ULM client communication is done via http/https. Therefore, a web server is required.

 

·        IIS was installed on the package server AFTER the PS Agent was installed.

o   In this case, the PS agent installation process did not create required virtual directories. There are ways to have these created afterward or the PS agent can be uninstalled, then install IIS, then reinstall IIS.

 

·        IIS virtual directory for the package being downloaded does not exist.

o   There are a few cases where the directory was not created properly. The package can be recreated in the NS console or perhaps the virtually directory can be manually created.

 

·        An incorrect version of asp.net is in use in IIS.

 

·        The asp.net web extension is not allowed in IIS for this web site.

 

·        Mime types in IIS. Errors related to this are similar to: "Failed getting Package, Msg: HTTP server returned an error, 500, http://mynsserver.com/Altiris/NS/NSCap/Bin/Unix/Agent/Mac/Universal/agent-upgrade\

HTTP/1.1 500 Internal Server Error\".

 

o   Add ‘.asp’ as a mime type in IIS.

o   Remove ‘.’ (dot/period) as a mime type in IIS.

 

·        Windows authentication for the package is enabled.

o   Disable or uncheck the ‘Windows authentication’ option for the package(s) being downloaded on both the NS and on any package servers.

Note: for all authentication and IIS issues, it is helpful to check the IIS logs on the package server. 400 series errors indicate authentication/security issues.

 

Other:

 

·        Intrusion detection or other security software is blocking traffic from the client machine.

 

 




Legacy ID



49809


Article URL http://www.symantec.com/docs/TECH46185


Terms of use for this information are found in Legal Notices