IT Bits and Pieces

Solutions and tips to every day IT problems

Category Archives: Configuration Manager

System Center Configuration Manager

SCCM Client Installation using PowerShell and PSExec

· · 4 Comments

There are a lot of ways to install the SCCM client: automatic client push, push via the console, GPOs and many more. I will be sharing here a simple PowerShell script meant to be run interactively. The script will install the SCCM client using a batch file stored on a file share accessible to all machines.

PSExec is part of Microsoft Windows Sysinternals PsTools and can be obtained here. For those who are not familiar with it, it is a powerful tool used to remotely execute commands on remote machines. It should be placed in an Execution subfolder compared to where the PowerShell script is placed, otherwise, modify the code to point to where PSExec is actually located.

The full script is below. Many lines have comments in them to make the script easy to read. I will further explain some code as well. Watch out for the & sign being converted to & by WordPress:

The script first asks the user(s) running it if they would like to use a list of machines as input or specify a single manual entry to install the SCCM client on.

If the user chooses to use a list input, the script checks for the presence of a file named Machines.txt that should be located in the same folder as the PowerShell script. The script then renames output log files from previous runs to avoid overwriting them, retrieves all the machine names from the Machines.txt file and asks the user for confirmation before proceeding since the number of machines could be large.

SCCM Client Installation Confirmation

If the user confirms, the script will perform two actions. The first is to attempt to remove a scheduled task which is present due to a bug in SCCM 2012 R2 for versions prior to SP1.

The scheduled task is named Configuration Manager Client Retry Task and the bug probably exists due to an oversight that places this scheduled task in the scheduled tasks folder Microsoft\Microsoft\Configuration Manager instead of Microsoft\Configuration Manager where all the other SCCM client related tasks are.

Microsoft confirmed that this behavior has been fixed in SCCM 2012 R2 SP1. Unfortunately, they also confirmed that no hotfix exists for pre-SP1 version, you either have to fix it manually as the script does, or upgrade to SP1 to squash the bug. As Windows 10 becomes more relevant, you would want to upgrade to SP1 (and CU2) soon in all cases.

In the next step, the PowerShell script uses PSExec to remotely execute the batch file responsible for installing the SCCM client. The batch file consists of ccmsetup.exe with any additional parameters that are needed in your environment. We used the batch file as well to copy all the client setup content locally before launching ccmsetup in our environment. The script will monitor the return from PSExec to determine if the setup was successfully launched on the target machine.

If the exit code was ‘0’, PSExec remote execution was successful, if not, it failed in launching the SCCM client setup. The script will track the number of successes and failures and will report at the end of the execution the total numbers.

SCCM Client Install Results

Manual entry is similar in behavior, it will ask the user to input a machine’s name and will proceed to perform the same two actions and monitor PSExec remote execution attempt. In the end, the user running the script is asked if they would like to run the script again or exit the session.

As you can see, the script is simple in nature and there is a lot of room for improvements if desired. For example, parallel execution can be implemented to speed up the process of installing numerous SCCM clients or log files for SCCM client setup can be monitored. Feel free to improve the script as you wish.

Distribution Point Migration Stuck on Reassigning Distribution Point

· · Leave a comment

During the course of migrating SCCM 2007 distribution points to SCCM 2012, I encountered a problem where a currently migrating DP would get stuck on “Reassigning Distribution Point”. The process would seem to stall and no errors are shown. The distribution point would show up in the console, its configuration can be modified, content can be distributed to it, and any other action can be performed. Content conversion never starts.

The Distribution Point would show up as if its configuration was finished.

DP Configuration information from the SCCM Console - DP Stuck on Reassigning Distribution Point

I checked several logs for an indication of any problem. Migmctrl.log shows that the uninstallation of the secondary site was correctly detected after running a data gather. Several SQL stored procedures are executed to update the boundary group, NALPath and to start the upgrade process. No errors in the process are logged. (The green color in the screenshot is highlighting the DP server name)

DP Upgrade Migmctrl

