ConfigMgr Content Source Path migration

No Gravatar

Several ConfigMgr scenarios require that the content Source Path be changed.  This typically includes migrating to a new ConfigMgr environment (2007 to 2012, 2012 to Current Branch, etc.), and simply moving the source content to a new location such as a DFS Share or low-speed NAS device.

Updating the Source Path can be done manually via the ConfigMgr console.  For Packages, Software Update Deployment Packages, Drivers, Driver Packages, Operating System Images, Operating System Upgrade Packages, Boot Images, and Virtual Hard Disks, just add the Pkg Source Path or Package Source Path column to the console view to review the paths, then edit the object’s Source Folder in the Data Source tab.

However, for Applications, you’ll have to step through each Deployment Type on each Application, view the properties and modify the Content Location in the Content tab.

This is all painfully slow if you have more then a handful to deal with.  So, automate it!

image image

The community has developed at least 5 solutions to this including

CoreTech and Nickalaj have the slickest solutions.  Sometimes a GUI gives the visual feedback you need to be confident in the final outcome.

158_1 image

Either of these two tools should effectively handle the changes.  As a bonus, both will actually copy the content files from the old to the new path.  Awesome!

Happy migrating!

September 28, 2016

Posted In: ConfigMgr 2012, Scripting

Tags:

ConfigMgr Status Message Viewer MFC120u.dll Missing Error

No Gravatar

 

When the ConfigMgr Admin Console version 2012 SP2 (or 2012 R2 SP1) is installed and the ConfigMgr client is not updated on the same computer you could see an error like the one below.

image

statview.exe – System Error

The program can’t start because mfc12u.dll is missing from your computer. Try reinstalling the program to fix this problem.

 

StatView is the utility that displays ConfigMgr status messages and is typically initiated from the console by navigating to

  • Monitoring \ Overview\ System Status \ Site Status
  • OR Monitoring \ Overview\ System Status \ Status Message Queries

StatView.exe requires Microsoft Visual C++ and ConfigMgr 2012 SP2 now uses VC++ 2013 which is not installed as part of the Console.

 

To resolve the issue, install Microsoft Visual C++ 2013 Redistributable (x86) which can be found at \client\i386\vcredist_x86.exe">\client\i386\vcredist_x86.exe">\\PrimarySiteServer\SMS_<SiteCode>\client\i386\vcredist_x86.exe.  Notice that the x86 version is required even if you are running Windows x64.  This is because StatView is a 32-bit application.

image

This will install and register mfc12u.dll and other files which should resolve the issue.

 

You can verify the installation in Programs and Features (Add/Remove Programs) as shown below.

image

Microsoft Visual C++ Redistributable (x86)…

 

Problem. Solved.

September 24, 2015

Posted In: Uncategorized

Tags:

What’s my ConfigMgr version: 2012 SP2 or 2012 R2 SP1?

No Gravatar

I’ve been installing a few lab and production ConfigMgr environments recently and found a little quirk with the versioning to go along with the service pack madness / confusion of the 2012 SP2 / 2012 R2 SP1 release.  Here’s the scoop:

After installing ConfigMgr 2012 SP2 as a new / fresh install, how do you know if R2 is installed?  There are really only two ways I can find:

  1. Launch the Configuration Manger Admin Console and check the about screen.  The console version will be 5.0.8239.1000 and the site version 5.00.8239.1000 for both SP2 / R2 SP1; however the product name will show “System Center 2012 R2 Configuration Manager SP1” or “System Center 2012 Configuration Manager SP2” to indicate the difference.
  2. Review the 2012 R2 release notes (What’s New in System Center 2012 R2 Configuration Manager) and note the new features.  If these exist within the Admin Console on the connected site, then R2 is installed.  Probably the easiest check is in Software Library –> Operating Systems –> Virtual Hard Disks.  The VHD feature set is part of R2 and won’t exist in a non-R2 site.

 

