Options for Nerfing Software Center

Note: I started this post several months ago but held off on posting it.  Since then, the circumstances have changed virtually eliminating the need for accessing Software Center not nearly as important as it once was.  That said, this may be a non-issue for you but I figured I’d at least share what I discovered.

In an Office Several Months Ago…

We stood up a new Citrix XenApp environment leveraging SCCM to build the Session Hosts over Machine Creation Services (MCS).  As such, Software Center was present posing a potential problem in trying to keep a pristine Citrix environment: We certainly can’t have our customers installing software willy-nilly now!  We had some discussions internally about this and there were two key objectives:

  1. We need to prevent our customers from installing software be it from Software Center or the Application Catalog
  2. We need to allow access to Software Center in order for our server admins to kick off Windows Updates, and install applications as necessary, from Software Center.

To address this, I started exploring what options were available to avoid unnecessarily drawing attention to the Software Center and allowing admins access for maintenance purposes.

The Software Center Shortcut

The first course of action would be to delete the ‘Microsoft System Center’ directory in:

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\


Truthfully, deleting the shortcut would immediately obscure Software Center from search which should prevent most customers from launching it but it’s not a silver bullet.

The softwarecenter: URI/protocol

If someone is a command line warrior they may know about launching Software Center via the softwarecenter: uniform resource identifier (URI).  As you probably already know, this URI is super handy for sending shortcuts to customers to specific applications via email or an Intranet page but it’s presence naturally poses a problem because leaving it available, provides a valid Software Center entry point.

In order to eliminate this shortcut, you need the protocol details from the registry:

Delete the ‘softwarecenter’ key from HKEY_CLASSES_ROOT:

reg delete "HKEY_CLASSES_ROOT\softwarecenter" /f

Delete the ‘softwarecenter’ key from HKEY_LOCAL_MACHINE\Software\Classes:

reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\softwarecenter" /f


This would help to address those cases where we send out an email communication with a link to some software we want to highlight and the reader is in Citrix.
This also breaks it for those command line warriors that know about softwarecenter:.

Software Center EXE’s

Even with all the work done above, if a notification appears and a customer clicks the notification, it would still launch Software Center.  Also, if someone happened to know the path to Software Center they could just launch it manually.  The former should be handled at a higher level (more on that below) but the latter can technically be addressed on the host itself but remember:

Just because we can do something doesn’t mean we should.

Although it is not likely that our customers know about this, there are two executables for Software Center:

  • %WinDir%\CCM\SCClient.exe
  • %WinDir%\CCM\ClientUX\SCClient.exe

The one that’s presented to customers depends on the version of Software Center you’re using:

  1. If you’re using the older Software Center UI the former is launched.
  2. If you’re presenting the newer Software Center UI, the latter is launched.

You can figure out which one is the default by querying this registry key:


To prevent customers from running them we have some options:

  1. Delete the EXE’s
  2. Rename the EXE’s
  3. Apply permissions on the EXE’s to prevent non-Administrators from executing
  4. Apply permissions on the parent directories to block access to non-Administrators


In my humble opinion, this is tricky for a variety of reasons:

  1. Assuming you did one of the above, if a customer tried to access Software Center, perhaps via notification or otherwise, some unfriendly errors would be thrown making for a poor customer experience.
  2. The method you choose depends on which version you’re using: old or new.
    Since I’m a believer of making things ‘ID 10 T’ proof, I would use the same approach for both to eliminate any potential gaps.
  3. Depending on the approach you take, there may be some potential ramifications.
    I don’t believe deleting or renaming is wise but it is an option.
  4. When the ConfigMgr client performs it’s health checks, would it undo all of this?
  5. If someone repairs the client, would that undo all of this?
  6. When the client is upgraded, would that undo all of this?
  7. No idea on the level of supportability of these actions.

For me there are just too many unknowns for this to be a viable solution.

Fixing it at a Higher Level

This in my opinion should be the real starting point as it’s one half of the ‘meat & potatoes’ of this post.

Client Settings Level

Create a new Client Settings policy deployed to the Device Collection you created above with one setting change within the Computer Agent Setting:

Install Permissions

Set ‘Install permissions’ to something other than ‘All Users’ which is the default:

  1. Only Administrators: Users must be a member of the local Administrators group.
  2. Only Administrators and primary users: Users must be a member of the local Administrators group, or a primary user of the computer.
  3. No Users: No users signed in to a client computer can initiate the installation of Software from the Application Catalog or Software Center and Software Updates or Task Sequences from the Software Center.


By setting it to ‘Only Administrators’ you’ve effectively killed Software Center’s usefulness for the every-day Citrix user, even if they tried to initiate the installation it from the Application Catalog.  That is of course assuming your Citrix users are not local administrators on Citrix servers.  (Hint: they shouldn’t be!)

OPTIONAL: Show Notifications

Set ‘Show notifications for new deployments’ to ‘No’ versus the default of ‘Yes’:

Choose Yes to display a notification for deployments available for less than a week. This message appears each time the client agent starts.


This will help prevent unnecessary notifications that would draw unnecessary attention to Software Center.

Collection Level

Put all these special machines into a Device Collection and only deploy what you need to deploy to those machines.


This is probably just leading practice advice but you should keep your deployments tight so they’re reaching the intended audience.  There isn’t much to gain in making Office 365 available to ‘All Systems’ if it would only ever be installed on Windows 10 Workstations and not on machines running Windows 7 or a Windows Server OS.

Deployment Level

When deploying things to the special Device Collection you created above, make sure you hide the notifications and optionally hide them from Software Center altogether.


This will help prevent unnecessary notifications that would draw unnecessary attention to Software Center.

Application Level

On the Deployment Type, add an Operating System requirement so that it must be non-Server OS.

Alternatively you can create your own Create a Global Condition specifically for these machines and add it to your applications.


This is a double edged sword, a bit tedious and potentially overkill considering the alternative options that are easier to implement.

Excluding Software Center During Installation of ConfigMgr Client

This in my opinion is the other half of the ‘meat & potatoes’ of this post.

If you’re installing the ConfigMgr Client manually you can exclude Software Center at installation time by running the following command line:

ccmsetup.exe /excludefeatures:clientui

But since all of these machines were built via an SCCM OSD Task Sequence we’re relying on the stock ‘Setup Windows and ConfigMgr’ Task Sequence step to get the ConfigMgr client loaded.  Since that’s all handled internally, we don’t have a way to alter the command line to add that specific switch.

Although to be fair, we can technically run this during or after OSD completes, I’m just not a big fan of doing things like that:

ccmsetup.exe /forceinstall /excludefeatures:clientui

But that was the golden nugget I needed!  I figured since there’s an argument for this to remove it, maybe there’s something we could do at installation time to prevent it from running.  A little sleuthing (i.e.: enabling verbose Windows Installer logging, running the above commands then reviewing the log files generated) revealed two new – to me anyway – MSI properties that appeared to be relevant:


Bingo was his name!  At the very least the CCMEXCLUDEDFEATURES=ClientUI property/value pair can be added to the ‘Setup Windows and ConfigMgr’ Task Sequence step so we can prevent Software Center from coming down in one fell swoop.

After re-imaging a server:

  • the Software Center icon was not present
  • the softwarecenter: URI/protocol was not functional
  • the Software Center Client executables were not present


This is arguably the best method for eliminating all avenues to Software Center since it’s completely supported and will persist through client upgrades, health checks and all that.

BONUS: Software Center Portability

Now that we’ve sorted out the customer facing pieces we needed to shift our focus to our server admins.

Early on in the Citrix project there was a need to make sure a Citrix/server admin could access Software Center to kick off the installation of patches or install new or updated core software the Citrix server needed.  As a result of the change made above we killed their ability to do that.  Fortunately Software Center appears to be ‘portable’ in that we can copy up the %WinDir%\CCM\ClientUX directory to a network share and run it from there and it works as expected.

There are however two concerns with this approach::

  1. Supportability – If Software Center doesn’t work properly, we may not be able to get support from Microsoft on this.
  2. Someone will have to maintain this repository each time we upgrade ConfigMgr or apply a ConfigMgr patch.

We’ve been using this configuration for a while now and so far, it has been working fine without issue.  Good news is we’re now relying on automation to get these server’s patched so there isn’t as much reliance on Software Center as there once was.

In Closing

Is this the end all be all?  No, I doubt it.  Clearly there are many ways to ‘nerf’ or limit access to Software Center depending on the nature of the situation and hopefully one of these helps you in that endeavor.  If you are using another method, tell me about it in the comments!

For now I bid you Good Providence!

Task Sequence Fails to Start 0x80041032

Recommended reading:

After preparing a 1730 upgrade Task Sequence for our 1607 machines, I kicked it off on a box via Software Center and walked away once the status changed to ‘Installing thinking I’d come back to an upgraded machine an hour later.  To my surprise, I was still logged on and the TS was still ‘running’.  A few hours later the button was back to ‘Install’ with a status of ‘Available’.  Thinking I goofed I tried again and the same thing happened.

