Installation & Licensing
Welcome to Autodesk’s Installation and Licensing Forums. Share your knowledge, ask questions, and explore popular Download, Installation, and Licensing topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Error 1304 or 2350 When Creating a Deployment for Autodesk 2011 Products

39 REPLIES 39
Reply
Message 1 of 40
bryce.thelin
13670 Views, 39 Replies

Error 1304 or 2350 When Creating a Deployment for Autodesk 2011 Products

When trying to create a deployment image for an Autodesk 2011 product, the process stops with one or both of the following errors:

"Error 1304. Error writing to file . Verify that you have access to that directory."
"Error 2350. FDI server error."

The cause of this is the installation directory has exceeded the 256 character limit of the operating system.

The solution is to shorten the path that you have entered for your Administrative Image location when initially creating the deployment.

Bryce Thelin, Autodesk Product Support



Bryce Thelin
AutoCAD Product Support
39 REPLIES 39
Message 2 of 40
zalant
in reply to: bryce.thelin

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.

 

 



Zac Travis
Message 3 of 40
spm5
in reply to: bryce.thelin

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.

Message 4 of 40
ktaylor
in reply to: spm5

 


@spm5 wrote:

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.


COMPLETELY agree.

 

Message 5 of 40
Patrick_Aps_9121
in reply to: ktaylor

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.

Message 6 of 40

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.

Message 7 of 40

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

 

Message 8 of 40
art_turner
in reply to: bryce.thelin

Phfft!

 

2:38 begin extract Inventor 64

 

4:23 Error 2350 FDI server error

 

top level directory, windows 7,

 

 

 

 

 

 

 

Message 9 of 40

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. 

 

 

Message 10 of 40
TravisNave
in reply to: bryce.thelin

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. 

 

 



Travis Nave Send TravisNave a Private Message                                             Need help in your post? Mention me with @TravisNave



My Expert Contributions to the
Autodesk Forums:
FLEXnet License Admin | MSI Cleanup Utility | .NET Framework Cleanup Tool | IPv6 NLM Fix | adskflex.opt Options File | Combine .LIC Files
Message 11 of 40
spm5
in reply to: TravisNave

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.

Message 12 of 40
TravisNave
in reply to: spm5

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!  Smiley Very Happy

 

 



Travis Nave Send TravisNave a Private Message                                             Need help in your post? Mention me with @TravisNave



My Expert Contributions to the
Autodesk Forums:
FLEXnet License Admin | MSI Cleanup Utility | .NET Framework Cleanup Tool | IPv6 NLM Fix | adskflex.opt Options File | Combine .LIC Files
Message 13 of 40
art_turner
in reply to: TravisNave

the margin for error is very small.  i had to go to

 

 

\\servername\\A_Inv_12_64_N

 

the name i had before was simply the same thing spelled out. 

 

whats the limit? how many characters can your customers use?

 

 

Message 14 of 40

So how would you know that \\SERVERNAME\FOLDER_SHARE isn't too long? And if it takes a half hour to an hour to unpack the installer and another half hour to reach the failure point in creating the deployment, wouldn't you like to know ahead of time if there are any important restrictions in creating the deployment? In my mind, and I'm sure many others, this is no different than telling the customer how much disk space is needed to install the product. This info should be displayed when the customer creates the deployment. How long the folder and file names should be is a different issue. This problem is pretty cut and dry.
Message 15 of 40

while(horse.status = DEAD)
{
horse.beat();
}

 

Smiley Very Happy



Travis Nave Send TravisNave a Private Message                                             Need help in your post? Mention me with @TravisNave



My Expert Contributions to the
Autodesk Forums:
FLEXnet License Admin | MSI Cleanup Utility | .NET Framework Cleanup Tool | IPv6 NLM Fix | adskflex.opt Options File | Combine .LIC Files
Message 16 of 40

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.

Message 17 of 40
GrantCollins
in reply to: bryce.thelin

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.

Message 18 of 40
TravisNave
in reply to: GrantCollins

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. 



Travis Nave Send TravisNave a Private Message                                             Need help in your post? Mention me with @TravisNave



My Expert Contributions to the
Autodesk Forums:
FLEXnet License Admin | MSI Cleanup Utility | .NET Framework Cleanup Tool | IPv6 NLM Fix | adskflex.opt Options File | Combine .LIC Files
Message 19 of 40
GrantCollins
in reply to: TravisNave

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?

Message 20 of 40
TravisNave
in reply to: GrantCollins

Sharing folders is a function of Windows, not Autodesk.  In all my Autodesk deployments, I specify only \\servername\sharename



Travis Nave Send TravisNave a Private Message                                             Need help in your post? Mention me with @TravisNave



My Expert Contributions to the
Autodesk Forums:
FLEXnet License Admin | MSI Cleanup Utility | .NET Framework Cleanup Tool | IPv6 NLM Fix | adskflex.opt Options File | Combine .LIC Files

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Administrator Productivity


Autodesk Design & Make Report