Best Practice: Keep the path as short as possible.
For example, when prompted for the location of the deployment (at the beginning of the Deployment Wizard), instead of specifying something like:
\\My Company\Software\Installations\Deployments\Autodesk\AutoCAD 2011 32-bit English Installation
use something more along the lines of
\\AutoCAD 2011 32-bit Install
Directly share the folder which will house the new deployment, instead of creating that folder a few directories deep in an existing shared folder.
This wouldent be as much a problem if the media library did not have file names that were 200 characters long. I think that is completely unnecessary.
And the problem is even worse,
because when you select at the start of creating the deployment, that you do not want the medial library to be included,
these unselected items still get copied to the deployment location and still take up unwanted disk space on the deployment server and still cause the error.
It appears that Autodesk are doing very little in this space to fix this issue. Just tried a Plant 3D 2011 deploy, and the Materials folder and filenames are completely out of control. Some filenames with nearly 100 chars!!
Some firms may have the luxury to shorten the depth of the parent deployment location, however Autodesk are not the only software vendor in the world, and we must have a logical folder naming convention to achieve deployment of 600+ other technical applications. I don't believe this is an unreasonable expectation! Obvously creating folder shares for multiple sites (25+) is impractical as well.
Moving forward, I put it back on Autodesk to have a good look at their folder and filenamng conventions (especially around Materials), and come up with a practical solution that allows us to adopt a "reasonable" parent fdeployment older structure to start with.
Windows 7 is not helping also: You have to run the link, created by the deployment "As Administrator" to install the software.
But this user is another session and does not have the (same) drive mappings, so he has to access the location using UNC paths.
Which in our case is something like \\Servername.subdomain.domain\Sharename\Intall\Win72_32bit\AutoCAD_2011
Phfft!
2:38 begin extract Inventor 64
4:23 Error 2350 FDI server error
top level directory, windows 7,
This solution requires Autodesk to provide the maximum allowable length of the folder path to a deployment. The users should not have to guess and guess again.
I never understood why this was an issue. The solution is simple. \\Servername\Sharename. Simple. Why people insist on making UNC shares that are themselves multiple folders deep is ridiculous. Sure, the physical folder location on the server can itself be many folders deep per company policy, ISO9000, etc., but for crying out loud, share only the last folder for deployment purposes. Navigating down thru a share to get to an installer is pointless and defeats the purpose of file and folder sharing for ease of use. Stop over complicating things and you won't have errors.
Because it is not an acceptable solution to create a share for every software I want to deploy. We have 30+ software deployments on 1 server, as well as pc images, and libraries.
On top of that any of us working in a company of more than 50 people are not in charge of the servers, only the software. For every share I want to create I need to ask the IT department to create it. They will ask me why, I will explain, they will tell me they don’t want to clutter up the network with all those shares and they don’t want to put in the work to create them .
The simplest solution is still for Autodesk not to have 200 character long names for the render library.
Really, that's the simplest? I create a share for every product and it works just fine. The problem is the process, not the product. I can agree that long filenames are ridiculous, but it is what it is. Perhaps in the future releases it will be different. But since that cannot be changed now, the simplest solution is to use shorter UNC paths. Any IT professional will recognize the path limit as an acceptable reason... even the most evil ones. I can attest that as an evil IT guy myself, the less work we have to do, the better. Oh, you need a share to avoid install errors that I'd have to fix? Done!
the margin for error is very small. i had to go to
the name i had before was simply the same thing spelled out.
whats the limit? how many characters can your customers use?
while(horse.status = DEAD)
{
horse.beat();
}
Just had a similar issue creating a deployment for the latest 2013 version of Building Design Premium, got all the way to the last product (Autodesk Essential Skills Movies) and errored out.
It took almost two hours to build the deployment and now it's reversing course because one item didn't install properly. I'm sure the "cancel" will take 1-2 hours as well.
We had similar issues with the 2012 deployments as well, but there were tons of other problems that this issue was minor by comparison. So, while other issues seem cleared up, this particular issue still has not been resolved more than a year later.
And the fix is fairly simple, find the longest file path in all packages in the installer and subtract it from the max path allowed, then tell me if the path to the admin image is too long.
Or at least tell us what the longest admin image path should be for the product.
I just want to thank Autodesk again, Sketchbook DEsinger 2012 destroys my standard deployment locations for a second time because of this product
All other deployments work fine in this location.
\\gal1-s-sccm1\PackageSource\Autodesk\2012\Eng
I have built over 300 deployment with various Autodesk packages.
The reason people get the FDI error when building the Sketchbook Designer Deployment or even the Product Design Suite is because the dumb Autodesk Engineer that created Sketchbook Designer 2012 labelled a single file with 77 characters in it. Well when you got only 255 characters you can work with, why in your right mind would you label one file with a 77 characters in it. This file has cause more grief and has made me stray from more Autodesk Standards than you can possible believe.
The only recommendation other than shortening your path is to start with Sketchbook Designer to figure out your deployment path. If this one works, guarenteed you will not get any FDI errors with any other products. Trust me when I say I more than not happy with Autodesk and this stupidity.
If I have said it once, I have said it a thousand times. If you have some kind of folder naming convention that you use, that is fine. However, once you have decided to put your files the 387 folders deep, share only the last folder. That way the UNC path is \\servername\sharename. There doesn't need to be \\gal1-s-sccm1\PackageSource\Autodesk\2012\Eng when it can be as simple as \\gal-s-sccm1\Autodesk2012. Your physical pathing can be the same as above, but the share needs only to be simple. You're defeating the purpose and convenience of sharing by making long paths that require more traversing.
Will this work using the sharename when trying to push it out via SCCM after? Without granting the end user access to the root share (iun this case I would make it at the Autodesk level?
Sharing folders is a function of Windows, not Autodesk. In all my Autodesk deployments, I specify only \\servername\sharename.