image

 

Some additional details

Where can the R2 installer be download from?

  • If installing ConfigMgr 2012 SP2 / 2012 R2 SP1 from evaluation media, you’ll easily notice that there are 2 files to download and install.  The small (1.1 mb) file is the “R2” installer / enabler.  Otherwise the code base is identical between the versions / editions.
  • If installing from MVL media, the small “R2” installer may not exist for download.  I’ve only see 1 company’s MVL site and the file didn’t exist in any place we could think to look.  Installing “R2” from the evaluation file, SC2012_R2_SP1_ConfigMgr.exe, worked fine on multiple MVL installed sites.

When I installed R2, there were almost no indications of the change.

  • The actual install, ConfigMgr2012R2SP1.msi did not generate a log file that I could find
  • The Windows Application Event Log did show that “Product Name: Microsoft System Center Configuration manager. Product Version : 5.00.8239.1000 … Reconfiguration” succeeded, but notice that the name does not identify SP2 or R2 SP1.
  • C:\ConfigMgrSetup.log was not changed
  • C:\ConfigMgrAdminUISetup.log was not changed
  • C:\ConfigMgrAdminUISetupVerbose.log was not changed
  • I could see no entries in any ConfigMgr site logs that gave any reference to a change
  • I could see no changes in the Windows Registry at HKLM\Software\Microsoft\SMS\*
  • The site properties in the Admin Console showed no changes
  • Re-running the R2 installation gave no indication that it was already installed
  • Re-running the R2 installation (ConfigMgr2012R2SP1.msi) with verbose logging did create a log file but there was no indication that it was already installed
  • Windows Programs and Features (Add / Remove Programs) did not change the product name

 

So much for clarity!

June 16, 2015

Posted In: Uncategorized

Tags:

BITS error 0x80200013 during ConfigMgr client installation

No Gravatar

When attempting to install the ConfigMgr / SCCM client on a few remote computers, the installation failed (more like stalled out) when ccmsetup.exe tried to download the full client binary files.  The download couldn’t complete and the following error was generated:

Failed to download files through BITS. Error: 0x80200013, Description The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

I discovered that Microsoft KB922330 describes the issues and a workaround.

You may experience this problem if a computer is behind a firewall or behind a proxy server. This problem occurs if one of the following conditions is true:

-The proxy server environment does not support the HTTP 1.1 range request feature.

-You are behind a SonicWALL firewall device, and the Enable HTTP Byte-Range request with Gateway AV setting is not enabled for the device.

When you copy a file by using BITS in background mode, the file is copied in multiple small parts. To perform this kind of copy operation, BITS uses the HTTP 1.1 Content-Range header. If you are behind a proxy server or behind a firewall that removes this header, the file copy operation is unsuccessful.

Note When BITS copies files in foreground mode, BITS does not use this header.

Interesting… changing the BITS priority will work around the issue and it just so happens that we can control that in the ConfigMgr client installation. 

Running ccmsetup.exe /BITSPriority:FOREGROUND did work around the BITS error during client installation.  The client successfully installed and registered with the Primary site.

We could also manually copy all of the installer binary files locally and use the /SOURCE parameter as another alternative.

 

Success!… well, not so fast.

 

From an ongoing operations perspective not much was gained.  Although Client Settings allow controlling BITS throttling, it cannot control BITS priority.  About a year ago the question about controlling BITS priority from a ConfigMgr content distribution perspective was asked on the TechNet forums and the product team did confirm that it isn’t a current feature.

 

It looks like the firewall or proxy server will have to be kicked in the shins after all.

 

Follow-up

I stumbled on to an interesting post by the 2PintSoftware guys whom have been doing A LOT of great work with BITS and BranchCache recently.

If I set the BITS Throttling Rate in SCCM, does it apply to all downloads?

