Friday, June 28, 2019

ConfigMgr Clients are no longer receiving User Deployments

Removing the Application Catalog Role within ConfigMgr was not as straight forward as i was hoping !

Like many SCCM admins historically the Application Catalog Web service Point and Website point were installed in order to deploy applications to Users.  
However, this feature is now depreciated and User deployments can be deployed without this role as the client will query a management point instead for all deployments (user and device).

I decided that this role should be removed as we were on 1810 Hotfix2 and colleagues had stated the transition was near seamless (see below regarding a reported BUG and quick fix to modify any Client setting).

The procedure to remove the App Catalog role is straight forward:
1. Remove references to App Catalog website within Client Settings.
2. Remove the Roles within the SCCM console.

In our case the removal of the website within Client Settings and the system roles was straight forward however, we saw in a few cases Clients are no longer receiving User Deployments and I thought I would write this blog to share my experience and how to detect systems in a similar state.

Lets gather the logs!

Using endpoint Url: https://AppCatalogSERVER:443/CMApplicationCatalog, Windows authentication (Microsoft.SoftwareCenter.Client.Data.ACDataSource+<>c at <RefreshLocalSettingsAsync>b__13_0)
The client is looking for User deployments using the AppCatalog server website however, this does not exist and it not referenced in Client Settings.


Raising event:
instance of CCM_PolicyAgent_PolicyDownloadSucceeded 
Failed to compile rule "{Rule_WRC10000}": 0x8000ffff
Raising event:
instance of CCM_PolicyAgent_PolicyCompileFailed 
We can see that Policy is downloaded however fails to compile.

The Image below details the "Actual" policy applied and as you can see 'Reserved1' details the AppCatalog Website which does not exist; however the client is told to use this address to find User deployments.  As the site does not exist policy cannot exist and Software Center does not show User deployed Applications.

The Image below details the "Requested" policy applicable via Client Settings. As you can see 'Reserved1' does not detail the AppCatalog Website; the client should understand that and receive User policy from the Management Points as intended.  If this was working the SCClient_Domain@USERNAME_1.log would show details for the Management Points instead.

While I cannot explain why the Client Settings are not compiling it did conclusively show that the Site Server was offering the right policy but the client was not applying it.  Various sites have stated this behavior is a known bug and that simply changing a Client Setting would re-engage the client and allow the desired policy to apply.

This client would not update which made me wonder how many systems in the estate have this exact issue?

Using PowerShell you can query the class CCM_ClientAgentConfig namespace and report a compliance metric; this is easily deployed via ConfigMgr Baselines..

$ClientConfig =Get-WmiObject -class CCM_ClientAgentConfig -namespace "root\ccm\policy\machine\actualconfig"
IF ($ClientConfig.Reserved1 -eq "https://AppCatalogSERVER:443/CMApplicationCatalog")
{Write-host "Non-Compliant"}
{Write-host "Compliant"}

The hope at this point is that the Agent Config client settings compile issue is limited to a small number of systems. Once the exposure of non-compliant system is understood we can see if a Remediation Script needs to be added to the Baseline.

...........Watch this space for Remediation (28/06/19)

Key Search words, phrases

Policy not compiling
Remove AppCatalog

Thursday, June 13, 2019

Windows 10 - Feature Upgrade using SCCM Servicing

Software Updates - Feature Upgrade - Windows 10

Software updates within an Enterprise organisation has been fairly straight forward until you attempt to use it for Feature Upgrades of Windows 10.  SCCM is very reliable at delivering the updates (Rollups, Updates, Upgrades) and as i have previously proved is UWF aware in Windows 10.
However, the Feature Upgrade does require a bit of prep work if you do not want the new Appx Applications installed as part of the Upgrade.

Moving between the 1507-1703 branches each Feature upgrade would reinstall the Appx Applications that you previously removed. Microsoft has addressed this in the 1703 - 1709 feature upgrade and if you removed an application it will not come back.  However, if the new branch has a new application this will get installed.

Uninstalled in-box apps no longer automatically reinstall
Starting with Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the feature update installation process.
Additionally, apps de-provisioned by admins on Windows 10, version 1703 machines will stay de-provisioned after future feature update installations. This will not apply to the update from Windows 10, version 1607 (or earlier) to version 1703.

 By using the SetupConfig.ini file for an OOBE after the Feature upgrade, you will be able to ensure unwanted Appx applications are not provisioned and made available to the user; in addition to any other post action script you need to run.

Location of the SetupConfig.ini
Before the Feature Upgrade is deployed/installed via Software Center the SetupConfig.ini must be created and place locally on the system. Place the SetupConfig.ini file in the WSUS directory below; the WSUS folder does not exist by default. The Feature upgrade via SCCM will look in the WSUS folder and read the SetupConfig.ini


Content of the SetupConfig.ini
In the ini file i have referenced the location of a file called "SetupComplete.cmd" that will be copied from this location to the hidden Feature Upgrade folder on the root of the C drive.  c:\$WINDOWS.~BT\Sources\Scripts\SetupComplete.cmd 


Within the Setupact.log you will see the /PostOOBE switch detailed with the contents of the SetupConfig.ini file appended to the Feature Upgrade Command Line used to run the Software update.

SCCM Software Update / Feature Upgrade Command Line 

[/PreDownload /Update /Quiet  /progressCLSID 71212340-ea4e-4e40-a0ee-a26312345baf /ReportId {A81239C5-8127-4352-1234-6CE01234531F}.200 "/ClientId" "fed1234-612d-40dd-123a-cd1234ee12d" "/CorrelationVector" "/oCGdL3nj012344.7.2"   /PostOOBE C:\ProgramData\OSConfig\setupcomplete.cmd]

Content of the SetupComplete.cmd
This command file calls several command lines for post Upgrade customization.

powershell.exe -executionpolicy bypass -file C:\ProgramData\OSConfig\Start\Set-StartLayout.ps1
powershell.exe -executionpolicy bypass -file C:\ProgramData\OSConfig\Background\Set-Background.ps1
MsiExec.exe /X {F14000BE-0001-6400-0000-074957833700} /qn

Here is the cool bit.  

The script below will create the SetupConfig.ini and SetupComplete.cmd files for you dynamically.  I use this in an SCCM Baseline to create and ensure they are upto date with my modifications.

In addition to the post custom scripts to set Background wallpapers and Start menu layouts I use the baseline to set 'Deprovisioned' regsitry keys so the Appx Applications are not provisioned for new users.

Example PowerShell command to create key. See Microsoft for additional details

New-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.Messaging_8wekyb3d8bbwe' -Force

I have scripted the process to create the keys using the PackageFamilyName. Remember do not Deprovision SystemApps otherwise you may experience issues with Applications you do want to use i.e. Photos.  See Microsoft for the different categories .  Makes reference to this in his blog (Thanks).

Next Line