Hello All

Hope this is the right forum to ask this question.

Does anyone know if it is possible to deploy Autodesk 2012 products with MDT 2010?

According to all the Autodesk documentation it is possible to deploy via SCCM. I have been trying for several days to install a Product Design Suite Ultimate 2012 deployment as part of my Win 7 x64 build via MDT.

I know the deployment works as I can succesfully install it by running manually. When I add the installation path to MDT and add the /W switch as per the Autodesk guidelines it gets as far as install the pre-requisites then stops.

I have tried installing .NET 4 and DX prior to the deployment but this has not helped.

Please help
Thanks P
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I just finished deploying the design academy 2012 via sccm, chaining everything, came to about 12 installs. I created a deployment share and in sccm I just ran programs and vbs which pointed there. First step was to uninstall net framework 4, because it is included in the base installs of computers. You have to install the net framework that comes from autodesk. I had a weired issue, the design review shortcuts ended in syswow64 directory, so i installed design review seperately. For testing, I installed a new fresh computer and then installed Comodo time machine on it, It worked pretty well.
Have you created a deployment share? does your computers/accounts have rights to access the share? and write to the network log share (if you have enabled logging)? In my case the local logs ended up in %temp%, try to find your logs and see what is going on. Do you get a 1603 error? and when?
What is yur commandline? Autodesk manuals refer to /W /Q /I thats the ones I used.
Answered 08/05/2011 by: admaai
Orange Senior Belt

Please log in to comment
0
Thanks for replying
I am not using the whole SCCM suite just MDT.

If I run the installer for Product Design Suite from its deployment shortcut I do not see .NET 4 being removed and reinstalled. What is the difference between "Autodesk" .NET 4 and .NET4 as deployed via WSUS, version numbers all seem to be identical.

I created a deployment and tested this succesfully when logged on as a user with local admin access. The command line I am using is
Quiet Install command: Setup.exe /W /Q /I PDSU_2012.ini /language en-us
Working directory: \\mdtshare\Autodesk\PDSU\AdminImage
If this is deployed by MDT during its applications stage as the PC administrator we get pre-requisites and then it just stops. Logs are created locally but at the point of failure nothing is logged apart from MDT reporting error 1619 - installation package could not be opened?

Maybe I am being too ambitious in the way I want to build my PC's. Because of the time and resources taken to build a PC and install Product Design Suite I need to try and do this as a Litetouch deployment. i.e. Press F12 to boot to network and come back in 3 hours to a complete PC. This would be a good idea in an ideal world that didn't include Autodesk Products.....
Answered 08/08/2011 by: petesnow
Yellow Belt

Please log in to comment
0
Have you tried deploying without MDT "in the way", e.g. using PSExec or similar?
Answered 08/08/2011 by: VBScab
Red Belt

Please log in to comment
0
Combing through autodesk forums error 1619, comes after error 1603. Autodesk does not support installation by mdt, therefore getting support can be kind of hard. Maybe you could get some more ideas here http://skatterbrainz.blogspot.com/2011/04/imaging-computers-with-mdt-2010-and.html
Answered 08/08/2011 by: admaai
Orange Senior Belt

Please log in to comment
0
Thought I would post a possible reply to this one:
Have successfully deployed Autodesk 2011/2012 products in sccm
for AutoCad - create the adminImage folder like normal
then ensure your INI file is correct and in the AdminImage folder like normal again

When you create the package make sure the ROOT folder is the one ABOVE the AdminImage folder!

When you create the program in SCCM use something like this:
AdminImage\setup.exe /w /q /I adminimage\AutoCad 2011 64bit License Server.ini /lang en-us

then also make sure it RUNS WITH A DRIVE LETTER - it doesn't like UNC paths - or download it if you want - I prefer the drive letter myself.

For RASTER Design
Same basic steps and use the ROOT folder the same way then run:
msiexec /i AdminImage\x64\ard.msi /passive /norestart
using AutoCAD as the RUN PROGRAM FIRST (a prereq)

For TrueView
get your INI file straight then:
setup.exe /w /t /q setup.ini

make sure .Net 4.0 is the RUN PROGRAM FIRST (a prereq)

Hope that helps someone
Answered 10/05/2011 by: niveknonrev
Yellow Belt

Please log in to comment
0
I successfully have tested this way of pushing out one of my 2012 products, but i did have a question for you (my apologies for it being 2 months later and digging this topic back up). When you create the Autodesk deployment, it automatically writes deployment location and a few other location based things into the INI files. So when you distribute this to your various DP's across a company, wouldn't every one of those still go looking back to the original location you created the deployment from instead of installing it from the Distribution Point?

ORIGINAL: niveknonrev

Thought I would post a possible reply to this one:
Have successfully deployed Autodesk 2011/2012 products in sccm
for AutoCad - create the adminImage folder like normal
then ensure your INI file is correct and in the AdminImage folder like normal again

When you create the package make sure the ROOT folder is the one ABOVE the AdminImage folder!

When you create the program in SCCM use something like this:
AdminImage\setup.exe /w /q /I adminimage\AutoCad 2011 64bit License Server.ini /lang en-us

then also make sure it RUNS WITH A DRIVE LETTER - it doesn't like UNC paths - or download it if you want - I prefer the drive letter myself.

For RASTER Design
Same basic steps and use the ROOT folder the same way then run:
msiexec /i AdminImage\x64\ard.msi /passive /norestart
using AutoCAD as the RUN PROGRAM FIRST (a prereq)

For TrueView
get your INI file straight then:
setup.exe /w /t /q setup.ini

make sure .Net 4.0 is the RUN PROGRAM FIRST (a prereq)

Hope that helps someone

Answered 12/14/2011 by: nkennelly
Senior Yellow Belt

Please log in to comment
0
It should only write 1 place in the INI file - DEPLOYMENT_LOCATION=\\someserver\someshare
but everything else in the INI is relative.
That line could be anything or even blank - my original deployment location doesn't even exist anymore since I created the admin image on a virtual machine (I use a clean VM for just about everything when testing).
But you had me second guessing myself, do I double checked everything and my INI file points to a non existent VM file share, it is in SCCM and is published to the DP's.
I ran the install through the SCCM advert, and monitored with netstat and no connections were ever made or even attempted to my original VM.
I did not go so far as to view all the actions in procmon and see if it ever tried to pass the deployment path to the MSI but Setup is apparently smart enough to use relative paths and get it installed without a problem.
Answered 12/14/2011 by: niveknonrev
Yellow Belt

Please log in to comment
0
Thank you for the quick response... it is good to know.

I appreciate the help getting my Autodesk apps deploying better.


ORIGINAL: niveknonrev

It should only write 1 place in the INI file - DEPLOYMENT_LOCATION=\\someserver\someshare
but everything else in the INI is relative.
That line could be anything or even blank - my original deployment location doesn't even exist anymore since I created the admin image on a virtual machine (I use a clean VM for just about everything when testing).
But you had me second guessing myself, do I double checked everything and my INI file points to a non existent VM file share, it is in SCCM and is published to the DP's.
I ran the install through the SCCM advert, and monitored with netstat and no connections were ever made or even attempted to my original VM.
I did not go so far as to view all the actions in procmon and see if it ever tried to pass the deployment path to the MSI but Setup is apparently smart enough to use relative paths and get it installed without a problem.
Answered 12/14/2011 by: nkennelly
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity