Wednesday, August 11, 2010

Deploying Autodesk Revit 2011 Products

Autodesk has come a long way in deployment creations over the years. The "Create Deployment" button from the app launcher takes you through a nice smooth creation process ... unless you are deploying any of the Autodesk Revit products using SCCM.

The Problem

When you create a Revit deployment (MEP, Architectural or Structural), it also has extra content that gets installed after the fact. When the software is deployed to the client system, it looks to the original deployment location for the content and installs as required. While this works fine on a stand-alone network share, it doesn't jive well with SCCM for a couple of reasons:

1) When you create the SCCM Package, the deployment gets moved into the SCCM architecture which has its own folder structure that will differ from your deployment location
2) In a distributed environment (like mine) where you have a Primary SCCM Server (or Central Site) and you have many Secondary Site Servers over long distances, pulling the Content data over the WAN is not an option (at least 500MB of content per install).

The Solutions

Method 1 - Use Drive Letters

With SCCM, you can setup a program so that it uses a specific drive letter when installing. This drive letter is mapped when you Run the Advertisement and then removed once it is complete. You would then deploy Revit as followed:

1) Map the drive letter you wish to use on your Deployment system. Hint, you can map a drive to a folder on your C drive by creating a share, or using the administrative share ie: \\computername\c$\ADESK_Deploy\
2) Run the Create Deployment Wizard. When prompted for the Administrative Image location, specify the Mapped drive. If it warns about not being a shared network location, accept the warning
3) Configure the Deployment as normal, do not modify the content directory location
4) Finish the deployment and create it

Once that is done, you will need to create the SCCM Package as you normally would. When you create your Program, on the Environment tab select the radio button labled "Requires specific drive letter (example: Z)" and type in the drive letter that you used when creating the Revit Deployment. Advertise and install at this point.

While this method appears to be the easiest, you may run into problems if you have a lot of memory card readers in your environment since they don't alway grab the next drive letter in the list, and in most cases users will change where they map too. That is why there is:

Method 2 - DFSr-supported Deployment

This method is a little different and requires that you have the following:

1) A mapped drive that is consistant in all offices that users have read access too
2) Replication setup for these folders via DFSr or any other replication software

I use this method in my envoronment as each office has their own shared drive letter, plus a standards drive that is consistant in all offices. Card Readers, USB Keys and External HDD's round out the rest of the drive letters so Method 1 is not practical in this case. Within our comapny we have a Revit folder set asside for Content, lets call this R:\Revit\2011\ for the sake of this demonstration. This folder gets replicated via DFSr to all our offices that use Revit, so any content added or updated is available in a reasonable amount of time to anyone else who uses Revit.

Before you Begin

If your deployment workstation does not have a mapped drive to your content directory (hereafter referred as R:\Revit\2011\), map a drive to that location or to a temp folder on your deployment workstation.

The Deployment

Begin setting up your deployment as per normal. If you are strictly using SCCM to deploy Revit, you can use any target for the Administrative Image as it will not be used for client installs directly. When you get to the Content Configuration Page, set your path to R:\Revit\2011\Revit (i use Revit for Revit Architecture, Revit_MEP for Revit MEP and Revit_STR for Revit Structures) and continue through the rest of the deployment.

Once the deployment is finished, go into the AdminImage folder and move the ContentENU and ContentAll folders to R:\Revit\2011\Revit

Next, there are two "content.rcl" files that need to be modified to point to the correct content location. Failure to modify these files will result in the content installation failing.

content.rcl file #1 Located at:

content.rcl file #2 Located at:
AdminImage\RevitSetup\Revit\program files\Autodesk\Root\program\Content.rcl

Open the content.rcl files using Notepad so you can view the contents. At the top of the file you will notice that the first few lines under [silentTargets] point to your central content location, however further down you will see a number of "downloadpath=" entries that point to your original deployment location. Change these too R:\Revit\2011\Revit, i find the Replace command very helpful for this.

Finally, if you created a temporary location for the central content, you will need to copy it to the correct folder and let replication take its course.

The SCCM deployment is created normally, no special considerations are requird outside the standard steps outlined in the Autodesk Deployment Guide.

If you have any questions about this, please post in the comments section below!

Wednesday, August 4, 2010

SMS_Distribution_Manager Caught in a Loop

The other day I came across (read: caused) a potentially major and annoying issue when rebuilding a secondary site server. Things were going very well ... used a new site code, the server software installed perfectly, applied the R2 feature pack, configured site settings and setup all our packages to sync to the new server. With 250+ packages it was going to take through the weekend to finish, which i wasn't too worried about.

While that was going on, i decided to do a bit of package cleanup, deleted some old Novell uninstall packages that we no longer needed, to help clean things up a bit. What I didn't pay attention too is that these packages were scheduled to transfer, so when the packages were deleted ... the schedules weren't removed. Imagine my suprise on friday afternoon when i saw 60000 informational messages in my Site Status for this new site. The distmgr.log file was going crazy re-processing these 4 packages that no longer exist.

The bad part, is that because the server was stuck on these 4 packages, nothing else was getting processed by the site server ... which means no packages were installing.

After searching for fixes, the only ones i came across required the original package (with the original packageID). I didn't have this, soo i decided to fudge it a little:

1) i found 4 small .PCK files in the SMSPKG and copied them to a new folder
2) rename the .PCK files to the names of the missing packageIDs
3) copied them back into the SMSPKG folder
4) used the preloadpkgonsite.exe utility to tell the primary server that the package has arrived at the site server

At this point the secondary site server processed the package and unpackaged it too the SMSPKGx$ folder.

Probably not the best way to fix this ... but hey it worked!