Posts tagged: sccm

SCCM: Content downloaded to the client does not match the content specified in the content source

comments Comments (4)
By , January 11, 2009 3:09 pm

There are some software packages that introduce a lot of interesting complexities that SCCM  2007 gets confused by. One of the applications that I was trying to test and deploy was giving me a particularly interesting problem: all of the clients downloaded the package, but when they checked the content, it did not match the source.

The error, which had an ID of 10057, was found by going to System Status -> Advertisement Status -> <advertisement name> -> Show Messages on the actions pane:

The program for advertisement “SIT00001 has failed because download of the content “SIT00029″ – “Per-system unattended” has failed. The download failed because the content downloaded to the client does not match the content specified in the content source.

Possible causes: The content on the distribution point has been manually modified, or a local administrator on the computer has modified the content in the computer’s hash. Solution: Refresh the content on the distribution point and retry the download.

The solution seemed obvious: update the distribution points. But multiple tries, including recreating the package and advertisement completely, did not fix the problem. Finally, I stumbled upon a forum post that helped me narrow the problem down to one of two scenarios:

Binary Differential Replication – If this is enabled in the package configuration, some packages seem to fail. I’m assuming that they can’t handle this kind of replication and several of the files become corrupt, creating a hash mismatch. This can be turned off by opening up the package properties, going to the Data Source tab, and unchecking Enable binary differential replication. This wasn’t my problem because I hadn’t enabled binary differential replication.

Hidden Files – Apparently, if the package source contains hidden files, SCCM may not calculate the correct hash for the package and clients could encounter an error. I found a quick way to check this using the command line:

  1. Open up a command window in the root director that contains your package source files.
  2. Type Dir /S /A:H and hit enter. Depending on the package, you may be presented with several directories with multiple hidden files.
  3. Trying to remove the hidden attribute on all the files with the GUI would be tedious, so just use this command instead: attrib -H /S
  4. Update the distribution points.

The package finally verified properly and the advertisement completed.


[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories System Administration, Troubleshooting, Work | tags , ,

Troubleshooting SCCM and BITS Downloads

comments Comments (25)
By , January 9, 2009 11:58 am

If you’re planning on using System Center Configuration Manager 2007 for its ability to distribute software over the internet and throttle large file transfers to avoid saturating the network, you may end up spending a lot of time scratching your head when packages start downloading to a client and then suddenly stop.

Such was the scenario I experienced while testing BITS with one of the applications we plan to deploy to clients. The client machine would begin the transfer and start the download… and then stop. Even worse, the issue never resolved itself, even when the machine was left running overnight. Since the issue was less-than-obvious (hint: It was not SCCM that was misconfigured) I decided to list a few tips in the BITS troubleshooting process that may be of use to others. Continue reading 'Troubleshooting SCCM and BITS Downloads'»

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories System Administration, Troubleshooting | tags , , ,

Deploy Vista install.wim on any drive you like (as long as it’s D:\)

comments Comments (0)
By , December 3, 2008 11:34 am
Source: xkcd.com

Source: xkcd.com

While designing and testing a deployment process for Windows Vista using System Center Configuration Manager 2007 I ran into a seemingly obscure problem: Vista refused to use drive letter C as the OS Volume and instead chose D as the system drive letter. The result is that the root of the system drive was D:\ instead of C:\, which is something that legacy applications are not fond of.

This would seem like an easy problem to resolve. Surely, it is caused by the way the disk is partitioned or perhaps the drive letter that SCCM applies the image to is incorrect. Perhaps it’s a registry setting in the image file that needs to be modified offline. I experimented with all of these things, with no luck. Finally, I came across a technet blog entry that I had missed with previous Google search queries:

Several people have tried to use the install.wim from the Windows Vista installation media in an Install an existing image package task sequence.  They are surprised to discover that, upon completion, the operating system is on the D: drive instead of the C: drive. The short explanation for why this happens is that the operating system volume for the images in install.wim is D:.  In other words, when the image was captured, the reference machine had the operating system on volume D:.  Why this is the case for the install.wim that ships on the Windows Vista installation media is beyond the scope of this blog.

So essentially, you can’t use the install.wim image from Vista in SCCM if you want to use C for the system drive letter. That would have been nice to know….

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories OS Deployment, System Administration, Troubleshooting | tags , , , , ,

Panorama Theme by Themocracy