Distmgr.log shows also that everything is progressing as normal. It picks up the updated NALPath, successfully connects to the DP, installs IIS and the DP role, queues up 2007 packages for processing and basically every other action that should occur during a distribution point migration. Several log snippets are shown in the screenshot.

Distmgr log file showing the migrated DP being configured - DP Migration Stuck on Reassigning Distribution Point

Checking the Distribution Point itself shows that the needed folders have been created, those two default packages have been sent to it and smsdpprov.log shows corresponding entries to all those actions. Content conversion however never starts and the DP remains in a “Reassigning Distribution Point” state. Querying the DPUpgradeStatus table shows as well a “Reassigning Distribution Point” state (Action is 2 and Status is 1).

I went over the logs trying to troubleshoot the issue but I could not find any indication of a problem occurring. A Technet article by Andre Della Monica detailed the process of reassigning a distribution point. I also could not find any information applicable to our case in the article. We opened a support case with Microsoft and were advised that this is a recently discovered bug in the migration process. Due to timing issues with the process, the command to upgrade the distribution point does not get executed in rare cases and the migration stalls. Microsoft is aware of this and are working to address it.

The workaround was simple and involved executing again the sp_RestartDPUpgradeProcess stored procedure on the stalled distribution point. The same SQL stored procedure can be seen executing in the Migmctrl.log screenshot above.

After executing the above stored procedure, content conversion started and distribution manager began instructing the migrated distribution point to convert the content.

Logs showing content conversion in progress - DP Stuck on Reassigning Distribution Point

The solution is this article is provided as is and should be used at your own risk, always take backups of your SCCM databases before attempting any modification and test any solutions first. Contact Microsoft for assistance if in doubt.

SCCM Distribution Point Migration SQL Views and Status

· · Leave a comment

One of the latest projects involved automating thousands of distribution point migration jobs. One of the runbooks in the Orchestrator automation for this project involved monitoring the progress of the migration jobs. The SCCM database has a view that tracks this progress and is an actual reflection of the status you see in the “Distribution Point Migration” section in the console.

The view is dbo.v_MIG_Job and this view combines data from several SQL tables, two of which are dbo.MIG_Job & dbo.DPUpgradeStatus. These two tables contain status updates about the distribution point migration jobs currently in progress as well as past migrations. As noted above, the console reflects that status and querying the v_MIG_Job view is a quick way to programmatically find the status of a migration.

Distribution Point Migration Progress

The upper section shows the current status from the SCCM console while the lower part shows the SQL query and the result of that query. Additional columns exist in that view and can be queried if needed.

Below is a list of common values for the status column as well as the respective description:

Status ValueDescription
0Not started
2In progress
3331Pending on secondary site uninstallation
3074Reassigning distribution point
2561Completed update binaries
2562Updating binaries
2818Converting content
3073Completed reassign distribution point
2819Failed to convert content
515Failed (Network Timeout)
2563Failed to update binaries
3075Failed to reassign distribution point

The values and their description are self explanatory. “Pending on secondary site uninstallation” occurs if the distribution point being migrated is also a secondary site, the job will remain in this state until a data gather runs and SCCM picks up that this site server no longer exists in the migration source. You can start a synchronization of the source site from the console or through PowerShell by running:

This will initiate a Gather Data on all the sources configured in the source hierarchy. Depending on the number of source sites, packages and other data, this could take a very long time. If you would like to gather data from only one source site through SCCM PowerShell cmdlets, unfortunately, Microsoft does not yet have a cmdlet to accomplish that and Sync-CMMigrationSource does not accept parameters. However, you can accomplish this by using WMI in a PowerShell script:

This will allow you to sync a particular source site of your choosing if you desire so.

Back to the status values in the SQL view, the Runbook to detect them was created by implementing a PowerShell function that can be called to provide a continuously updated distribution point migration status. I used the return values to monitor the progress and perform further automated configuration changes such as setting rate limits and adding the migrated distribution point to a DP group once the migration was finished (more on this in a later article).

