Excellent usage article on SCCM

My friend Jarvis wrote an excellent article about how to manage the default collections to make them easier to use. This is one of those great usage articles that all SCCM administrators should read regardless of their experience.

Failed to download pre-requisite components (0x80090024)

This error may be the root of evil, it actually means virtually nothing other than your screwed and that your not going to complete SCCM setup today.

I was recently at a customer helping them setup SCCM 2007 R2 and no matter what we did on one machine we couldn’t get SCCM setup to complete. If we tried to download the pre-requisite components we would get the error above. If we downloaded them first (setup.exe /download <downloadlocation>) it would just fail later in setup with a hash check error (File hash check failed 0x80090024). We literally troubleshot this for two days until we figured it out. We did the following to try to resolve.


  • Download on different machine and copy
  • Remove PacketShaper and IDS from inline
  • Rebuild Server
  • Update BIOS
  • Add automatic configuration of Proxy
  • All combinations of above


  • Succeed: Run install on separate machine on same domain against same SQL server
  • Manual MD5 hash check of file!

Must be a hardware problem right? It only ever fails on this box? Gotta be… Well we ran Hardware diagnostics and it came up perfect.

So what was the problem? The user that was logged in had a faulty terminal services mandatory profile. For whatever reason this caused the download to fail. The reason it worked on other machines is that we were not logged in via terminal services. Lesson learned? Make sure your profile is working…

SCCM R2 Softgrid integration very good with one low spot

I recently had the opportunity to spend some time working with the SCCM R2 Softgrid integration. First off the overall integration is excellent, it adds the powerful SCCM infrastructure to the great Softgrid solution. In the past the ability to scale with Softgrid was extremely limited by the Softgrid infrastructure. The integration with SCCM allows the use of the powerful distribution infrastructure in SCCM in addition to the ability to target computers. It also allows the targeting of workgroup machines which was not included in Softgrid 4.2 (it is included in 4.5).

However with all of this excellent extension of Softgrid there is one low spot. Once the client agent for Softgrid is enabled the policy is delivered via the SCCM policy engine. rather than the Softgrid Desktop Configuration Server. While the SCCM policy engine is very scalable it does lack speed. The Desktop Configuration Server in Softgrid offers virtually instantaneous delivery of applications to users at login. Now depending on how you target the application in a collection this could cause a major delay in software delivery time. For example if you target an AD group that contains users depending on your discovery and collection refresh cycle you could have a several hour delay in software delivery. Obviously if you use the functionality introduced in SMS 2003 SP2 where you can target a group of users via a collection your software delivery speed will be greatly increased. Even with this model you will not have the immediate delivery of a Softgrid application at login like you do with the Softgrid Desktop Configuration Server. 

I will leave it to you to evaluate whether this is an issue and if so how severe it is something that I am disappointed with. When using a thin image strategy the ability to deliver applications instantaneously at login provides a very powerful tool for desktop management. I am hopeful that in the next version of SCCM we will be able to deliver policy more quickly and use the scalability of the SCCM infrastructure. Until then depending on the implementation requirements I may still be using the Softgrid Desktop Configuration Server.

Deploying XP with SCCM: Part 1 Building an XP Base Image

