Video Screencast Help

DS 7.5 Path too long while importing Windows 8.1 sources

Created: 29 Dec 2013 • Updated: 18 Apr 2014 | 13 comments
no-idea's picture
This issue has been solved. See solution.

Hi,

I have a CMS 7.5 migrated from 7.1. installed on D:\Altiris.

While trying to import the os files for Windows 8.1 x64 en-us I get a console error message "Error occured while uploading files".

A check in Altiris Log Viewer gives more explanation: "Failed to add file to package repository: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."

Problem is, the original Windows 8.1 sources\sxs folder contains files with very long names and together with the package path they exceed the maximum length allowed.

I fixed it using a sources folder without sxs subfolder and copied it to the package via NSCAP share later.

Path Length Checker shows a lot of files too long in the 7.1 migrated os files. Migrated packages have brackets around their guid, fresh imported not.

Did somebody else experienced the same? I already remarked in the beta releases this might be an upcoming problem.

See screenshots attached.

 

 

 

Operating Systems:

Comments 13 CommentsJump to latest comment

James007's picture

DS 7.5 are not supported windows 8.1

 

Symantec™ Deployment Solution 7.5 powered by Altiris™ Release Notes

Article:DOC5803  |  Created: 2012-08-07  |  Updated: 2013-12-02  |  Article URL http://www.symantec.com/docs/DOC5803

See Support Matrix

Symantec Management Platform and Altiris Solutions Support Matrix

Article:HOWTO9965  |  Created: 2009-03-31  |  Updated: 2013-12-04  |  Article URL http://www.symantec.com/docs/HOWTO9965

 

no-idea's picture

I'm already two steps ahead :)

Symantec™ IT Management Suite 7.5 HF2 powered by Altiris™ technology Release Notes Article:DOC7076 | Created: 2013-12-16 | Updated: 2013-12-18 | Article URL http://www.symantec.com/docs/DOC7076

I'm using 7.5 HF2 and I can select "Windows 8.1 x86/x64" in OS Files.

johnres's picture

For such problems, you can use Long Path Tool as well, it works good for such issues!

no-idea's picture

Had the same issue today. Different customer, different environment.

James007's picture

If you have received same issue another customer, It's best bet you can approach symantec support.

Torsten Holzbrecher's picture

I run into the same problem during Windows 8.1 Deployment (using WIM Files and Scripts, no Ghost Imaging at the moment due Microsoft Surface Problems with UEFI).

 

To solve this problem, I created a self extracting ZIP-Archive, fireing the DISM command to activate .NET 3.5 after unpacking. This archive is copied to C:\Install after applying the WIM files to the partions, then boot to production.

 

First task after configuration Windows is to execute the *.exe file, to unpack itself to C:\Install\Net35 and fire the DISM command on it's own (command line to be executed after unpacking). The unpack command is triggered by the unattend.xml, to ensure .NET 3.5 is activated before Agent Installation and Driver Upgrades are fired.

 

Not the perfect way, but it's working.

 

Best regards,

Torsten

ICT Service Manager COMPAREX AG, Germany

no-idea's picture

Yepp, do it almost the same.

I have built a software resource containing the sxs folder and install it via task using dism.

But this does not resolve the original problem during import.

 

Torsten Holzbrecher's picture

And this is the difference: I'm not importing the original SXS folder into the Repository, I'm importing an self-extracting Archive, that contains the SXS Folder (and content), so the path is quite short. The "magic" is happening on the client during Installation, by first expanding this archive and then triggering the installation command.

Delivering .NET 3.5 with Software Delivery runs into the described problem, that (depending on the configuration of the Software Library) the sxs path is extended by \\ServerName\Central_Repository\Software Delivery\..... and then the Source path becomes too long. Even reducing this path to for example \\ServerName\Rep\SWD\... will not solve the problem, because using the Full sxs Package allows only to add additional 19 characters to the path (yes, we counted them ;) ).

We ran into the same problem with several other Applications, like Adobe Creative Cloud for example, so we created two Workarounds:

 

1) Create an self-extracting Archive, and check-in this self-extracting Archive into Software Repository. Self-extracting archives can be configured with a default expand path and a default command executed after expanding:

In this case, the "dotNET_Framework35_W8.1.exe" is checked into the Software Repository with the install command "dotNET_Framework35_W8.1.exe -dC:\Install\sxs"

Within the archive the command after expanding is configured (execute after expansion option) as "dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:C:\Install\sxs /LimitAccess"

Even if you were able to check in the original sxs package, you will run into the problem, that the default Agent Software Deliver Path (e.g. C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{E6F4E4AA-F303-42DC-B2D3-5A881E4ACCD8}\cache) is also much longer as allowed, so the Check-In may work, but the Delivery will fail with the same error (Path too long).

Of course you can just create an Archive with the content, check that into the repository and use a script to expand the archive to a SHORT! path on the client and execute the DISM command afterwards.

 

2) The second workaround was used for Adobe Creative Cloud. The path were shortened to Numbers like "1,2,3" checked into the Repository and the Iinstallation was done with a script, expanding the directories to the original names on the client. In this case we had to use this, because the size of the Application (>19 GByte) extended the possible size of an self-extracting archive. From the Start, this Application is possible to be checked into the Repository, but the Software Delivery Agent Directory on the client extended the maximum allowed size for a path.

Problem with this Workaround: for the Installation we need double the space on the drive: First the Agent Delivery directory, second the temporary directory where the pathes are created. We create the correct source directories first, then move the files from the agent directory to this temporary directory, and last Installating the Application out of this directory and then finally delete the temporary directory. This is done with a simple VBS.

no-idea's picture

Compressing repositories is not unknown to me, but coming back to the topic: during os files import the console should be able to ignore SXS automatically.

There should be no demand of changing os sources.

 

ICHCB's picture

I was running into this in a lab with win 8 files in ds 7.5 Hf5 and was able to get beyond it by using the ResourceImportTool.exe in “C:\Program Files\Altiris\Deployment\Tools” on the NS server.

 

Hope that helps.

http://symantec.com/docs/TECH216785

If you find this post helpful please give it a thumbs up!
If you find that this solves your problem please mark it as the solution! 

SOLUTION
Thomas Baird's picture

Resource import tool is faster than using the console anyway.  :D  When looking at this now old thread, that was actually my very FIRST thought.

GL everyone!

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.

 

no-idea's picture

It took almost four month but I think the workaround is good enough :-)