A PowerShell script was implemented to make use of this function and to track the status changes as well as perform actions and log updates as needed.

SCCM 2012 Software Center error 0x80041013

· · 2 Comments

After migrating SCCM clients from 2007 to 2012, the Software Center console on some of the migrated clients would open and displays an “error 0x80041013” message: “Loading Software Center returned error code 0x80041013 (-2147217389).”

Software Console Error 0x80041013

Examining the problematic systems revealed that the old SCCM 2007 client was not fully or properly removed, evident by files still remaining behind, one example being C:\Windows\SysWOW64\CCM. CCMSDKProvider.log was also logging exceptions being thrown about a WMI Provider load failure:

CCMSDKProvider Exception

After some troubleshooting, it turned out that one of the earlier 2007 DLL files was still present in the registry and this problem seemed to affect 64-bit machines only.

We reached that conclusion by running WBEMTest and connecting to root\ccm\clientsdk (as evident by the log file above) and enumerating the classes present. The WMI provider for them had a CLSID of {555b0c3e-41bb-4b8a-a8ae-8a9bee761bdf} as shown below:

WBEMTest CCM SDK Error 0x80041013

We searched the registry for this CLSID. Checking HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{555B0C3E-41BB-4B8A-A8AE-8A9BEE761BDF}\InProcServer32 showed that “Default” still had a value of “C:\Windows\SysWOW64\CCM\dcmsdk.dll” which is from the 2007 client. We blanked the value present.

We checked the second “Default” value present in HKEY_CLASSES_ROOT\CLSID\{555B0C3E-41BB-4B8A-A8AE-8A9BEE761BDF}\InProcServer32 and found it contains the proper value for the 2012 client: “C:\WINDOWS\CCM\ccmcisdk.dll“. After blanking the first value mentioned above, the Software Center started to open and function properly without any errors.

SCCM Detection Clauses Using Scripts

· · 5 Comments

Implementing SCCM detection clauses using scripts allows an administrator to flexibly define detection methods, especially when dealing with manually defined applications and deployment types. The scripting potential and capabilities are virtually limitless. SCCM supports scripting using PowerShell, VBScript or JScript.

I was recently supplied with an application to be distributed though SCCM. The files initially provided did not respond to any command line switches for silent installation. I requested from the supplier to provide setup files capable of being installed without user intervention. They did, though the behavior was erratic:

  • The initial application setup is launched by running “Setup.exe /s”
  • This setup file in turn launches a setup.exe file located in a subfolder
  • This second setup launches in turn an IKernel.exe setup file for InstallShield installer
  • Setup file in the first point terminates directly after launching the second setup, even before the actual installation is finished

Moreover, as shown in the bullets, the setup file was an .exe file. I started by creating a package using the Setup.exe file as shown in the guide published previously. I created detection clauses based on File Detection rules.  The application was deployed to several test machines.

The setup behavior caused problems with SCCM detection of the installation status since it monitors the return codes of the initial setup file which is terminating before the end of the installation. As shown in the screenshot, SCCM tries to detect the application after five seconds of launching the deployment, which corresponds to when the primary setup file finishes execution:

SCCM Detection Failure - SCCM Detection Clauses Using Scripts

This is by design since SCCM monitors the return codes for the setup file it launches. This was reflected in the SCCM console showing installation failure due to application files not being detected after deployment. The actual installation however was still running in the background and it finishes successfully. The application deployment will eventually be retried. Two scenarios can occur:

  1. If the installation is retried while the first one has not finished yet, multiple instances of the setup will now be active causing unpredictable behavior
  2. If the installation is retried after the entire setup has finished, the application will be detected as already installed causing wrong reporting in the console (Already Compliant status instead of Success)

Knowing that simple file detection will not suffice, I attempted to use a custom script to provide the required file detection. SCCM expects a certain output from the script to properly determine the application state as shown in this Technet article. The most relevant sections are highlighted in red:

SCCM Custom Script Output

