Installation & Licensing

[#1]

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.

[#2]

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! 

[#3]

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?

[#4]

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.

[#5]

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

[#6]

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.

[#7]

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.

[#8]

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. 

[#9]

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?

[#10]

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