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!