You can use the below instructions to slipstream updates to the SCEP clients. This process also should work for any future updates.
These instructions are for the 64bit clients, but you should be able to figure out how to create a 32 bit client using the same process.
Download Main standalone client:
Client version 18.104.22.168 direct link: http://wsus.ds.download.windowsupdate.com/c/msdownload/update/software/crup/2015/02/scepinstall_230274d8b20bbe30fb94a287fd82670af0309ea4.exe
Rename the file as needed e.g scepinstall_22.214.171.124.exe
Use 7zip to extract the exe contents to a folder “scepinstall_126.96.36.199”
Download the latest update 188.8.131.52 [May-2015]
Rename the update file and extract to a folder using 7zip, same as above.
Create a new folder called “SCEPClient_4.8.204”
From the client extract folder “scepinstall_184.108.40.206” copy the below files to the “SCEPClient_4.8.204” folder
Everything in the \amd64 folder
Copy the Required language folder and the below files from the root folder
Now slip stream the updates:
Make sure you overwrite the files when you copy the updates
From the extracted update folder “updateinstall”
Copy everything in the /amd64 folder and overwrite the old files
From the root of the update folder copy and overwrite the below files and folder
Final install folder should look like below.
You can now install it using the setup.exe
e.g setup.exe /s /q
If you are using SharePoint online in your organization, it is wise to know about the below issue (or feature?).
If you have followed Microsoft best practice and have added your company zone to the trusted zones and also instructed the users to tick the “remember my password” it seems like that the cookie generated during this procedure would be valid even if you disable this user and revoke their login permissions (unless your process is to delete AD/O365 accounts immediately).
Steps you would/can take to decommission a user account
Environment setup: AD password synced
Change the user password
Disable the account
Block “sign in” on Office 365 [update: This will stop access after 1 hour]
SharePoint online access will still work even though you do any of the steps above!!
How do I block access?
You would have to remove access from the SharePoint site level permissions. Depending on if you are using security groups or actual user accounts to grant access, we would have to remove the terminated user from the group and then force a sync to azure AD.
Scenarios not tested: ADFS SSO environment, Deleting the account (this should work as then SharePoint site permissions would be removed too)
Update: I have logged a ticket with Microsoft regarding this issues and will upadate this post when I hear back from them.
Update2: MS came back with the below. So you could use the block sign in option but it will need about an hour to take effect.
Once admin blocked the user in the MSODS (O365 global AD), the msonline-AccountEnabled for that user in MSODS will be updated to false for that user , it need about 1 hour for syncing the msonline-AccountEnabled value to SPODS (SharePoint online AD). It is a by design behavior according to the feedbacks from back-end team.
Generated cookie details (IECookiesView.exe)
Remove User from the SPOnline Site permissions: access will be denied