ConfigMgr 12

ConfigMgr 2012 R2 PowerShell to Install SMP Role

Posted on Updated on

In a recent customer engagement, we needed to mass deploy the State Migration Point (SMP) role to nearly 70 servers.  After completing about a dozen of these one by one, I thought PowerShell would be a much faster way to accomplish the end goal.  The below script can be used as an example for finding existing site systems that do not have the SMP role installed, while allowing it to skip servers with certain names (in this example, it skips servers that begin with TEST in the name).


import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')
# Site Code + :
$SiteCode = "GAL:"
Set-Location $SiteCode

#Properties for Setting the SMP Role
$UsmtDrivePath = "F:\USMT"
$MaxNumClients = 100
$MinFreeSpace = 3
$TimeDeleteAfterDays = 5

$SiteSystemServers = Get-CMSiteSystemServer
write-host $SiteSystemServers.Count

ForEach ($Server in $SiteSystemServers) {
    $ServerName = $Server.NetworkOSPath.Replace("\\", " ")

    $CheckSMP = Get-CMSiteRole -RoleName "SMS State Migration Point" -SiteSystemServerName $ServerName
    #write-host $CheckSMP.Count

	# If SMP Count is zero, SMP not installed
    If ($CheckSMP.Count -eq 0) {
        If ($ServerName.ToUpper().StartsWith("TEST")) {
            # Do Nothing, skip this type of server
        } Else {
            Write-host "No SMP Role, installing on" $ServerName

            $Folder = New-CMStorageFolder -StorageFolderName $UsmtDrivePath -MaximumClientNumber _
				$MaxNumClients -MinimumFreeSpace $MinFreeSpace -SpaceUnit Gigabyte

			Add-CMStateMigrationPoint -SiteSystemServerName $ServerName -StorageFolder $Folder _
				-AllowFallbackSourceLocationForContent $False -EnableRestoreOnlyMode $False -SiteCode $SiteCode _
				-TimeDeleteAfter $TimeDeleteAfterDays -TimeUnit Days
    } Else {
        Write-host "SMP Role installed, skipping server" $ServerName

Finding ConfigMgr Collections with Queries

Posted on Updated on

Using ConfigMgr 2012 R2 (and newer), the following PowerShell script can be used to identify which device collections have a query in them, and those that do not.

Example output:



import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')
# Site Code + :
Set-Location "GAL:"

$CollectionList = Get-CMDeviceCollection

ForEach ($Collection in $CollectionList) {
    $RuleName = (Get-CMDeviceCollectionQueryMembershipRule -CollectionId $Collection.CollectionID).RuleName

    If ([string]::IsNullOrEmpty($RuleName)) {
        write-host "NO Query: " $Collection.CollectionID "," $Collection.Name -foregroundcolor Red
    } Else {
        write-host "YES Query:" $Collection.CollectionID "," $Collection.Name ", Query name:" $RuleName

Observations with CU2 install for ConfigMgr 2012 R2 SP1

Posted on Updated on

Recently I updated a customer’s ConfigMgr 2012 R2 SP1 environment with Cumulative Update 2.  It was not exactly a jovial experience, so I thought to share some of the pain points that were experienced.

  1. Total time for CU install was 30 minutes on the primary, with the console update taking the longest time.  Remote console updates took about 15 minutes.
  2. The Release notes say no restart is required, however after the installation, the wizard says a restart is required to complete the changes.
  3. After upgrade/restart, the distribution manager was unavailable…for about 15 minutes.
  4. At that point, ConfigMgr began automatically upgrading all pull DPs with a newer installation.  This is not documented in the release notes that an auto upgrade would happen.
  5. The package transfer manager was locked and unavailable for not quite 2 hours, so content could not transfer.
  6. Some pull DPs failed to upgrade, which is shown in the distmgr.log as well as in the DP Configuration Status.  This also broke communication with SMS Executive on the failed DPs.
    1. The only commonality that I can find that these DPs are all on Windows Server 2008 (non-R2).  However, other DPs on that server were OK.
    2. Distmgr.log also showed error “Failed to copy vcredist_x86.exe to \\server\SMS_DP$\sms\bin\vcredist_x86.exe. GLE = 32”. The vcredist_x86 file had multiple open instances showing in task manager, which needed to be terminated so that the file could be deleted from the bin directory.  Ending those open processes allowed the install to continue.
  7. The CM client package and upgrade package automatically updated across the organization … But there were zero new files in the client install folder.
  8. Buried in the release notes is a post-install task to update the DP for all boot images.

ConfigMgr 2007 to 2012 R2 – Hung Conversions

Posted on Updated on

Recently when helping a customer migrate to ConfigMgr 2012 R2 SP1 + CU1, the site had major problems with fully completing DP upgrades.  First, it would start the uninstall of a CM07 secondary site, then do nothing.  So we would restart the process to which it reassigns the DP and then stalls again…but even worse, it never completed the process and it couldn’t be restarted again.  So the status never came to a full completion and the old content (SMSPKG, PCK files, etc.) were not removed.  Additionally, the state of the migration status never went beyond “Reassigning distribution point” as in the image below.


Ultimately I had to engage Microsoft to get an answer.  Even they had to dig through the SQL stored procedure (sp_MIG_ UpgradeDistributionPoint) to understand for themselves what the conversion process does.  Essentially the stages boil down to these high-level steps:

  1. Uninstall of the 2007 components, then delete the values in MIG_DistributionPointSource in the database
  2. Drop a .dpu file into the  (for more info, see TechNet article “DP converts, but content fails“)
  3. Convert DP values of various package and DP mapping values in SQL
  4. And finally, set the DPUPgrade status where Action=2 and Status=0 for complete.  The example below shows an incomplete “hung” state of a DP with Action=2 and Status=1.


To get these statuses, the following SQL query was used so that we would know when the remote server had completed the uninstall of the secondary site and was ready to have a manual .dpu file dropped in to initiate the content conversion.

-- Result must be empty
select * from MIG_DistributionPointSource where PKGServer like '%ServerName%'

-- Result must have content listed
select * from PkgServers_G where NALPath like '%ServerName%'
select * from PkgServers_L where NALPath like '%ServerName%' 
select * from PkgStatus where PkgServer like '%ServerName%'
select * from ContentDPMap where ServerName like '%ServerName%'
select * from DistributionStatus where DPNALPath like '%ServerName%'

-- Result must have Action=2 and Status=1 to know server is ready to convert content
select * from DPUpgradeStatus where NALPath like '%ServerName%'

-- Use the DDPID number to create the .dpu file name
select * from DistributionPoints where ServerName like '%ServerName%'

The secondary site conversion woes occurred in primarily three ways:

  • First problem – a rerun the stored procedure did not occur after the uninstall of 2007 components.  While this is still unsolved and would take ‘significant’ effort to diagnose the cause, PSS provided a query to identify if the site is ready for the content conversion by creating a dummy .dpu entry.
  • Second problem – A manual restart of the conversion tools led to the system having a “failed to convert content”.  This was occurring because a couple dozen of the packages had mysteriously updated their source files, so there is a hash mismatch between 2007 and 2012.  The solution will be to delete those identified packages in 2012, re-migrate from 2007, and then restart the failed DP conversion (or drop a dummy .dpu)
  • Third problem – On a “completed” DP, files were leftover on the DP, both the PCK and extracted SMSPKG$ files.  Since we did not migrate ALL packages that were on the 2007 DP into 2012, those files are left behind such that they still could be converted at some point if desired.  Otherwise they need to be manually deleted after the conversion process completes.  Then, any package that had a CM07 advertisement that is set to “run from server” will migrate over to CM12 with the option to “Copy content to a package share on DP” – meaning the files in the SMSPKG$ share will remain.  These files should not be deleted from the SMSPKG$, but rather it would be better to change the package setting to not copy the contents (if appropriate for that package).

Why update ConfigMgr clients after upgrades?

Posted on Updated on

I was recently asked by a couple of friends, is it required for me to update my ConfigMgr clients after upgrading my site?  Intuitively I knew the answer and the why, but they need “proof” or documentation from Microsoft that stated it as such.  It was a bit of a needle-in-the-haystack to find, but the following reference on TechNet illustrates the case.

From the guide for Planning to Upgrade System Center 2012 Configuration Manager, in the upgrade checklist, the last step is to Upgrade Clients.

“After you upgrade a primary site, plan to upgrade clients that are assigned to that site. Although a Configuration Manager primary site or secondary site can support communication from clients that have a lower service pack version (including clients that run Configuration Manager SP1 talking to a site that runs System Center 2012 R2 Configuration Manager), this communication should be a temporary configuration. Clients that run a previous service pack version of Configuration Manager cannot use the new functionality that is available with the new version of Configuration Manager.”

ConfigMgr 2012 Site Migration – No Shared Distribution Points

Posted on

Recently when helping a customer with a ConfigMgr 2007 to 2012 R2 upgrade and migration, we were planning to upgrade their secondary sites to standard DPs.  When setting up ConfigMgr 2012 R2 migration tools in the console, none of secondary sites were showing as being available for DP sharing.  In reviewing the site’s migctrl.log file, there was an entry for an error that stated  “The DP is NOT eligible for sharing because no ports between the legacy site and the current site are the same.”


In this case, the customer had configured the 2007 primary site to have clients communicate on a custom port, and not use the standard default port 80, of which the 2012 primary site was configured to use.


By changing 2012 to also use that same custom port, re-running the source hierarchy gathering process, the migration tool (and migctrl.log) now displayed the secondary site servers available for upgrade.

ConfigMgr 2012 R2 – Remote SUP

Posted on Updated on

When setting up ConfigMgr 2012 R2 to use a remote server to host the Software Update Point on Windows Server 2012 R2, configuration of the SUP may fail.  The WCM.log will show entries such as:

Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608)
Checking runtime v2.0.50727...
Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701
Checking runtime v4.0.30319...
Did not find supported version of assembly Microsoft.UpdateServices.Administration
Supported WSUS version not found
Remote configuration failed on WSUS Server

The error implies that WSUS 3.0 SP2 is required for the remote SUP, however it is not for Windows Server 2012 R2.  Rather, since the SUP is on a remote server, the WSUS admin console server feature is required to be installed on the primary site server.