do not mess with WSUS or how to get crazy with software updates.

when you are configuring SCCM 2007 or SCCM 2012 it is stated on the TechNet and all blogs:

DO NOT MODIFY WSUS CONFIG MANUALLY!

Just install WSUS role and then SUP role. SCCM will configure everything it needs on its own.

it is also known by advanced users that yes, you can fine tune some things through WSUS console, but only when you've got enough experiance and you know exactly what you are doing.

why am i telling this?

a colleague of mine is involved with a customer for almost a year now. the IT guys there managed to set up SCCM 2012 on their own and it even works now, after we've spent a few month (re)configuring and fine-tuning it for all their needs. unfortunately they still don't know how SCCM 2012 works and is something happens they just blame SCCM for it and start nagging.

The last issue they've had was really weird - they are using Forefront as well and everything was fine until approximately a month ago the clients started receiving Forefront engine update that was causing system reboot. It is a health care organization and they can't afford unexpected or not announced desktop reboots. The strange thing was that this update wasn't approved on SCCM site. It wasn't even downloaded to a package. so... it was a big mess :O... the local IT disabled the ADR, they've even deleted and recreated it, and disabled again... configured update source location settings and so on... but nothing could help.

The local IT guys were going to make some dramatic decisions like completely wiping SCCM 2012 site server and reinstalling it from scratch of calling Microsoft Premium support, or may be even both of those steps (in the right sequence ;) )

Just before that happened, my college has decided to get involved and just take a look at complete chain of severs, clients and applications involved. After some deep digging in an affected client's logs, site server logs, lots of other logs, all the relevant SCCM 2012 console parts... he went to WSUS console, to look if he could find something "unusual"...

AND HE HAS FOUND IT!!!

WSUS has got "Default Automatic Approval Rule" and it was enabled!!!

well what can i say...

Back in SCCM 2007, when you wanted to automatically update Forefront clients from SCCM, you, indeed, needed to configure certain settings on WSUS server to make it work. but it is no longer the case with SCCM 2012, so do not do that!!!

unfortunately some wise guy had itch on his fingertips and didn't have proper understanding of what he was doing...

so, once again - DO NOT MESS WITH WSUS!

and of course - make sure you've got proper understanding of what you are doing and how it all works.

change Source Path(s) in ConfigMgr 2012

i was migrating a ConfigMgr 2007 site to ComfigMgr 2012 ...
basically you can use built-in migration tool and it should work...
and yes, it even works ... in most cases
and usually you don't have to do much things afterwards.

I'm not gonna cover all the possible pitfalls right now, but only a few regarding content source location.

as it has already been explained here and there, and amog others in the blog mentioned below, Migration Tool DOES NOT / CAN NOT change the content source path!


That's not a problem, we can simply use the script from Inframon Blog to bulk update package content source.
There is however one nasty issue with that script and it should be corrected - the script is using String.Replace and this is case sensitive. This won't change anything if your $source and PkgSourcePath contain even one letter in different cases.
But it is easy to fix by adding ToLower() just before Replace :)
below is the case insensitive version to replace package source path

=====================================================

$sitecode = "XYZ"
$source = "\\OLD_PATH\sccm_source"
$dest = "\\NEW_PATH\sccm_source"

$packages = Get-WMIObject -namespace "root\sms\site_$sitecode" -class SMS_Package
foreach ($package in $packages) {
  $id = $package.PackageID
  $single = Get-WMIObject -namespace "root\sms\site_$sitecode" -class SMS_Package -filter "PackageID='$id'"

  foreach ($object in $single) {
    $path = $object.PkgSourcePath.ToLower().Replace($source, $dest)
    $object.PkgSourcePath = $path
    $object.Put()
  }
}

=====================================================

This is it....
or not yet ;)

The script above will update only the package content source path, and what about the rest?

if you've got drivers - you'll have to update driver source path as well!
the following script is a modification of the above to replace driver source path

=====================================================

$sitecode = "XYZ"
$source = "\\OLD_PATH\sccm_source"
$dest = "\\NEW_PATH\sccm_source"

$drivers = Get-WMIObject -namespace "root\sms\site_$sitecode" -class SMS_Driver
foreach ($driver in $drivers) {
  $id = $driver.CI_UniqueID
  $single = Get-WMIObject -namespace "root\sms\site_$sitecode" -class SMS_Driver -filter "CI_UniqueID='$id'"

  foreach ($object in $single) {
    $path = $object.ContentSourcePath.ToLower().Replace($source, $dest)
    $object.ContentSourcePath = $path
    $object.Put()
  }
}

=====================================================

information about WMI calsses used:
SMS_Packages - http://msdn.microsoft.com/en-us/library/cc144959.aspx
SMS_Driver - http://msdn.microsoft.com/en-us/library/cc146249.aspx

Using information from TechNet you can modify anything you want ;)

Disclaimer: the scripts are provided as-is without any warranty or support!