SCCM client install/reinstall (A disaster recovery approach)
SCCM client can be installed or re-installed using the following methods.
- Client push Installation. Automatic client push or pushing clients directly to a Computer object or a collection of computer objects.
- Using Microsoft Intune.
- Using Software Update point.
- By using third party tools like Client Center for Configuration Manager or Right click tools for the SCCM console.
All of the above methods are very effective in their own right. But when it come to a disaster recovery scenario they fall a little short.
What is a disaster situation?
A disaster scenario could be one or more of the following.
- All or a major portion of your fleet has their SCCM client broken. Reasons unknown or possibilities endless.
- The CCM (SCCM client) WMI namespace(s) are corrupted on all or most of your SCCM clients.
- Machines are connected via RAS (VPN); all other solutions are complicated and network bandwidth intensive.
- Helpdesk are bombarded with multiple calls regarding end users waiting for an Application(s) to be deployed and there is an unanimous consensus that SCCM clients are non-functional.
So whats the best approach?
Adjunct to the standard Microsoft documented approaches; it is prudent to implement an alternative disaster recovery method. Goals of this approach are as follows.
- The SCCM client repair files will be available locally.
- The trigger action will be ‘Unlock of the computer’
- Prevent repetitive re-installs (after trigger) by using
‘Client installed’ flag. - Helpdesk can easily re-install SCCM clients by deleting the
‘Client installed’ flag and direct end-users to lock and unlock their computer.
Whats involved?
The following steps are needed.
- An SCCM application.
- A PowerShell script (We use PS App Deployment tool kit)
- A machine with a working SCCM client at the time of deployment or the Application containing the SCCM client to be deployed during build time.
The logic:
- The SCCM application (the download content: do not think about that now) gets created and deployed.
- The SCCM application does NOT install/reinstall the client.
- The SCCM application just copies the SCCM client install files locally to the computer.
- The SCCM application also creates a Schedule Task on the computer that executes the SCCM client install/reinstall process when the user ‘Unlocks’ the computers (Only if the
‘Client installed’ flag is not present).
The download package:
The download package is written using the PS app deploy toolkit.
The following are the areas of focus.
- The Files folder.
- The ‘Repair-SCCMClient.exe’ executable.
- The ‘Deploy-Application.ps1’ PowerShell file.
- The ‘sccm-client-version-is-*.**.***.***.lnk’ shortcut is a ‘local content copied’ flag. This is the flag that SCCM detection method will use to check if the SCCM application has successfully copied the SCCM Client content locally.
Note: The above flag is the ‘local content copied’ flag. This is different to the ‘Client installed’ flag which will be discussed later.
The files folder:
This folder in the app deployment tool kit package contains the following.
- A copy of the SCCM client package, copied from your SCCM server. These files are usually found within the ‘Client’ sub folder within the ‘Microsoft Configuration Manager’ folder inside the ‘Program Files’ area.
- An XML file that has the content of the Schedule Task that gets created. Do not delete the ‘schtask.xml‘ file.
The ‘Repair-SCCMClient.exe’ executable:
This executable calls on the ‘Deploy-Application.ps1’ PowerShell file with the switch ‘-copyonly’ during the installation (copy process) of the SCCM Application. (Image 1)`
This executable calls on the ‘Deploy-Application.ps1’ PowerShell file WITHOUT the switch ‘-copyonly’ via the Schedule task during the ‘unlock’ process that triggers the install/reinstall of the SCCM client. (Image 2)
The ‘Deploy-Application.ps1’ PowerShell file:
As discussed above the executable calls on the ‘Deploy-Application.ps1’ PowerShell file with the switch ‘-copyonly’ during the installation (copy process) of the SCCM Application. (Image 1 above) and WITHOUT the ‘-copyonly’ switch when called via the Schedule task trigger (Image 2 above).
The PowerShell file has the logic within it to do the following.
During SCCM application install:
- Make itself local by copying itself to “C:\Windows\CCMInstallSource” directory. This happens when the ‘-CopyOnly‘ switch is used.
- Creates a Schedule task called ‘SCCM Client Repair’
During Schedule task trigger
- Uninstall the existing SCCM client.
- Clears the CCM folder (if exists).
- Clears the CCMCache folder(if exists).
- Clears the CCMSetup folder(if exists).
- Clears the CCMTemp folder(if exists)
- Install the SCCM client using the parameters specified in the PowerShell script.
What changes are to be made in the PowerShell script?
The script can be edited and customized to your own liking. But the minimal changes that are required to get to a functional script are as follows.
$SMSCACHESIZE => You SCCM client cache size.
$SMSMP => Your SCCM management point.
$SMSSITECODE => SCCM site code.
$FSP => Your SCCM fallback status point.
$SMSSLP => Your SCCM server locator point.
$DNSSUFFIX => Your DNS suffix.
$appVersion => This will contain the value corresponding to the ‘ccmsetup.exe‘ file product version you are deploying.
Setup the SCCM application :
Follow the standard procedure to set up the SCCM application and a deployment type. Pay attention to the areas of the application depicted by the below screenshots.
- Deployment Type/Content tab
- Deployment Type/Programs tab
- Deployment Type/Detection method tab.
Content location => this will be the location where you’ll place the downloaded content. (Download link below).
Installation command line => this will be the similar to the below command.
Repair-SCCMClient.exe -copyonly
Script detection method ==> This will detect the existence of the schedule task ‘SCCM Client Repair‘ and the ‘local content copied’ flag ‘sccm-client-version-is-*.**.**.****.lnk‘.
The version number ‘*.**.**.****’ will be the same value as the value assigned to the $appVersion variable within the script (As discussed above).
Please note: PowerShell script execution should be set to ‘ByPass‘ in SCCM console client settings for the PowerShell based script detection to work. If not, the PowerShell script should be signed.
if ((Get-ScheduledTask -TaskName "SCCM Client Repair" -ErrorAction SilentlyContinue) -and (Test-Path -Path "C:\Windows\CCMInstallSource\sccm-client-version-is-5.00.8913.1032.lnk" -ErrorAction SilentlyContinue)) {
Write-Host 1
} “C:\Windows\CCMInstallSource” is the location into where the local SCCM client install files are copied.
The Schedule task will then run the ‘Repair-SCCMClient.exe” from this location when the user unlocks the computer.
The presence of the ‘local content copied’ flag will mark the success of the copy operation. The version number of the ‘local content copied’ flag should be changed to reflect the version of the SCCM client being deployed.
A quick check point!
- Have you downloaded the content and setup your SCCM application content location?
- Have you edited the ‘Deploy-Application.ps1‘ PowerShell script and made all necessary changes?
- Have you renamed the (copy local) ‘local content copied’ flag to reflect the version of the SCCM client you are deploying?
- Have you copied the SCCM client installation files into the ‘Files’ sub folder of the PS App Deploy Toolkit?
- Make sure you have not deleted the ‘schtask.xml‘ file from within the “Files” folder.
After deploying the SCCM client install / reinstall application.
You should see a Schedule task item called ‘SCCM Client Repair’; As seen in the image below. This task will trigger ‘Repair-SCCMClient.exe’ from “C:\Windows\CCMInstallSource” location when the user unlocks the computer.
You also find a local copy of the SCCM application content in “C:\Windows\CCMInstallSource” location. Pay attention to the FLAG ‘sccm-client-version-is-*.**.****.****.lnk‘ flag. The FLAG was one of the SCCM application detection methods. Deleting the flag will force SCCM to re-copy (deploy) the content.
SCCM client install / reinstall has not started yet
To start the install / re-install of the SCCM client. The end-user should lock and unlock the computer.
The Schedule task will trigger re-install of the SCCM client from its local source as discussed above during computer unlock.
To prevent the SCCM client from re-installing every time the user locks and unlock the computer, the client install process creates a ‘Client Installed’ flag called ‘installed-sccm-client-version-is-*.**.****.****.lnk‘ flag
Note: This FLAG is different to the ‘local content copied’ flag that we discussed earlier.
- The ‘local content copied’ flag is used by SCCM to detect if the content is copied locally.
- The ‘client installed flag’ stops the schedule task trigger from re-installing the application over and over again when the user unlocks the computer.
After the deployment of this SCCM client install / re-install application as a local copy, the first install or re-install will happen during computer unlock because the ‘Client installed’ flag is not present under “C:\windows\CCM“.
This should not be a problem; But to stop this from happening create the ‘Client installed’ flag via other means (group policy or scripts).
Henceforth the help-desk could delete all the ‘Client installed’ flags and direct the users to lock/unlock their computer to re-install/install/repair the SCCM client.
For global SCCM client re-installs:
- Use scripts to universally delete the ‘Client installed’ flag once.
- Use “Run script” SCCM functionality to delete the ‘Client installed’ flag.
- You could also use AD group policy to give your users full permission to “C:\Windows\CCM\installed-sccm-client-version-is-*.**.****.****.lnk” file (Only that file). Such an action will allow then to delete the ‘Client installed’ flag themselves.
Log location
Both the copy and the install logs are located under C:\Windows\Logs\Software\
This is very good approach. I do like the schedule task trigger; allows the install to happen outside the purview of the SCCM client (ccmexe.exe process). Delivery using the SCCM application delivery model but, execution using the ‘system unlock’ schedule task trigger. Great idea!
Read a comment on LinkedIN regarding your post. The comment read that your script can be delivered group policy too; I thought that was a good idea.
Great article – thanks for sharing. I used some of your approach for a recent SCCM client migration. It was mostly successful, but a number of servers failed to migrate. You may want to update your article, as this will affect others.
When running the script manually on these failed machines, I found Windows prompts for a .Net 3.5 feature to be installed. This causes the script to stall when it’s run in the system context. This is a bug which appeared in PSAppDeployToolkit 3.5, and was resolved by creating the “Deploy-Application.exe.config” file in the root folder, alongside the “Deploy-Application.exe” file. The original article mentioning this has been archived, but it is mentioned here.
This fix works fine, unless you rename Deploy-Application.exe file (as in your solution, where it’s renamed to Repair-SCCMClient.exe). If you do that, you also need to rename the .config file to match.
So, in a nut-shell, Deploy-Application.exe.config needs to be renamed to Repair-SCCMClient.exe.config. Otherwise, the script will stall in certain circumstances.
Thank you, Dave. Appreciate your work. I’ll get my team to update the package and make the necessary changes to this article.