I assumed it was unique to this one machine so I tried it on another and it behaved the same way.  I then ran the upgrade sequence on 5 other machines and they all exhibited the same behavior.  I knew the Task Sequence was sound because others were using it, so it was definitely something unique to my machines but what?

Since I was doing this on 1607 machines I tried upgrading form 1511 to 1703 and 1511 to 1607 but they too failed the same way confirming it was not Task Sequence specific but again unique to my machines.  After spending a quite a few cycles on this, my original machine started failing differently: I was now seeing a ‘Retry’ button with a status of ‘Failed’.  I checked the smsts.log but it didn’t have a recent date/time stamp so it never got that far.  Hmm…

Check the TSAgent.log

Opening the TSAgent.log file I could see some 80070002 errors about not being able to delete HKLM\Software\Microsoft\SMS\Task Sequence\Active Request Handle but the real cause was a bit further up.


The lines of interest:

Getting assignments from local WMI. TSAgent 9/1/2017 12:58:27 PM 1748 (0x06D4)
pIWBEMServices->;;ExecQuery (BString(L"WQL"), BString (L"select * from XXX_Policy_Policy4"), WBEM_FLAG_FORWARD_ONLY, NULL, &pWBEMInstanceEnum), HRESULT=80041032 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,3205) TSAgent 9/1/2017 1:03:55 PM 1748 (0x06D4)
Query for assigned policies failed. 80041032 TSAgent 9/1/2017 1:03:55 PM 1748 (0x06D4)oPolicyAssignments.RequestAssignmentsLocally(), HRESULT=80041032 (e:\cm1702_rtm\sms\framework\tscore\tspolicy.cpp,990) TSAgent 9/1/2017 1:03:55 PM 1748 (0x06D4)
Failed to get assignments from local WMI (Code 0x80041032) TSAgent 9/1/2017 1:03:55 PM 1748 (0x06D4)

The source of error code 80041032 is Windows Management (WMI) and translates to ‘Call cancelled’ which presumably happened while running the query select * from XXX_Policy_Policy4, where XXX is the site code.

I ran a similar query on my machine to get a feel for the number of items in there:

(gwmi -Class xxx_policy_policy4 -Namespace root\xxx\Policy\machine\RequestedConfig).Count

Which ended up failing with a Quota violation error suggesting I’ve reached the WMI memory quota.

Increase WMI MemoryPerHost & MemoryAllHosts

Fortunately, there’s a super helpful TechNet Blog post about this.  Since all of my test machines were running into this, I decided to make life easier for myself and use PowerShell to accomplish the task on a few of them thinking I’d have to raise the limit once.

$PHQC = gwmi -Class __providerhostquotaconfiguration -Namespace root
$PHQC.MemoryPerHost = 805306368
# Below is optional but mentioned in the article
#$PHQC.MemoryAllHosts = 2147483648

After the machine came up I ran the same query again, and after 2 minutes and 38 seconds it returned over 1800 items.  Great!  I ran it again and after 5 minutes it failed with the same quota violation error.  Boo urns.  I kept raising MemoryPerHost and MemoryAllHosts to insane levels to get the query to run back to back successfully.

The good news is that I made progress suggesting I’m definitely hitting some sort of memory ceiling that has now been raised.

The bad news is why me and not others?  Hmm…

Root Cause Analysis

I checked the deployments available to that machine and wowzers it was super long.  I won’t embarrass myself by posting an image of that but it was very long.  This helped to identify areas of improvement in the way we’re managing collections & deploying things, be it Applications, Packages, Software Updates and so on.

On my patient zero machine I ran the following to clear out the policies stored in WMI:

gwmi -namespace root\xxx\softmgmtagent -query "select * from ccm_tsexecutionrequest" | remove-wmiobject

gwmi -namespace root\xxx -query "select * from sms_maintenancetaskrequests" | remove-wmiobject

restart-service -name ccmexec

I then downloaded the policies and tried to image – it worked!  I decided to let that machine go and focus on some administrative cleanup in SCCM.  After tidying things up a bit, the rest of my 1607 machines started the 1703 upgrade Task Sequence without issue and the 1511 machines ran the 1607 upgrade Task Sequence as well.

As we continue to phase out Windows 7, we’ll hopefully update our methods to help avoid problems like this and perform that routine maintenance a little more frequently.