Client Management Suite

 Although this may actually be a broader problem...
I'm getting these kinds of errors when trying to distribute software packages:

Log File Name: C:\Program Files\Altiris\Notification Server\Logs\a.log

Priority: 1

Date: 3/5/2010 10:20:30 AM

Tick Count: 261659171

Host Name: ALTNSSRV

Process: AeXSvc (8780)

Thread ID: 64

Module: AeXSVC.exe

Source: Altiris.NS.StandardItems.SoftwareDelivery.SWDSupport.MapHttpVirtualDirectory

Description: Unable to map the HTTP virtual directory "Package - Pencil 0.4.4b (c3750632-81ed-4b31-b1a7-eff8b6cd173d)". Reason: The path specified cannot be used at this time. (Exception from HRESULT: 0x80070094)

rebooting seemed to fix one problem, but there are still errors. Now I'm seeing

 Log File Name: C:\Program Files\Altiris\Altiris Agent\Logs\Agent.log
Priority: 2
Date: 3/5/2010 11:09:31 AM

Tick Count: 146531

Host Name: ALTNSSRV

Process: aexnsagent.exe (1548)

Thread ID: 5804

Module: AeXNetComms.dll

Source: AeXNetworkTransport

Description: GetFiles '\\altdssrv\express2$\Mac Software\Utility Software\Skype\Skype_2.8.0.851.dmg'->'C:\Program Files\Altiris\Altiris Agent\Package Delivery\Skype for Mac (0012f401-9db3-439c-9e7d-c721b6bae6a5)\cache\Skype_2.8.0.851.dmg' failed: UncTransfer: Aborted (-2147467259)

can't access UNC paths, at least from the Altiris definition they can't. They can only hit HTTP paths. The only thing I found on your first error (Microsoft IIS error) was to restart IIS.

I'm confused. this used to work just fine. We rebuilt our NS/CMS from the ground up for SP2, and now things are going goofy as I rebuild my software jobs (we blew the database away too)

The devil is always in the details. If you didn't keep your database, and didn't export\import your jobs, any custom created packages are going to have different guids. For example, if you recreated Skype for MAC, there is no guarantee (in fact I would be surprised if it did) that the guid listed for the old package "0012f401-9db3-439c-9e7d-c721b6bae6a5" would be the same on the new package.

Got those two problems resolved. Now all that's left is that I have packages that aren't downloading their installation payloads. the task history says the package download was successful, but all that's on the client is an empty folder where an installation package should be :\

OK. I found the cached copy on the NS server, and it didn't pull the payload from the UNC path where the original is stored. WTH?
I'm getting cranky

Did you tell it to use the SWD Library or a UNC path? Not sure what else I can provide, as we can't see what you see.

Well I still don't have a "fix", or even any messages in the logs to account for this behavior, but every software release I'm having problems with is one where, when importing the installer, I told to update an existing resource (since a bulk of these software packages had already been picked up by full inventory scans and were listed in the "installed software",) instead of creating a new one.
That has proven to be a mistake, and I've posted a big note for all my colleagues to just create a new resource when importing packages

We too have been seeing these "Unable to map the HTTP virtual directory" errors all over the place and have seen packages which do not have a source associated with them, so the client never downloads anything. All packages are imported.

I have a call in with support and will share my findings.

Did you get an update on this? I am receiving the same issue on a brand new box and am wondering what is causing it.

For the error you are seeing, you may want to check out the following link:

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