Oh no. That would be too simple. Remember that the client setting in SCCM is for Background transfers only. So if you make a deployment ‘Available’ as opposed to ‘Required’, then it will be a BITS Foreground transfer that is created and it will attempt to use whatever bandwidth it can get it’s grubby little hands on.

http://2pintsoftware.com/2psfaqs/bits-throttling

So it appears that ConfigMgr does know about BITS priorities beyond the ccmsetup.exe scope, but you still can’t change it.

May 21, 2015

Posted In: Uncategorized

Tags:

Unexpected reboot upgrading ConfigMgr Admin Console

No Gravatar

Yesterday I upgraded my ConfigMgr 2012 R2 lab to SP1 and encountered a small bit of trouble.  During the SP installation the Admin Console failed to uninstall; during installation the MSI performed an unexpected reboot.

Scenario

  • The primary site server had recently been upgraded to CU5 for ConfigMgr 2012 R2 but had several reboots since.
  • As far as I can remember the Admin Console was not running when the service pack installation began, nor any time during the installation.
  • The Admin Console failed to uninstall during the service pack installation.
  • After the service pack installation, a manual reboot was performed.
  • The Admin Console was reinstalled via command line.  The MSI return code of 1641 was generated and MSI automatically rebooted the server.

Details

Below are some details captured from the installation logs.

in C:\ConfigMgrSetup.log

INFO: AdminConsole will be deinstalled first for upgrade – "E:\Program Files\Microsoft Configuration Manager\bin\I386\ConsoleSetup.exe"/uninstall /q.

ERROR: Configuration Manager console uninstallation failed. Check log file ConfigMgrAdminUISetup.log.

WARNING: Configuration Manager console installation failed. ConfigMgrAdminUI.log has further information.

in C:\ConfigMgrAdminUISetup.log

5/14/2015 2:46:55 PM   MSI: Another application has exclusive access to the file ‘E:\Program Files\Microsoft Configuration Manager\AdminConsole\AdminUILog\CMSitePSProvider.log’.  Please shut down all other applications, then click Retry.      

5/14/2015 2:46:55 PM   MSI: Action 14:46:55: Rollback. Rolling back action:

5/14/2015 2:46:55 PM   Installation failed with error code 1603

The server was manually restarted

The Admin Console installation was initiated via command line from an elevated PowerShell ISE session.

"E:\Program Files\Microsoft Configuration Manager\Tools\ConsoleSetup\ConsoleSetup.exe" /q TargetDir="E:\Program Files\Microsoft Configuration Manager\AdminConsole" EnableSQM=0 DefaultSiteServerName=LAB-CM.lab.local

In ConfigMgrAdminUISetup.log

5/14/2015 3:28:56 PM   MSI: You must restart your system for the configuration changes made to System Center Configuration Manager Console to take effect. Click Yes to restart now or No if you plan to manually restart later.    

5/14/2015 3:28:56 PM   Installation succeeded. Windows Installer has initiated a reboot.

*Notice that the time difference in the 2 log lines in <=1 second.  Also, no visible prompt was generated asking about a reboot.

In ConfigMgrAdminUISetupVerbose.log

MSI (s) (78:04) [15:28:56:261]: Windows Installer installed the product. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0.

MSI (s) (78:04) [15:28:56:261]: Value of RebootAction property is

MSI (s) (78:04) [15:28:56:261]: Windows Installer requires a system restart. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Type of System Restart: 1. Reason for Restart: 1.

MSI (s) (78:04) [15:28:56:261]: Closing MSIHANDLE (1) of type 790542 for thread 5124

MSI (s) (78:04) [15:28:56:261]: Deferring clean up of packages/files, if any exist

MSI (s) (78:04) [15:28:56:261]: MainEngineThread is returning 1641

MSI (s) (78:98) [15:28:56:261]: RESTART MANAGER: Session closed.

 

Hopefully no one else runs into this scenario.

May 15, 2015

Posted In: ConfigMgr 2012

Tags: