Reinstalling a Management Point on a Secondary Site

I recently ran into an issue where one of my SCCM 2012 SP1 (Cu3) secondary sites that is hosted on a Hyper-V server had a corrupt management point after a power failure in the facility.

The SMS_MP_CONTROL_MANAGER showed the following errors when the site server came back online:


Since this site system is a Secondary Site I could not simply remove the role and re-add it (A management point is a requirement for a Secondary Site).  I decided to try the following before delving into reinstalling the Secondary Site.

This is an HTTP based Management Point so I first flipped it to HTTPS, which triggers a reinstall of the MP:


As you might expect, this results in a failure since IIS is not configured to support SSL.  This is fine as it is only a temporary measure.


I then flipped it BACK to HTTP, which once again triggers a reinstall of the MP:


My Management Point is now successfully reinstalled and no longer reporting errors.


Quick and painless!  🙂

Disclaimer: I have no idea if this is a “supported” process from Microsoft so you should research your issue thoroughly and contact MS Support if needed.

PowerShell: Modify Source Location for SCCM Drivers

I recently ran into an issue where eh hmm.. someone (not sure who but his initials are WB) imported a new set of drivers from a UNC path that was named incorrectly.  😐

To be exact, the directory was named “\\DFS\NameSpace\Share$\OSD\Win7\x64\DriverSrc\Lenovo S32_x64_R01” when in reality it was supposed to be “\\DFS\NameSpace\Share$\OSD\Win7\x64\DriverSrc\Lenovo E32_x64_R01″.

There are quite a few drivers that were imported for this particular model and there is no way in the console to bulk change the source path so after renaming the source folder to E32, off to PowerShell I went.

As you might guess I opened the PowerShell (x86) Console from the SCCM Admin Console (Still on Sp1 CU3 so no x64 PowerShell for me yet).

First I need to retrieve the driver objects that have the invalid path:
$Drivers = Get-CMDriver | Where-Object ($_.ContentSourcePath -like “*S32_x64*”}

This process takes a while as I have a lot of drivers.  If your really bored you can watch the SMSProv.log instead of stare at the PowerShell console waiting for the command to end.

Once the command completes I  have a new variable ($Drivers ) filled with all the driver objects I need to target to fix this mishap created by whoever that attention deficit admin was.  (*cough*).  For sanity sake I echo the contents out to the screen to validate I have only what I need in the variable:

$Drivers | Select-Object ContentSourcePath

I now know I have all the desired drivers that I need to modify.  My goal is to simply replace S32 with E32 in the existing path.  The command I used:

foreach ($driver in $xBackupDrivers) {$oldPath = $driver.ContentSourcePath; Write-Host “OLDPATH: $oldPath”; $NewPath = $driver.ContentSourcePath -replace “S32″,”E32”; Write-Host “NEWPATH: $NewPath”; Set-CMDriver -Id $driver.CI_ID -DriverSource $NewPath}

An easier way to read this:

foreach ($driver in $xBackupDrivers) {
    $oldPath = $driver.ContentSourcePath
    Write-Host “OLDPATH: $oldPath”
    $NewPath = $driver.ContentSourcePath -replace “S32″,”E32”
    Write-Host “NEWPATH: $NewPath”
    Set-CMDriver -Id $driver.CI_ID -DriverSource $NewPath

I have highlighted the commands that are doing the actual work.  I simply replace the text into a new variable and pass that to the “Set-CMDriver” cmdlet (Along with the driver CI_ID).

About 30 seconds later the drivers have the correct source path.  I’m now off to reprimand that SCCM Admin!


Boot Image Optional Components Explained

With SCCM 2012 there are many components you can now add directly from the SCCM admin console that allow you to enhance your boot image with extended capabilities (Such as Powershell!)  There are a variety of components to choose from, some easy to grasp what they add based on the name, others maybe not so easy.

Here’s a shot of the default x86 boot image (with default components).


Click the orange star to see the additional optional components you can add:


If you select new components to add you will be prompted to update your Distribution Points.  This is the process that combines the new components into your PE WIM file and distributes the updated WIM out to your DP’s.  You can always select no at this prompt and do it at a later time if you are super bandwidth conscious.

Here’s a TechNet article that describes each component in detail to help you determine if the added functionality is something you could utilize.  As a best practice, you should only add components you plan on taking advantage of to keep the size of your boot image as small as possible.  😉

SCCM 2012 Admin Console Sluggish?

Does your SCCM 2012 Admin Console feel sluggish even when running directly from the Site Server that has more resources than SCCM knows what to do with?

Although there could be other issues that contribute to this issue, one of the first actions you should take it make sure your Antivirus product is set to exclude the correct directories and files!  This can have a dramatic effect on your console performance.

A great article about recommended exclusions can be found here:

If your AV product is System Center Endpoint Protection, you can start your SCCM 2012 Server policy baseline with the included template.

Navigate to Assets and Compliance>Endpoint Protection>Antimalware Policies.  Right-click Antimalware Policies and select  Import:


Select “SCEP12_Default_CfgMgr2012.xml”


As you will see this will import many default recommended exclusions.  You should now follow the guidance in the post above to exclude the additional locations/files not contained in the default template.

Save and deploy this policy to your SCCM 2012 server(s).  😉

Any AV exclusion leaves your system open for potential infection.  You should evaluate your environment and determine what best meets your needs.

Upgrade guide for SCCM 2012 R2 (With known issues)

Johan Arwidmark has created a nice guide outlining the upgrade process from SCCM 2012 SP1 to R2/MDT 2013. This blog post also contains a few known issues with R2 and potential workarounds. A great read for those about to upgrade!

Create Prestage Content Failure and UAC

If like me, you don’t typically execute the SCCM Administrator Console with “Run as Administrator” option I think you are generally in good company. Day to day administration does not require you to elevate the admin console so rarely do I do so.

Today I needed to create prestaged content for a Distribution Point located on the other side of a pretty high latency, low bandwidth WAN connection to China.  (Cannot get a sizable Software Updates Package to successfully send to this DP, after several attempts, but that’s another story)

As I do every day I launched the Admin console (without elevation).  I navigated to the offending Software Updated package and walked through the “Create Prestage Content File” wizard.  Shortly after the process began, it failed.

After reviewing the {SCCMInstalDirectory}\AdminConsole\AdminUILog\PrestageContent.log I received the following error:

Creating prestaged content file failed due to user not having sufficient rights.

The obvious next step for me was to close and reopen the console as an administrator and viola, the process completed without error.