In this case, the script needs to exit with a “0” exit code and have some data written to the standard output stream to indicate application presence. Exiting without writing anything to STDOUT or STDERR indicates the absence of the application files.

The script needs to detect the application files and wait for the background setup file to finishes. Starting from this Technet Blog, the following VBScript was written to achieve the needed file detection clause:

‘Declare needed variables
Dim FSO, File, WaitTime, TotalWaitTime

‘ Initialize constants
Const InitialTime = 30000
Const Delay = 60000
Const Timeout = 600000

‘ Set inital values
Set FSO = CreateObject (“scripting.FileSystemObject”)
File = “C:\Users\emmanuel.rached\Desktop\MyFile.txt”
WaitTime = InitialTime
TotalWaitTime = 0

‘ Loop until file is found or timeout exceeded, sleeping for WaitTime between each iteration
Do While TotalWaitTime < Timeout

TotalWaitTime = TotalWaitTime + WaitTime
WScript.sleep WaitTime
If fso.fileExists (File) Then

WScript.sleep Delay
WScript.StdOut.Write “The file was detected”
WScript.Quit(0)

End If

Loop
WScript.Quit(0)

The script starts by declaring several variables that we will use and by initializing some constants:

  • InitialTime will control the sleep interval for the script. WScript.sleep uses the integer defined as milliseconds. It is defined as 30 seconds in the code above
  • Delay will control a small sleep delay before exiting the script in case the file is found to allow the background setup to finish and properly exit
  • Timeout will define the maximum time that the script is allowed to run. It is defined as 10 minutes on the code above
  • WaitTime will be assigned the value of the InitialTime constant and will control the delay in the loop
  • TotalWaitTime will be used to monitor the script execution time to exit when the timeout is reached. It is set to zero at first
  • FSO will be used to indicate the file to monitor by using CreateObject (“scripting.FileSystemObject”)

The text highlighted in red indicates the full file path that the script will attempt to detect.

The main part of the script is the loop function. It will initially sleep for 30 seconds before attempting to detect the file, controlled by the WaitTime constant and using WScript.sleep. If the file is not found, the script will loop back, will increase the value of TotalWaitTime and will wait another 30 seconds. It will continue to monitor and loop until the TotalWaitTime variable exceeds the Timeout value defined. The script will then exit with an exit code of “0” and will write nothing to STDOUT or STDERR. SCCM will interpret this as “application files not found” and will proceed with the deployment.

If the file is found, the script will sleep for a minute to allow the background setup to properly finish. It will then output to STDOUT a custom message and exit with a “0” code. SCCM will determine that the application deployment was successful. This will also allow subsequent SCCM Agent application discovery to properly detect that the application is already deployed. The script was tested in a standalone environment and performed as expected.

However, when the script was integrated with SCCM detection clauses, it failed to run due to the default timeout that SCCM assigns to scripts. The maximum script execution run time is 60 seconds.

SCCM Detection Timeout - SCCM Detection Clauses Using Scripts

Thanks to Fei Xia who provides a solution to change the default timeout value. The script mentioned in his blog post was ran and successfully updated the ScriptExecutionTimeOut value to 600 seconds:

SCCM Script Execution TimeOut

Following all this configuration, the application was deployed again to the test machines with the updated script. The installation and detection was a success:

SCCM Detection Success - SCCM Detection Clauses Using Scripts

Hopefully, the script in this example will help you with custom detection rules in your environment. The variables and constants defined can be changed to values that suit your deployment type. Make sure to test the script before mass deployment.

Deploy EXE Files with SCCM

· · 1 Comment

As any SCCM administrator will tell you, ConfigMgr does not offer the option to deploy EXE files in a direct manner like MSI files. Fortunately, working around that limitation is easy. I will use the Silverlight setup as an example in this article. This can be applied to any EXE setup file.

We will start by placing the Silverlight setup file in the System Center Library. Following that, go to Software Library, Applications and Create Application:

Note: Always dedicate a central share location to store all System Center files.

Create Application

Choose the “Manually specify the application information” option in the wizard that appears and proceed to the next step.  Fill the text as desired. An example for Silverlight is shown below:

Silverlight Application - Deploy EXE with SCCM

Proceed to Application Catalog and fill out the additional details as needed. Be sure to specify a relevant icon as well. Continue to Deployment Types and click Add. We will create the Deployment Type as MSI deployment but we will use the EXE setup file of Silverlight.

Keep the default option of Windows Installer (.msi) and choose “Manually specify the deployment type information” option. Fill out the relevant information and continue to Content. Click browse next to Content Location and specify the location of the System Center Library share where the Silverlight package is present.

When you click the Browse button next to Installation Program, you will notice that you cannot select EXE as the file type. You can however directly type the EXE file name and SCCM will accept it. Proceed to do that and delete msiexec /i from the Installation Program parameters. Add any relevant switches to automate the installation as per your application documentation. For example, most InstallShield based setups allow you to run setup in record mode by using -r parameter. This will generate a .iss file can be used to automate the installation by specifying -s switch to play back the recorded installation.

Manual Content - Deploy EXE with SCCM

You can also specify the uninstallation program should you need SCCM to uninstall this deployment in the future. Search the registry where the application is already installed to determine the proper uninstall commands.

An additional option to mention is Run installation and uninstall program as 32-bit process on 64-bit clients. This allows the installation to automatically determine where the files should go depending on Windows being 32-bits or 64-bits, for example to X:\Program Files or X:\Program Files (x86) if %ProgramFiles% is specified. Proceed to Detection Method.

You will need to determine how SCCM will detect if your application is installed or not. Detection clauses can use File or Folder detection, Registry Key detection or Windows Installer based detection. Any easy way to specify what will constitute the clauses is to search on a workstation where the application is already installed for the appropriate files and registry keys. You can add multiple detection clauses, group them together to specify evaluation order and combine them using logical operators (AND/OR).

A simple way to detect whether Silverlight in our example is installed or not is by detecting its installed files for our specific version:

Detection Rule - Deploy EXE with SCCM

Proceed to User Experience. Customize the settings as per your need and continue with the wizard. If any Requirements must be met for this application, such as specific Operating System version or free disk space, specify them in the Requirements section and proceed. If any dependencies are needed specify them here. More on Requirements, Dependencies, Supersedence and other settings in a later article. Finish the Deployment Type wizard and finish the Create Application wizard.

Your application is now ready to be distributed to Distribution Points and deployed to the required collections.

Additional general information about application deployment with SCCM can be found in this Technet article.

SCCM Revoked Clients Registration

· · 3 Comments

When we were in the process of migrating our SCCM 2007 hierarchy to the newly installed SCCM 2012, we encountered around 150 revoked clients that were being denied registration. While the vast majority of the agents functioned properly, these particular agents remained unable to register with SCCM 2012.

We checked all the settings for SCCM 2012: boundaries, Management Point, and PKI among others. All our configuration was correct. Moreover, the issue was not restricted to a specific location since the problematic clients were distributed over numerous secondary sites which contained perfectly functioning clients as well. All the workstations come from a single master image without the SCCM agent installed which puzzled us even more. We examined the ClientIDManager.log on a malfunctioning agent and we saw these errors:

CLientIDManager Log - SCCM Revoked Clients

The server was rejecting the registration request. No further details were present otherwise so we checked the server logs. We found the following behavior being logged in MP_RegistrationManager.log on the primary site’s management point:

MP_RegistrationManager Log - SCCM Revoked Clients

That was odd since these clients were new and we have never revoked any certificates. We generated a new GUID for the agent by deleting %windir%\smscfg.ini and restarting the SMS Agent Host service. The same behavior remained and the server still rejected the registration for the new GUID with the same error.

Due to one of the log entries above, we suspected that the self-generated certificates had somehow expired but they were still valid:

SMS Certificates - SCCM Revoked Clients

