Wednesday, December 15, 2010

SCCM Client / WMI Issues

Found a slick way to fix SCCM Client issues for Win XP SP2/SP3. This fix is for when WMI has tanked and it needs to be rebuilt. Note that this is a destructive process that can kill your machine if not done right so perform these steps at your own risk!

1) Open a Command prompt
2) cd %windir%\system32\wbem
3) mofcomp cimwin32.mof
4) mofcomp cimwin32.mfl
5) net stop winmgmt
6) rmdir /s /q repository
7) rmdir /s /q Logs
8) mkdir Logs
9) net start winmgmt

Once that is done, restart the CCM Client service, open the CCM Client mgmt console (in control panel), click the Components tab then click Repair. The repair process will take a while to complete, so be patient

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!

Thursday, June 10, 2010

Deploying Raster Design and Civil 3D on 64-bit systems

Autodesk products are currently in flux between native 64-bit support and 32-bit compatability. For 2010 products, Civil 3D is not a native 64-bit application, but Raster Design 2010 is! This causes major issues, when you deploy 64-bit Raster Design, it looks for native 64-bit versions of AutoCAD to link with.

There are a few blogs out there that post the fix, however they are not very clear as to WHEN the fix needs to be applied, basically:

1) Download the compressed package for Raster Design from Autodesk's Website - Or - copy the DVD contents to your Hard Drive
2) Open Setup.ini and change the following line under [SETUP]:

Old: x64_IMAGE_PATH=x64
New: x64_IMAGE_PATH=x86

3) Create your deployment, or install the product manually if you do not have Volume Licensing

What this does, is force Raster Design to install in 32-bit compatability mode (under WOW64) so it looks to "Program Files (x86)" instead of "Program Files" for products that it supports.

Note that if you deploy any native 64-bit Autodesk apps that use Raster, you will have to create a deployment to support those apps as well. This fix also works for 2009 if you are still using it, unsure about 2011.

Tuesday, June 1, 2010

Wednesday, May 12, 2010

Server 2008 R2 w/ Hyper-V on Precision T3500 Workstations

Came across a BSOD issue when running Server 2008 R2 w/ Hyper-V on a Dell Precision T3500. Specifically, there is an issue with the Intel Nhalem-based CPUs (Xeon 5500 series and Core-i series). Specifically the stop error is 0x00000101 with an error o CLOCK_WATCHDOG_TIMEOUT

Microsoft has released this hotfix to address the issue.

Works like a charm!

TS: Microsoft System Center Configuration Manager 2007, Configuring

Its been 7 years since I last written a Microsoft Exam, and am happy to report that i wrote the SCCM 2007 exam and PASSED!!!

Its definatly a tough exam and makes you think about different ways of using the product that you may not have thought of.

Details on the exam can be found here

Next exam is going to be TS: Windows 7, Configuring

BES 5.0.1 Troubles!

So recently I upgraded our Blackberry environment to 5.0.1 MR2 due to our Exchange servers being upgraded to 2010. Definatly a hair raising experience. Wanted to post a little-known issue when installing BES on a Windows 2008 R2 server!!

There is a known issue with Microsoft Hotfix KB979683

The behavior I experienced was pretty strange, mainly:

  • When I added the DNS A Record for the MDS-IS service, I could no longer sign into the Blackberry Administration Console using Active Directory Authentication. I could only use BAS Authentication ... but i was able to access the configuration for the MDS-IS Component
  • When I removed the DNS A Record for the MDS-IS service, I was able to sign in via AD Authentication but was unable to configure the MDS-IS Component
  • Numerous error messages were displayed from timezone issues to message routing problems
  • BES would stop redirecting email after 6 - 8 hours depending on load

Removal of the Hotfix appears to have cured all these issues and more.

Thanks to the Blackberry Support Community Forums for pointing me in the right direction, specifically this post