Showing you what I did on a recent project with a client – moving license servers on a few hundred workstations automatically! Very useful when migrating servers or retiring servers, or even making sure workstation have a backup license server in the cloud. Using Group Policy, we make an environment variable on workstation listed on a specific OU. The environment variable will direct workstation to point the Autodesk software to point to the new server.
Since everyone loves videos (myself included), here’s another one! Autodesk AutoCAD 2014 Deployment creation & customization. No frills video that goes straight into demos, creating a deployment in a DFS path, and then installing it onto virtual machines using Virtual Box.
Got a follow up video for those you responsible for making deployments in your office. Since the original deployment was made, Autodesk has release Update Release 1; we’re going to add that update to your deployment image. We’re also going to change two file locations, the Revit Project Data path and the IES file location.
There are two reasons for this change. If you want worksharing to work properly, the folder needs to be write-able for users. Since my DFS location is locked down and I don’t want to bother with permissions and blocking inheritance, I’m going to repath it to the local workstation. The second reason is that you will always have a local copy of the Revit model you’re working on (in case the server falls off the cliff).
There are many ways you can deploy Autodesk software and in this post/video, I’ll try to explain the different methods. I’ll also show how you can easily create a deployment of AutoCAD 2013 on a DFS location, using my office as an example. In the video, I’ll also go through different methods of automated software deployment, including batch files, Group Policy, and SCCM.
I initially created a group policy as I’ve always done. Set package installation paths, point to the MSIs. Seems like that didn’t work too well. After a gpupdate /force, the workstation will look like it’s installing the software but when you log in and actually try to install it, you’ll get this errror with ACCORE.DLL crashing.
After looking through a lot of different discussions boards and PDF white papers and going through a few trial runs in our lab, AutoCAD 2013 is now installed in my training rooms, pushed automatically via OU association with Group Policy. It was a little bit of a hassle to figure out the various MSI and MST files needed for successful GPO push, but alas, all is well in the universe again
Confirmed my licenses for 3ds max design 2013, and packaged the deployment in my DFS – no errors or failures. The next step was to deploy the software! My philosphy is always to automate as much as possible so I decided to use Group Policy to push the software out. Initially done on my lab, I then applied the GPO to one of my training rooms. EPIC FAILURE! Here’s the error message from the workstation:
Event ID 10005
Product: Autodesk 3ds Max Design 2013 64-bit — 1: 5 2: adlmPITSetProductInformation failed. 3:26
I searched for the solution, including renaming the .pit file from the Program Data directory but it didn’t work! I’ve been working on finding a solution for this so my GPO will push but nothing seems to work! Sounds like I’ll have to start a case with Autodesk! 😦
Just came back from a client visit and the project this time was helping to upgrade their license server. Pretty straight forward stuff, but I’ve come to realize that what I do as “straight forward” is actually pretty impressive to quite a few people.
We all know [at least you should if you follow my blog] that there are three spots that Autodesk uses to define where the license servers are.
- Environment variables
- Registry Entries
These are read that in that order, and when the system finds the key (ADSK_LICENSE_FILE), it will stop and put it to memory. So how does it affect my deployment? Well, if you have a license server (let’s call it OldLic1 and OldLic2) already serving up licenses and you want to upgrade/retire it and move licenses to your new, awesomely robust virtual server (NewLic1 and NewLic2), most people think you need to touch every workstation to update those values so that AutoCAD and Revit will get license from the right servers. NOT!
With the all-powerful Group Policy Management Editor and some nifty GPOs, you can make the change to all your workstations to all your branches… at once. Yes, we did this to well over a thousand machines for this project, even to their branches, WITHOUT having to touch every single machine. Thank goodness too, cuz I would’ve gone crazy!
So what is the difference between default, local, and shared when you deploy AutoCAD / AutoCAD Architecture? Both default and local stores onto your local workstation; the difference is that you get to pick where you want it to go (local) and keeping content data like AEC styles and DesignCenter Content in the ProgramData folder (default).
The Shared Mode is where things get a little more interesting, and for larger firms, this is the preferred method since standardization across all workstations is vital for productivity. I mean, you don’t want teams in the same firm using completely different Templates and Layer Standards. Some points to consider:
- If you specify the same location for subsequent installations (not deployment), you will be prompted to overwrite the existing shared content files.
- If you create a deployment with shared content, the content files are written to the shared locations when the deployment is created. This “one time deal” installs content for all Content Packs to the shared location so make sure it’s large enough.
Thankfully uninstalling the software from one workstation does not remove the content from the shared location. Imagine the headaches that would’ve happened if that was the case! Craziness!
Within a few months, Autodesk has released a second update for the Revit family of products. Download them from the Autodesk website (here). Being a “on the ball” IT guy, I went to update my deployment images for Revit Architecture, Structure, and MEP.
Since I have both standalone and network versions, I don’t want to download the updates twice. The automated method actually downloads the MSP from Autodesk and puts it into the file location \\company.com\deployments\RevitArchitecture2012-64bit\AdminImage\x64\RAC2012, under the file name rac2012ur2.msp. Knowing this, I moved the .MSP file over the the root of the deployment image for the Revit product and modified the deployment to apply that .MSP. One MSP can then be used for both standalone and network deployment. Save server space. Save time. WOOT WOOT!
Autodesk has recently released the Revit 2012 Deployment Utility to help BIM Managers with Revit configuration. There is no longer a Revit.ini file on the deployment image; instead, there is a inifile.xml file that creates the Revit.ini on workstation installation.
Check out the video and make sure you switch it to HD so you can see the text clearer. I’ll show you how to modify the XML source file before any installation happens. This will result in a clean push without needing any bandaid modifications on the workstations later.
There are some great resources from Autodesk and their support team bloggers documenting Revit customization. Check them out after you finish watching the video for more info:
- Autodesk Revit 2012 Deployment Utility: DOWNLOAD / README file
- Up and Ready: Revit 2012: Revit.ini customization, the old fashioned* way
- Revit Clinic: 10 Revit.ini Customizations (based on 2010)
- Revit Clinic: Deploying Revit 2012 with a customized Revit.ini file
- Revit Clinic: Revit 2012 Network Deploy Utility: Custom Revit.ini Settings & Content Supression