problem deploying 3DS Max via sccm

[Anonymous]

Hello,

I'm having a problem deploying 3DS Max with SCCM,  I have successfully packaged and deployed every other AutoCAD application, but this one is troublesome.  Going through my sccm client logs, the client is failing to download the 3DS Max package because it's running into a path/filename that is too long.  Is there any sort of solution to fix this?  We have to run the installation under the user's context because all the profile specific directories are written to the user's profile.  Running the package under the system context writes those directories into a system directory.  Any ideas would be greatly appreciated!

Thanks

Tim

[todd.kane]

Have you tried putting the deployment into a shorter file path?  Generally, we recommend \\SERVERNAME\Deployment\Product as a best practice.

[Anonymous · Accepted solution]

the problem isn't the deployment path itself, it's the local cache path that sccm downloads to.  I was able to get around this by running the program directly from the sccm distribution point vs download and install.  Works quite well.

[todd.kane]

Nice, my guess is that the download location on the client was a very long path.  Glad that you figured it out!

[Anonymous]

yeah, i don't know how familiar you are with sccm, but i'll post this in hopes that it also helps someone else.  When the sccm client downloads a package from a distribution point,  the default location (for an x64 OS) is c:\windows\syswow64\ccm\cache.  From there, the package folder naming convention follows the pattern <packageID>.<revision>.<context>.    For Autodesk applications, we have to run the installation as the user per my original post.   Downloading the package as system, the local package path is tolerable e.g. c:\windows\syswow64\ccm\cache\gai00080.2.system\    vs  downloading as the user  c:\windows\syswow64\ccm\cache\gai0080.2.S-1-5-21-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx\

Running directly from the distribution point hold 2 advantages, we don't run into the download path length limitation, and we don't have to sit through the painful process of downloading and then running a consistency check on the downloaded content, which for some autodesk packages can take upwards of an hour.  Obviously this is only a solution if you have an sccm distribution point on your local LAN, running this over a WAN link would probably fail and is NOT recommended in any way.  Hope this helps!

Tim

[Random206]

I work for a large government department, and we have the same issue, when users request the software via available deployments (not required).

The issue occurs as SCCM suffixes the users GUID to the cache folder.

I got around it by 7zipping the source files transferring that and extracting to the users D Drive on their device, installing from there, and then deleting.

If you want, I have attached as a text file the powershell script I used.

You will need to rename the format to .ps1 for my Inventor script, as I was experiencing the issue with Inventor.

**I DO NOT TAKE RESPONSIBILITY FOR THE USE OF MY SCRIPT, OR ANY RESULTS YOU RECEIVE WHILST USING IT....IT IS YOUR RESPONSIBILITY TO ENSURE YOU CHECK THE SCRIPT IS COMPATIBLE WITH YOUR ENVIRONMENT, AND THAT YOU UNDERSTAND EVERYTHING THE SCRIPT IS DOING BEFORE YOU RUN IT**