Removing the Application Catalog Role after Upgrading to ConfigMgr 1806

If you have been keeping up with SCCM/ConfigMgr release notes, you will have seen that in 1806, you no longer need to have the Application Catalog Role installed in order to enable User Available applications in Software Center (if you didn’t already know, yeah, that was a requirement previously). If you were like me, this was one of your first actions after upgrading to 1806. Unfortunately, there appears to be a bug with removing the role that causes clients to stop seeing User Available software in Software Center. I’m going to walk through the removal process as well as the remediation of the client issue.

Removing the Application Catalog Role

Simply go into your ConfigMgr console and navigate to \Administration\Overview\Site Configuration\Servers and Site System Roles. Select each of the Application Catalog Roles then select Remove Role.

You should be able to watch smscomp.log to see the uninstall progress. You should see an entry like this showing that the role is being removed then several more actions that run to switch over the role to the new 1806 functionality. It should happen very quickly.

Starting service SMS_SERVER_BOOTSTRAP_CM01 with command-line arguments "TST C:\Microsoft Configuration Manager /deinstall C:\Microsoft Configuration Manager\bin\x64\rolesetup.exe SMSAWEBSVC "...

If your client settings are pointing to a custom Application Catalog URL, be sure change it to default. Your setting should look like this:

That’s it. You’re now using the cool new 1806 Application service (I honestly don’t know the name is, if there is one.)

Checking your Client for Issues

At this point, you should be able to open Software Center on your client that had User Available applications in it prior to the change and the applications should be there just like before. You can confirm the change by checking the SCClient_XXXX.log on the client to see that Software Center is pointing to the new web service.

Working Client – Entry on [email protected]_2.LOG

Using endpoint Url: http://CM01.asdlab.net:80/CMUserService_WindowsAuth, Windows authentication (Microsoft.SoftwareCenter.Client.Data.ACDataSource RefreshLocalSettingsAsync)

Broken Client – Entries in

[email protected]_2.LOG and PolicyAgent.log

[email protected]_2.LOG: GetCategoryValuesAsync: There was no endpoint listening at http://cm01/CMApplicationCatalog/applicationviewservice.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.. Unable to fetch user categories, no endpoint found. (Microsoft.SoftwareCenter.Client.ViewModels.SoftwareListViewModel+<LoadAppCatalogApplicationsAsync>d__145 at MoveNext) PolicyAgent.log: Failed to compile rule "{Rule_WRC10000}": 0x8000ffff Raising event: instance of CCM_PolicyAgent_PolicyCompileFailed { ClientID = "GUID:FAD43163-1038-43B3-BB15-9837DEEE4404"; DateTime = "20181102204614.541000+000"; PolicyNamespace = "\\\\.\\ROOT\\ccm\\policy\\machine\\requestedconfig"; PolicyPath = "CCM_Policy_Policy5.PolicyID=\"WRC10000\",PolicyVersion=\"4.00\",PolicySource=\"SMS:TST\""; ProcessID = 1684; ThreadID = 8324; Win32ErrorCode = 2147549183; };

If you see the error entries, then read on, otherwise, you should be installing Applications from Software Center, not reading a blog!!

Remediating Client Issues

The fix that Adam Juelich and I have settled is to make a change in the client settings policy (he toggled a setting in the Software Center settings) then try again on the client. You MAY need to update client policies, but in our testing, that wasn’t necessary. Simply close and re-open Software Center and the apps reappeared and the errors went away.

Summary

We have reached out to the ConfigMgr product group and they are looking into the issue. In the meantime, just change a client setting and see if you get it working. Please send me a note or message me on Twitter if you find any issues or other info about this issue.