SCCM client install/reinstall (A disaster recovery approach)

SCCM client can be installed or re-installed using the following methods.
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.
A disaster scenario could be one or more of the following.
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 following steps are needed.
The download package is written using the PS app deploy toolkit.
The following are the areas of focus.
Note: The above flag is the ‘local content copied’ flag. This is different to the ‘Client installed’ flag which will be discussed later.
This folder in the app deployment tool kit package contains the following.
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)
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:
During Schedule task trigger
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.
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.
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.
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.
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.
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.
Both the copy and the install logs are located under C:\Windows\Logs\Software\
It is always a unique challenge of having to build an OSD experience that includes providing a great user experience during the deployment of a new operating system.
The attached application would allow you to present a front-end to an active end-user who is executing the SCCM task sequence……
Keywords: SCCM tasksequence UI, SCCM Task Sequence User interface, SCCM task sequence Set computer name.
Reporting on software update compliance of workstation devices in SCCM brings with it varying levels of complexities. But if you break it all down and…
According to Microsoft. A deployment ring is a defined as follows. “Deployment rings in Windows 10 are like the deployment groups most organizations constructed for…
Does your organization use VPN where a remote client no longer act as a network but as a standalone host which communicates on an interface…
Create a SCOPE for the Group Policy Object. Remove all other scopes. The scope will be limited to an AD security group e.g. ‘SCCM-Client-Re-Install-AD-Group’
Now the group policy will only run on computers who are members of the above AD security group. In this case, ‘SCCM-Client-Re-Install-AD-Group’ security group.
You must be logged in to post a comment.
Repair-SCCMClient.exe -copyonlyScript 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:WindowsCCMInstallSourcesccm-client-version-is-5.00.8913.1032.lnk" -ErrorAction SilentlyContinue)) { Write-Host 1 }"C:WindowsCCMInstallSource" 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.
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.