Nevertheless, we again deleted smscfg.ini and we used SMS Toolkit to run CCMDelCert.exe on a problematic workstation. We restarted the SMS Agent Host service but the issue remained. We tried again but this time we deleted the agent and reinstalled it after the cleanup, the issue persisted.

Following that, we selected a secondary site that contained problematic agents and we performed the following:

  • Deleted %windir%\smscfg.ini on all the clients in the site
  • Ran CCMDelCert.exe on all the clients
  • Ran CCMclean.exe /all on all the clients as well
  • Uninstalled all the SCCM agents
  • Fully deleted the secondary site and its database and cleaned up any references on the primary site

We reinstalled the secondary site and pushed all agents. The same issue remained and problematic clients appeared again. Even though all the troubleshooting steps generated new GUIDs, the server was still rejecting them with the same error message. The root of our revoked clients problem had to be coming from the primary site and its database.

We went back to the primary site and we connected to the SQL instance for the SCCM database and ran the following:

Select * from ClientKeyData where SMSID in (‘GUID:E0D8AAC8-414C-4076-B733-873CC6FE46AF’)

This GUID belonged to one of the problematic clients. The query returned no results however, indicating that it does not exist in the database at all. We checked the database for any revoked clients by running:

Select * from ClientKeyData where isrevoked=1

The query returned results indicating that some clients have been revoked by the server. That was odd since, as I mentioned earlier, we never blocked or revoked any client or certificate. We backed up the SCCM database and ran:

Update ClientKeyData set isrevoked=0 where isrevoked=1

The query updated a number of records that matched the number of clients we were having problems with. After a few minutes, the clients started trying to re-register and they were finally able to do so:

CLientIDManager Log Success - SCCM Revoked Clients

Caution: directly modifying the SCCM database is not recommended nor supported by Microsoft and should be extensively tested. Only perform update queries after taking a full backup and when advised to do so by Microsoft support personnel.

SCCM Failed Client Push Installation

· · Leave a comment

A while back, we started noticing some SCCM clients failing to push automatically on some machines. The majority of client push installations were being processed successfully and installed clients were behaving properly (we have several thousand SCCM clients). Examination of the ccm.log on the server revealed the following error when the agent is being pushed:

Unable to get Win32_OperatingSystem object from WMI on remote machine “<machinename>”

Win32_OperatingSystem is a WMI class and this indicated that WMI was acting up on the target PCs. Nevertheless, we attempted to install the client locally on one of the problematic PCs by copying the client installation folder and running ccmsetup.exe with SMSSITECODE=<code> option.

The installation was a success, however, the client failed to report back to the server. After checking several log files on the client, the following errors showed up in ClientIDManagerStartup.log:

SCCM Client Log ClientIDManagerStartup Errors

All these were calls failing further indicating that WMI was corrupt.  To confirm, we ran wbemtest.exe on the target machine, connected to root\cimv2 and ran the following query:

select * from Win32_OperatingSystem

The query failed with Invalid Class error.

Corrupt WMI repositories can be fixed or rebuilt in several ways, some of which involve renaming the repository folder and rebuilding it from scratch. This method is very invasive and will most often lead to issues. A faster way to attempt remediation is to recompile WMI MOFs using mofcomp. A simple batch file consisting of the below will accomplish this:

cd “%systemroot%\system32\wbem”

for /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s

To note that this needs to be ran as a batch file and not directly from the command line, otherwise it will most probably fail. Running this batch file from an elevated command prompt repaired WMI and the query for Win32_OperatingSystem succeeded:

WIMQ Wbmetest Win32_OperatingSystem Success

Reexamining the ClientIDManagerStartup.log showed that the client is now functioning properly and has registered with the server:

SCCM Client Log ClientIDManagerStartup Success

We used PSExec to run the script remotely on the remaining problematic machines and the issue cleared up.

Links:

https://blogs.technet.com/b/askperf/archive/2009/04/13/wmi-recompiling-wmi-mofs.aspx