Using Configuration Manager Automatic Client Upgrade to upgrade to the latest System Center Endpoint Protection Client
Update 8/4/2015 - Your voice has been heard!!! Great news - after upgrading to R2 SP1 with CU1, automatic client upgrades will also install cumulative updates!! Check it out! https://blogs.technet.com/b/configmgrteam/archive/2015/08/04/automatically-updating-the-configuration-manager-client.aspx. If you aren't yet up to R2 SP1 with CU1, the below still applies to you until you get there.
The Configuration Manager Automatic Client Upgrade feature in Configuration Manager 2012 RTM through R2 is a nice new feature, but as it is still new to many folks, it often causes some confusion and misconceptions. The purpose of this blog post is to hopefully clear up some of the common misconceptions of this feature, and also show you how you can use it to keep your SCEP client version updated – not the definitions, but the actual version of the client itself.
You may already be familiar with the Automatic Client Upgrade option.
One of the most common misconceptions is that this checkbox will “Upgrade” your clients with the latest Cumulative “Update”. This is not so, as there is a difference between “Upgrade” and “Update”. ConfigMgr RTM to SP1 is an Upgrade, and SP1 to SP2 is an Upgrade. However, CU1, CU2, etc are both considered – you guessed it - an Update.
What this means is that automatic client upgrade will NOT automatically apply cumulative updates to your clients. Instead, you must use the packages created by the CU installation process to upgrade your clients, or SCUP, or any other method you choose.
To clarify what this feature will and won’t do, review the TechNet Article on Automatic Client Upgrades at https://technet.microsoft.com/en-us/library/gg712298.aspx. In it, you will notice the following:
A client can be automatically upgraded in the following scenarios:
- The client version is lower that the version being used in the hierarchy.
- The client on the central administration site has a language pack installed and the existing client does not.
- A client prerequisite in the hierarchy is a different version than the one installed on the client.
- One or more of the client installation files are a different version.
What happens when you apply a SCEP update to your site server, for example the latest one as of this writing https://support.microsoft.com/kb/2865173? *Update* (As of 11/27/13 it’s now https://support.microsoft.com/kb/2907566). The hotfix will automatically update the SCEP client installation within your out-of-the-box, automatically created/distributed/updated ConfigMgr 2012 client installation package, thus making it a different version than the one installed on the clients, and distribute the updated contents out to your DPs via the updated client source coming from the client share at \\yourprimarysiteserver\sms_xxx\client.
Before installing the SCEP hotfix, you may decide to take a look inside your CCMSetup.cab file at the CCMSetup.xml manifest. The CCMSetup.xml manifest is a file compressed inside of CCMSETUP.cab and has details of the files which are part of the ConfigMgr client installation, including the hash values and versions of each file.
Looking at the line within the client package CCMSetup.xml for the SCEPInstall before applying the SCEP update to the site server, you’ll notice something like following:
<Item FileName="SCEPInstall.exe" FileHash="EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD" KeepAfterExit="true">
<Applicability Platform="ALL" OS="ALL"/>
<Discovery Type="File" Identifier="%windir%\ccmsetup\SCEPInstall.exe" VerifyHash="true">
<Property Name="Version" Operator=">=">4.2.223.0</Property>
</Discovery>
<Installation Order="17" InstallationType="NONE"/>
</Item>
After applying the SCEP hotfix to your site server(s), you can once again open the ccmsetup.cab and review the manifest,, and should see that both the “FileHash” value, as well as the “Version” property have been updated to reflect the new SCEPInstall.exe updated by the SCEP update installation.
<Item FileName="SCEPInstall.exe" FileHash="B0336B863EE0FEE92A309F1BF1F11B878236D45C60165AAF7A6ED48454262595" KeepAfterExit="true">
<Applicability Platform="ALL" OS="ALL"/>
<Discovery Type="File" Identifier="%windir%\ccmsetup\SCEPInstall.exe" VerifyHash="true">
<Property Name="Version" Operator=">=">4.3.215.0</Property>
</Discovery>
<Installation Order="17" InstallationType="NONE"/>
< /Item>
Question: Now that you’ve updated the server, how do you get this update to deploy to upgrade your SCEP clients to the latest version?
Answer: Enable Automatic Client Upgrade (see “Important Caveat”).
Important Caveat: If you enable Automatic Client Upgrade and have maintenance windows applied to your clients, the clients will adhere to the maintenance windows regardless of the Automatic Client Upgrade checkbox. Therefore, if the clients are not in a maintenance window when the scheduled task runs, the automatic upgrade will not take place.
When you have Automatic Client Upgrade enabled, each client adds a scheduled task called “Configuration Manager Client Upgrade Task”.
Looking at the properties of the scheduled task, let’s say you’ve entered 30 days in the automatic client upgrade option. In this case, the “Next Run Time” will be anywhere from 1 to 30 days out from the current date. In other words, each client will pick a random execution date, somewhere between 1 day from now and 30 days from now, and will will use its randomly chosen date as the Next Run Time for this task. This is designed to help stagger out client upgrades across the desired number of days and the specific date can be determined the specific client’s CCMSETUP.log:
Upgrade task is randomized to run at 09/10/2013 10:04:03 PM (local) 09/11/2013 03:04:03 AM (UTC) time with arguments ' /AutoUpgrade /UpgradePackageVersion:4 /UpgradeWinTask'.
So now that the scheduled task exists on your clients, what happens when task scheduler kicks it off following the SCEP update being applied to the site server(s)? In a client’s CCMSETUP.log, you’ll see the following:
Ccmsetup command line: "C:\WINDOWS\ccmsetup\ccmsetup.exe" /runservice "/AutoUpgrade" "/UpgradePackageVersion:4" "/UpgradeWinTask" "/usepkicert" "CCMHTTPPORT=80" "CCMHTTPSPORT=443" "CCMFIRSTCERT=1" SMSSITECODE="PRI" "/mp: https://SCCM2012PRI.russlab.com" FSP="SCCM2012PRI.russlab.com"
So, CCMSETUP.exe has been spun up by the scheduled task, and has created a temporary CCMSETUP service with the pertinent switches to check for upgrades. Once the CCMSETUP service starts up, it will download the latest CCMSETUP.cab with the updated manifest included from the assigned Distribution Point, and write it to the client’s %windir%\ccmsetup\cache directory.
GET ' https://SCCM2012PRI.russlab.com/SMS_DP_SMSPKG $/CAS00006/ccmsetup.cab'
Successfully extracted manifest file C:\WINDOWS\ccmsetup\ccmsetup.xml from file C:\WINDOWS\ccmsetup\ccmsetup.cab.
Retrieved client version '5.00.7804.1000' and minimum assignable site version '5.00.7783.1000' from manifest
The CCMSETUP process extracts the CCMSETUP.XML from inside the CAB file and insures it’s running the minimum supported version to continue with the process. Further down the log, you will see that the SCEPInstall.exe is checked for existence, and it will discover that the hash value of the SCEPInstall.exe in the client’s %windir%\CCMSETUP directory no longer matches the hash of the SCEPInstall.exe listed in the new ccmsetup manifest:
File 'C:\WINDOWS\ccmsetup\SCEPInstall.exe' with hash 'B0336B863EE0FEE92A309F1BF1F11B878236D45C60165AAF7A6ED48454262595' from manifest doesn't match with the file hash 'EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD'
The newer SCEPInstall.exe is therefore added to the client’s pending install list:
Item SCEPInstall.exe has not been installed yet. Put to pending install list.
A few lines further down the log, you’ll see that the CCMSetup process reminds you one more time that the hash does not match, but this time it deletes the old SCEPInstall.exe and uses BITS to download the updated SCEPInstall.exe from the DP, and you can see that the new SCEPInstall.exe is around 25MB in size.
File 'C:\Windows\ccmsetup\SCEPInstall.exe' with hash 'B0336B863EE0FEE92A309F1BF1F11B878236D45C60165AAF7A6ED48454262595' from manifest doesn't match with the file hash 'EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD' ccmsetup 9/9/2013 8:56:37 AM 6788 (0x1A84)
Deleted file C:\Windows\ccmsetup\SCEPInstall.exe ccmsetup 9/9/2013 8:56:37 AM 6788 (0x1A84)
Validated file 'C:\Windows\ccmsetup\client.msi' hash '2F0819F959E788CF843F42E9CA7B44E258B8B4BA37BB63902DB39ACF747BE7DA' ccmsetup 9/9/2013 8:56:37 AM 6788 (0x1A84)
Upgrade code '{252DA259-82CA-4177-B8D0-49C78937BA3E}': product = '{D6804B3A-BFEC-4AB4-BFA5-FD9BECC80630}', installed = 1, version = 5.00.7804.1000 ccmsetup 9/9/2013 8:56:37 AM 6788 (0x1A84)
Client download is skipped because client version is greater than 5.00.7804.1000. ccmsetup 9/9/2013 8:56:37 AM 6788 (0x1A84)
Using branch cache option. ccmsetup 9/9/2013 8:56:38 AM 6788 (0x1A84)
Adding file ' https://SCCM2012PRI.russlab.com:80/SMS_DP_SMSPKG $/CAS00006/SCEPInstall.exe' to BITS job, saving as 'C:\Windows\ccmsetup\SCEPInstall.exe'. ccmsetup 9/9/2013 8:56:38 AM 6788 (0x1A84)
Starting BITS download for client deployment files. ccmsetup 9/9/2013 8:56:38 AM 6788 (0x1A84)
Download Update: 2567210 out of 25591432 bytes transferred. ccmsetup 9/9/2013 8:56:39 AM 6788 (0x1A84)
Successfully completed BITS download for client deployment files. ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
Once the BITS download finishes, CCMSetup will verify that the hash of the newly download file matches the one it downloaded:
Successfully downloaded client files via BITS. ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
Validated file 'C:\Windows\ccmsetup\SCEPInstall.exe' hash 'B0336B863EE0FEE92A309F1BF1F11B878236D45C60165AAF7A6ED48454262595' ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
C:\Windows\ccmsetup\SCEPInstall.exe is Microsoft trusted. ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
At this point, the ConfigMgr client has the updated version of SCEPInstall.exe in its %windir%\ccmsetup directory, and successfully validated that the hash matches the version on the DP which was automatically distributed to it following the site server’s SCEP hotfix install.
You should see a message letting you know that since you didn’t add any language packs to the site server, nor did you install a newer client version, it doesn’t need to do a full client reinstallation. The CCMSetup.exe process deletes the temporary CCMSETUP service, and the ccmsetup.xml manifest file extracted from the cab, and if all went well, exits with a return code of ‘0’ – Success!
No client language changes are detected per current client.msi. ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
Client installation will be skipped because required version of client is already installed. ccmsetup 9/9/2013 8:56:42 AM 6788 (0x1A84)
Successfully deleted the ccmsetup service ccmsetup 9/9/2013 8:56:47 AM 6788 (0x1A84)
Sending Fallback Status Point message to 'SCCM2012PRI.russlab.com', STATEID='400'. ccmsetup 9/9/2013 8:56:47 AM 6788 (0x1A84)
Params to send FSP message '5.0.7804.1000 Deployment [DP] https://SCCM2012PRI.russlab.com/SMS_DP_SMSPKG $/CAS00006' ccmsetup 9/9/2013 8:56:47 AM 6788 (0x1A84)
State message with TopicType 800 and TopicId {1FFD119F-4ED5-4C9A-9765-CAACE1E26FD7} has been sent to the FSP FSPStateMessage 9/9/2013 8:56:47 AM 6788 (0x1A84)
Deleted file C:\Windows\ccmsetup\ccmsetup.xml ccmsetup 9/9/2013 8:56:47 AM 11156 (0x2B94)
Task 'Configuration Manager Client Upgrade Task' does not exist ccmsetup 9/9/2013 8:56:47 AM 11156 (0x2B94)
CcmSetup is exiting with return code 0 ccmsetup 9/9/2013 8:56:47 AM 11156 (0x2B94)
CCMSETUP is later launched by the client’s Windows Task Scheduler during the automatic client upgrade scheduled task:
==========[ ccmsetup started in process 8260 ]========== ccmsetup 9/9/2013 9:15:13 AM 9948 (0x26DC)
Running on platform X64 ccmsetup 9/9/2013 9:15:13 AM 9948 (0x26DC)
Updated security on object C:\Windows\ccmsetup\cache\. ccmsetup 9/9/2013 9:15:13 AM 9948 (0x26DC)
Launch from folder C:\Windows\ccmsetup\ ccmsetup 9/9/2013 9:15:13 AM 9948 (0x26DC)
CcmSetup version: 5.0.7804.1000 ccmsetup 9/9/2013 9:15:13 AM 9948 (0x26DC)
In ServiceMain ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Successfully started the ccmsetup service ccmsetup 9/9/2013 9:15:13 AM 4892 (0x131C)
Running on OS (6.2.9200). Service Pack (0.0). SuiteMask = 400. Product Type = 2 ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Ccmsetup command line: "C:\Windows\ccmsetup\ccmsetup.exe" /runservice "/UpgradeWinTask" "/usepkicert" "CCMHTTPPORT=80" "CCMHTTPSPORT=443" "CCMFIRSTCERT=1" SMSSITECODE="PRI" "/mp: https://SCCM2012PRI.russlab.com" FSP="SCCM2012PRI.russlab.com" ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Command line parameters for ccmsetup have been specified. No registry lookup for command line parameters is required. ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Command line: "C:\Windows\ccmsetup\ccmsetup.exe" /runservice "/UpgradeWinTask" "/usepkicert" "CCMHTTPPORT=80" "CCMHTTPSPORT=443" "CCMFIRSTCERT=1" SMSSITECODE="PRI" "/mp: https://SCCM2012PRI.russlab.com" FSP="SCCM2012PRI.russlab.com" ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Ccmsetup is launched by Windows Task Scheduler for client upgrade. ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
The CCMSETUP service is restarted, and the CLIENT.MSI file is deleted from the %windir%\CCMSETUP directory to insure the current MSI will be used.
Ccmsetup is being restarted due to an administrative action. Installation files will be reset and downloaded again. ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Deleted file C:\Windows\ccmsetup\client.msi ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
This time, the SCEPInstall.exe file DOES match the hash from the CCMSetup.xml manifest, and also now reflects the new version of SCEPInstall.exe as well.
Discovering whether item 'SCEPInstall.exe' exists. ccmsetup 9/9/2013 9:15:13 AM 3892 (0x0F34)
Validated file 'C:\Windows\ccmsetup\SCEPInstall.exe' hash 'B0336B863EE0FEE92A309F1BF1F11B878236D45C60165AAF7A6ED48454262595' ccmsetup 9/9/2013 9:15:14 AM 3892 (0x0F34)
Checking file 'C:\Windows\ccmsetup\SCEPInstall.exe' version '4.3.0215.0000' expecting >= '4.3.215.0'. ccmsetup 9/9/2013 9:15:14 AM 3892 (0x0F34)
Detected item 'SCEPInstall.exe' ccmsetup 9/9/2013 9:15:14 AM 3892 (0x0F34)
Now we will download the current CLIENT.MSI and add it Windows Installer’s pending install list to prepare for the client for the update:
Discovering whether item 'x64/client.msi' exists. ccmsetup 9/9/2013 9:15:14 AM 3892 (0x0F34)
Item x64/client.msi has not been installed yet. Put to pending install list. ccmsetup 9/9/2013 9:15:14 AM 3892 (0x0F34)
And we will use CLIENT.MSI to initiate a repair on the client to include the newer SCEPInstall.exe:
Client (5.00.7804.1000) is installed and is the same or lower version. Initiating repair. ccmsetup 9/9/2013 9:15:15 AM 3892 (0x0F34)
Repairing version 5.00.7804.1000 of the client with product code {D6804B3A-BFEC-4AB4-BFA5-FD9BECC80630} ccmsetup 9/9/2013 9:15:15 AM 3892 (0x0F34)
MSI PROPERTIES are REINSTALL=ALL REINSTALLMODE=vmous CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMFIRSTCERT="1" SMSSITECODE="PRI" FSP="SCCM2012PRI.russlab.com" CCMHTTPSSTATE="480" CCMCERTID="MY;1519300E12D5A92DB736AAD7AA4E17A79C162B9F" ccmsetup 9/9/2013 9:15:15 AM 3892 (0x0F34)
C:\Windows\ccmsetup\{59A0EA77-D28C-4286-83A6-04BB57B9CDD6}\client.msi is Microsoft trusted. ccmsetup 9/9/2013 9:15:15 AM 3892 (0x0F34)
Running installation package
Package: C:\Windows\ccmsetup\{59A0EA77-D28C-4286-83A6-04BB57B9CDD6}\client.msi
Log: C:\Windows\ccmsetup\Logs\client.msi.log
Properties: REINSTALL=ALL REINSTALLMODE=vmous CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMFIRSTCERT="1" SMSSITECODE="PRI" FSP="SCCM2012PRI.russlab.com" CCMHTTPSSTATE="480" CCMCERTID="MY;1519300E12D5A92DB736AAD7AA4E17A79C162B9F" ccmsetup 9/9/2013 9:15:15 AM 3892 (0x0F34)
Next time the SCEP Service starts or restarts, it will see that there’s a version difference between the SCEPInstall.exe located in %windir%\ccmsetup and the one that is actually installed:
Service startup notification received EndpointProtectionAgent 9/9/2013 10:37:38 AM 2916 (0x0B64)
Endpoint is triggered by CCMTask Execute. EndpointProtectionAgent 9/9/2013 10:37:38 AM 2968 (0x0B98)
File C:\WINDOWS\ccmsetup\SCEPInstall.exe version is 4.3.215.0. EndpointProtectionAgent 9/9/2013 10:37:38 AM 2968 (0x0B98)
EP version 4.2.223.1 is already installed. EndpointProtectionAgent 9/9/2013 10:37:38 AM 2968 (0x0B98)
EP 4.2.223.1 is installed, version is lower than expected installer version 4.3.215.0. EndpointProtectionAgent 9/9/2013 10:37:38 AM 2968 (0x0B98)
It will kick off the new and improved SCEPInstall.exe to install the upgraded version of ScEP, and send the resulting status message up to the site:
Sending ack to MTC for task {9BCF7827-E04F-4C3A-8D8C-B943316A2D7F} EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
SCEP client is not present, SCEP client will be installed with the latest AM policy. EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Sending message to external event agent to disable notification EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Sending message to endpoint ExternalEventAgent EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Disable Startup Signature Update equals to true. EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Add the Disable Startup Signature Update settings to policy xml successfully. EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Create Process Command line: "C:\WINDOWS\ccmsetup\SCEPInstall.exe" /s /q /NoSigsUpdateAtInitialExp /policy "C:\WINDOWS\CCM\EPAMPolicy.xml". EndpointProtectionAgent 9/9/2013 10:37:56 AM 2920 (0x0B68)
Path variable ProgramData does NOT exist. EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
Detail error message is : [EppSetupResult]
HRESULT=0x00000000
Description=The operation completed successfully.
EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
Installed EP client successfully. EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
start to send State Message with topic type = 2001, state id = 3, and error code = 0x00000000 EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
Start to send state message. EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
Send state message successfully EndpointProtectionAgent 9/9/2013 10:39:17 AM 2920 (0x0B68)
Now that this has finished, you can confirm your client has been updated by clicking “Help”, “About” on the Endpoint Protection client itself.
If all was successful, you will be able to see that the Antimalware Client Version has been updated to 4.4.304.0!
Ahhhh. A happy new and improved SCEP client!
Comments
Anonymous
November 26, 2013
Thanks for this this was awesome even after working it out, wish i found this sooner. Wondering if you could advise on a upgrade issue. I've managed to upgrade all SCEP clients to Antimalware Client Version: 4.3.215.0 Engine Version: 1.1.10100.0 CMM clients have also updated however i have three clients in the collection where there client version hasn't changed relative to whats actually installed. I have 1 server that has .1400 installed but the database show 1000. I've ran the inventory cycles, pretty much everything including installing manually to get it to update the database but with to avail. Any ideas? Best Regards JeffAnonymous
December 15, 2013
Pingback from Part I - Deploy Windows 8.1 - George's BlogAnonymous
April 29, 2014
both clarifying and disheartening. Hopefully auto-updating will follow-alongside auto-upgrading soon ... as it adds a LOT of complications to manually create collections or integrate SCEP for something that would be considered automatic to any other product.Anonymous
July 31, 2014
Regarding the "Important Caveat" - will the client retry the scheduled task once the client is in a maintenance window? Or will the scheduled task simply fail and never run again?Anonymous
August 04, 2015
This functionality has been changed in ConfigMgr 2012 SP2 and ConfigMgr 2012 R2 SP1, CU updates now work with Automatic Client Upgrade feature.
This can be seen in CU1 for ConfigMgr 2012 SP2 and ConfigMgr 2012 R2 Sp1