This post and subsequent posts will be a step by step on how to build a base XP image in SCCM. I will be outlining not necessarily pointing out every click. Hopefully others will find this helpful. This assumes an understanding of SCCM and uses what is refereed to as a “Thin Image Strategy”.

  1. Create a network access account, it only need be a domain user and its password should not expire. Add the account to the Computer Client Agent in the Client node under Site Settings
  2. Import XP SP2 as an operating system Install Package (Note most common issue here.
  3. Add a Distribution point to your new XP SP2 package created in step 1
  4. Create the XP SP2 sysprep package in SCCM
    1. The Deploy.cab included on the CD was not updated properly for XP SP2 so you must download a new version here.
    2. Create a package that points at the extracted CAB file for its source
    3. You do not need to create any programs for the package the build task sequence takes care of this
    4. Add the package to a DP that can be used during your build
  5. Create a package from definition for the Config Mgr Client (a definition is available called “Configuration Manager Client Upgrade” in the create package from definition wizard)
    1. Specify always obtain file from source directory
    2. Usually here I create a share at \\SCCMSERVER\SCCMClient pointing to \\SCCMSERVER\SMS_XXX\Client where XXX is the site code in order to make it easier for manual installs in the future. Note I also usually grant domain computers read access to the share and directory to prevent permissions problems in the future (Note this last permissions step may no longer be necessary in SCCM but I haven’t tested it yet)
    3. Update the ccmsetup command line properties accordingly. Extensive information about command line properties on TechNet here.
    4. Add the package to a DP that can be used during your build
  6. Create a “Build and capture a reference operating system image” task sequence
    1. Name the task sequence something appropriate like “Build Windows XP Gold Image”
    2. Select a boot image (I suggest x86 as it will run on all platforms, plus you will be booting from PXE so it really doesn’t matter)
    3. Select the Operating System Package you created in step 1
    4. Enter a product key
    5. Set the local admin password to blank
    6. Join a workgroup
    7. Select the Config Mgr client you created in step 4
    8. I generally don’t install updates in this phase but this is debatable. You must weigh time to deploy if you have to deploy a bunch of updates during deployment time vs. superseded updates and rebuilding your image more often.
    9. Don’t add any software to the base image
    10. Set your image properties
    11. Select a location to save the image and make sure you include the full path including the .wim extension
    12. Enter an account with rights to write to the share
    13. Finish up
  7. Change the task sequence to use “Quick Format”
    1. Right Click on the Task Sequence and choose Edit
    2. Select the “Partition Disk 0” step
    3. Choose properties on the Default (Primary) partition and check the “Quick Format” option
  8. Create a collection to which you will advertise the task sequence; I usually use _OSD\Base Builds
  9. Advertise the task sequence to the collection you created in step 7 as optional
    1. Right click Task sequence and choose advertise, follow the wizard
    2. Make sure you select the check box “Make this task sequence available to boot media and PXE”
    3. If you are in test and your boundaries are not defined make sure you select “When no local distribution points are available, use remote distribution point”
    4. Make sure you completed step 1
  10. Select a client to build your base image
    1. I suggest using a virtual platform to keep the drivers in the image at a minimum
    2. VMWare ESX is not a good candidate as a platform as it uses SCSI disks only to my knowledge. You do not want SCSI Mass storage drivers in your image, use MS Virtual Server / Virtual PC / Hyper-V or VMWare Server / Workstation
  11. Ensure that you have the network and mass storage drivers to boot the device on the boot image and in the driver store (If you have to do this in the future you must update the PXE and standard DPs)
  12. Add the appropriate boot images (x86 / x64) to the PXE and standard DPs
    1. If you don’t see a PXE DP it means you don’t have one :), get WDS installed and your PXE Service point
  13. Allow the client to boot from PXE
    1. If this client previously had an SCCM agent on it you just need to add the client to the collection you created in step 6
    2. If this is a new client and SCCM is pre-R2 add the client manually
      1. Add the client by right clicking the Computer Associations node under OSD and choosing “Import Computer Information”
      2. Enter the Name of the computer; I use XPBase
      3. Enter the MAC and or SMBIOS GUID
      4. Add the computer to the collection you created in step 7
    3. If you are using SCCM R2 you can enable unknown computer support on the PXE service point but choose wisely; option 10.2 may still be the best choice given the risk of accidentally formatting your CXOs laptop
  14. Boot the device up to PXE and choose your task sequence. In less than an hour you should have the start of a great XP Image

Adding Operating System Install Package Notes

Here is what I have seen as the most common issue when adding an operating system install package.

If you get the error “The specified directory does not contain a valid operating system or you do not have permission to access it. Please specify a valid source directory”. The most common cause is permissions. Remember that the SMS provider needs to access the share to import it which runs under the context of the computer account where the SMS provider runs. For most organizations this will be the computer account of the SCCM Primary Site server.

  • To correct this grant the computer account or a group that contains a computer account (the group you uses to grant access to the System Management container in AD would be great here) Read access to the share and directory.
  • Note that you will likely have to reboot the SMS provider computer if the computer account was not in the group you use above before it was last rebooted (the computer logs on to add during the boot process).

Great SCCM OSD Blog

I often get asked “Where can I get the best OSD information?”; well here is a great place to start and it answers so many of the common problems with beginners at OSD. Microsoft Inside OSD Blog

SCCM x64 vs. x86 Update

There has been much discussion on the Internet as to whether or not an SCCM server should be x64 or not. One of my very good friends is far more diligent about posting to his blog than I am actually posted much of my long standing opinion here. Much to Jarvis’s chagrin I am going to change my opinion in light of some recent discoveries.

Before I go any further I want to make sure there is a clear understanding about one thing. If you are doing anything but a very small SCCM installation (1000 devices or less) at the very least I would highly suggest offloading SQL to a remote box running x64. This will allow your SCCM environment to scale far better and ensure that SQL Reporting Services will be running remotely, which in turn when SCCM R2 ships will allow your reports to also run in x64. As a more strategic recommendation a strong consideration should be made for a large, centralized, redundant, x64 SQL environment. This type of environment if done properly can have dramatic affects on operational efficiency, costs and virtualization consolidation ratios (more on this in another post some day).

On to the topic at hand; there are two reasons that I no longer recommend x64 for the SCCM site server. First and foremost, if you are monitoring SCCM with SCOM (always a good practice) the SCOM agent will not be able to correctly monitor the 32 bit SCCM processes running on the x64 system. This will result in greatly degraded monitoring and alerting. To me this reason alone pushes me over the edge as SCOM monitoring of SCCM is mandatory in my opinion to maintain a smooth running SCCM site. Secondly, and this should be temporary. When SCCM R2 ships WDS on Server 2008 will allow for multicast distribution points. Currently in the beta the function does not work on an x64 Server 2008 box. While this support has been promised for RTM the fact that it is not in the beta makes me nervous.

For now I think that the safe bet is to install your SCCM site servers in x86 and allow those processes to run natively.