Client Management Suite

Hello All,

Im currently having some small dramas with the Altiris plugins I am hoping someone can help me with, or at least point me in the direction of some documents that can. I have already spent some time trolling around the net but cant find anything to helpful. My issue is as follows.

Scenario: Installing SMA onto a server machine (which isnt part of the companies domain) to be managed via all plugins used.

Problem: Installing SMA wasnt an issue, but the plugins are. Some of the plugins (eg Inventory Management plugin) successfully installed but some of the others we use (eg. Software Update plugins) didnt. Upon prodding and poking around I found that the ones that worked have http://"<fqdn>"/Altiris/NS/nscap/bin/win32/x86/pcagent source locations while the others that failed only reference a network source location.

Question: How do I configure these alternate source location settings? I wasnt involved in the intial setup of the server so I need to configure this setting for the plugins I have enabled myself after the initial setup (Software update, Qchain, Software Management etc plugins). Also I need to ensure that the Server will also have access to the updates aswell.

Any help would be greatly appreciated.

Thankyou

I believe you have created a package server and if this is correct than make sure that package server machine is able to ping client machine using FQDN and vice versa.

It might be possible that downloaded plugins are downloaded from SMP and later package server is created and now clients are trying to download from package server.

Then you can fire up the logviewer on the client that will give you an easy view of the client log and see why the client can't download the subagents.

Or find the Remote Altiris Agent Diagnostics (RAAD) kit on the Support forum and use that to remotely look at client agent logs.

On the NS go to Settings > Notification Server > Site Server Settings and see what Site Servers have been set up as Package Servers and make sure they still exist. If you get rid of any, run the two Scheduled tasks from Control Panel that are called NS.Package...

It might be a permissions issue if this computer is not on the domain but you use domain-based application identity credentials.  Are you sure the user on the non-domain computer has access to the file locations?

Thanks for the quick response guys.

Just to elaborate a little bit more, security settings on this server is locked down as it is our web server being hosted in the DMZ. I attempted to add 2 screenshots from the SMA installed on the server I am having issues with. One shows a plugin that successfully installed automatically via policy and how it contains an alternate URL download location which uses the FQDN (which I dont know how to modify/create). The other screenshot is a plugin that didnt install which is only using a UNC patch.

Mclemson: Permissions are a slight problem as the box isnt part of the domain I have to log onto the box as a local admin to perform any actions. I have tested accessing the file locations manually and using PING to diagnose, but this has all been blocked/lockedown for security reasons. The firewall rules have been relaxed to allow communication between the Client Agent and the NS Server so the client receives the configurations and tasks and reports as normal. So the problem is indeed that the server is unable to reference the UNC location for the plugin packages. I was hoping to replicate the FQDN URL settings across the other plugins that only use the UNC path.

Andykn101: I checked the Site server settings and found a notification telling me that the Package Service wasnt actually installed on the site server that is setup.

Thanks guys for your help on this one. Just a quick note though, Since my original post, I have tested manually copying across the software update plugin .msi package to the server and I installed it manually. It works and is reporting but I am faced with the issues that the server cannot reference the UNC path location to download the updates it needs.

I think I know what is going on here.

Because the server is on your DMZ, you probably can't reach through port 80 to reach the package server (The HTTP source location)  and NetBIOS broadcasts are also likely blocked, thus preventing the UNC path from working.

The problem is that the programmers at Altiris, and then at Symantec didn't consider using non-domain machines when they were programming the system, and so the server doesn't hand out IP addresses or FQDNs of the site servers to the agents when not using a web-based site server.  In your case you have the webserver, but the DMZ is likely blocking port 80, making it inaccessible.

You can either unblock port 80 through your DMZ (unwise), or set a static HOSTS/LMHOSTS entry to allow for UNC path browsing. (clunky, but works.)

I already have a suggestion in to improve the Altiris Agent such that it allows one to MANUALLY add in a list of alternate site server locations, inlcuding IP address, and then have the agent round-robin them until it gets a response.  (really helpful for web-based updating of remote agents)  You can find that idea here:  https://www-secure.symantec.com/connect/idea/preferred-servers-proxy-round-robin-offsite-patching  Please give it a vote if you like it.

Hey Guys,

I ended up finding the solution I was chasing down after pulling some teeth. Packaging Service. Our server didnt have that service installed and configured initially when it was setup way-back-when. Once I had installed the service and configured the settings, all packages I enable for delivery (whether it be a plug-in/windows update or other stuff), the packaging service allowed me to publish packages not only through UNC but via URL. Now im able to manage the machines which are not part of our domain.

For everyone that mentioned Package Service, Thankyou. It might not have been the exact answer, but from your suggesstions I was able to deduct what was wrong.