Deployment Solution

I am having an issue with just 1 package that has me stumped. I am hoping maybe someone has seen it before. We are using Altiris Version 7 and all packages with the exception of this one works just fine. I have tried recreating the package and the problem still exists.

The package should install MS SQL Express 2005 and will be used as a pre requisite package for another application. However when I add a machine to the filter for the package or the other package that uses it as a pre requisite the SQL Express download always fails. The download gets to 50% cache and then fails with a return code 0.

The log file found at C:\Program Files\Altiris\Altiris Agents\SoftwareManagement\Software Delivery\<GUID>  shows the error:

HTTP Request Failed: The system cannot find the path specified.

The strange thing with this one is that it downloaded and cached 50% and does so on every machine we try this on. Also we can browse to the deployment server location and access each file just fine manually. This can be done by the UNC path and the HTTP path so the paths seem ok. I manually transfered the files into the local cache directory and the download status then shows 100% cached, yet the download still fails with the same error.

I dont want to go too much into config as every other package works OK, it is just this one. It's more of an irritation than the end of the world. There are other packages larger is size so I dont think its a timeout issue either.

It will be good to know if anyone else has seen this.

 

Many Thanks

James

Does it make a difference if you change which medium to transfer the file with?  HTTP vs UNC can make some weird differences.  If your clients are trying one, maybe try forcing the other as a test?

What is the size of the file/package?

The package is 160mb in total which isn't as large as MS Office etc, yet they run fine.

Where would the option be to switch to UNC for that specific package? My colleague set up the template policies so I haven't played too much with those settings. Would it be in the software package or the policy?

Thanks very much for the response

 

James

Hi,

Check your source files if there your UNC path can be many characters. If all your machines stops at 50% there should be something wrong with the package. Browse through folders and files of your package source files. It think there is probably to long unc path to certain files or you can have reserved characters on some folders or files like ?:* for example.

Good luck!

Have you found anything yet on the illegal characters?  My guess is that the HTTP vs UNC isn't the issue based on what you've seen.  In fact, you may have to do a network trace to see what is happening to that particular stream.  I've seen stranger things.  We had a switch that went bad and filtered out any file with a certain extension.  Very odd.  But you might have something like that, or something in that particular package...  Oh, and force an update to all package servers for the package just in case.

Nothing so far, all file paths are within 256 characters and didn't see any disallowed characters. That doesn't mean I've given up on that idea though. Will revisit it when at work tomorrow.

You said you've recreated the package - have you recreated the files themselves?  Maybe there are no illegal characters, but if one of them is damaged, that might also explain this behavior.

I recreated the package again but used the original EXE this time, before I had unpackaged all the files and ran from MSI.

That ruled out any chance of file names or long paths and I no longer have the problem. I cant say for 100% if it was an illegal character or a corrupt file it's no longer an issue.

Thanks very much for the ideas. This one had been irritating me a fair bit.

I mean, we all love for it to be gone, but there are times I wish I just knew WHY it was gone!  Thanks for the update and GL moving forward!