Video Screencast Help

NSClient and Linux?

Created: 07 Apr 2010 • Updated: 06 Jun 2010 | 9 comments
kristopherjturner's picture
This issue has been solved. See solution.

Can anyone lead me to some information on what the NSAgent can and can't do running on Fedora 12?  We are pushing out the agent to about 2000 Fedora systems and would like to know what limitations the Linux client has?

Comments 9 CommentsJump to latest comment

mclemson's picture

Have you seen the support matrix?  It doesn't mention Fedora 12 specifically, but it does give a breakdown of specific features in CMS 7 SP2 by OS family (Windows, Mac, Linux).

No or partial functionality for:

  • DeployAnywhere
  • PCTransplant
  • Standalone inventory
  • Application metering and blacklisting
  • File/registry baselines
  • pcAnywhere console software or access server
  • RTSM
  • All of Software Management solution, except it will run Quick Delivery Tasks (managed delivery cannot evaluate detection rules or virtualize)

You can view the spreadsheet here:

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner

jjesse's picture

mcclemson mentions the support matix which doesn't mention Fedora at all.  Red Hat is, but not the free version Fedora.  One gotcha when installing is you can't let the system auto-detect what version of Linux it is runing, you will have to force it to pick a version.  This version of OS is what will show up in your reports if I recall correctly.  So your machines might not report as Fedora as the OS Name.

Also Patch Management won't work for you.  CMS 7 supports patching of Red Hat and SUSE linux, not Fedora.  So you will have to use some other process  to patch the systems, maybe software delivery jobs?????

Good luck

Jonathan Jesse Practice Principal ITS Partners

kristopherjturner's picture

Another dumb question.  Sorry.  Not a Linux guy so this is fun.  We have 3000 laptops and desktops that we are going from Windows to Fedora 10 right now. (Can't get a good image from Fedora 12 that works)

How do we verify the client is running?  I have it enabled to show the client but where does that icon show up?  How do we launch the Client GUI in Linux?

cnpalmer75's picture

As far as I am aware there is no GUI based client for any of the *nix OS's. Here is what I've put together for helping others troubleshoot around here for agent commands within *nix... hopefully this helps!

The first is directly form the KB. I got tired of searching for it so I made my own local doc to hand out.
The second is a doc I wrote to help troubleshoto agent health etc.

Altiris Agent UNIX Command Line Parameters.doc 66 KB
Troubleshooting Altiris Agent for UNIX.doc 37.5 KB
jjesse's picture

Ben is correct, there is no GUI for Unix/Linux/Mac.

The Linux agent is installed in /opt/altiris/ntofication/.  Under the nsagent bin folder is where you will see the specific agent commands for troubleshooting.  Under the ctagent directory you will find the commands for troubleshooting task server.

Drop me a note with further questions

Jonathan Jesse Practice Principal ITS Partners

Andrew Bosch's picture

There is an Altiris Agent GUI on Windows and on the Mac.  There is NO agent GUI on UNIX and Linux.

Sr. Principal SQA Engineer

kristopherjturner's picture


Here is a good one.  Our team that is putting together our Linux image, we have 3000 systems we are taking Windows off of and moving to Fedora.  Anyway, our team went ahead without more instruction from me and installed the NSAgent on the image they just finished.  I was told they would deploy the agent as a start up script but they changed their minds.  However, now there has been about 500 machines imaged and they all show up once as the imaged machine name.

I found the GUID file and tested a box and removed the file and even uninstalled and reinstalled but the machine never reports back to the NS server.  Even when I run the inventory and update config commands manually.  It says it was successful but it wasn't't.

What can be done?  We do have the firewall enabled but I opened the ports on my test box.  I also disabled the firewall on my box and the system doesn't't report back.

In fact, I have noticed that all my Linux systems have only reported just once, even the one's I pushed the client to.

Any ideas?

cnpalmer75's picture

If you are finding that the agent based reset guid command line isn't working for you, there was a resource pack/tool that was able to be imported in your 6.5 console that provided a task based approach to reset the agent guid if a duplicate was found reporting into the console.

I located the KB article here:
The .xml files are attached in the KB artcile for import into your NS.


A Shared Altiris Agent Guid is a configuration problem that causes mismatched inventory data, and prevents accurate management and event-message storage of managed computers by the Altiris Notification Server.  The Altiris Agent Guid is the primary mechanism by which the Altiris Notification Server uniquely identifies each resource record in the NS database.  In this situation, we are concerned with computer resource records.  There are several potential causes of shared guids.  They all originate from circumvention of the normal agent deployment process, or external changes to the agent's configuration.  The end result is that two or more managed computers each claim to be the sole owner of the Agent Guid (which is supposed to be globally unique). 

Known causes

OS Imaging:  By default, the Notification Server will generate a new Guid upon the first request from a brand new Altiris Agent.  The Altiris Agent then stores its assigned Guid in the registry for Windows, and on the file-system for the Linux, Unix and Macintosh platforms.  Shared Guids can be caused by imaging a workstation that already has an Altiris Agent installed.  Each restored copy of the workstation will have the same assigned Guid.  This issue exists in all imaging solutions, with the exception of Deployment Server (DS) version 6.5 or better.  The best solution is to schedule the Altiris Agent to install immediately after restoring an image  (This can be done as a DS job).  An alternate solution is to always remember to delete the guid from the workstation prior to imaging (error prone).

Software Packaging: This cause is less likely to occur, but simple software repackaging tools will include the Altiris Agent's registry or file location of the guid as part of the software package.  Activity by the Altiris Agent can fool the packaging tool into thinking that the Guid belongs to the package.  Deploying the bad software package overwrites the good guid with the one from the capture station.  To avoid this problem, don't install the Altiris Agent on the workstation used for snapshoting the original software installation job. 


The purpose of this document is to demonstrate how to use the Notification Server’s shared GUID diagnostics kit to successfully identify and remove computers within the Notification Server database. The attached MS Word document contains screenshots for additional clarity (it is now considered out-of-date, and is merely provided for historical reference).