Unable to Uninstall Exchange Server 2016 Due to MpsSvc Access Denied Error

Craig Power
Copper Contributor
May 14, 2018
Thanks for the response, Mitch. I have tried disabling Windows Defender Firewall, but Exchange's Setup.exe still fails with the same

The MpsSvc service is running as Local Service; it just doesn't seem to be able to be modified by Exchange's Setup.exe (and yes, I'm running Setup.exe from an elevated command prompt, using an administrative account.) As mentioned, disabling Windows Defender Firewall does not help. (I haven't yet tried trying to disable the MpsSvc outright, because I don't think that I will able to, even if starting in Safe Mode, and I also don't think that it will help with the core issue of Exchange's Setup.exe not being able to modify the properties of the service.)

The initial purpose of this task was to install the Exchange Management Shell (EMS) PowerShell tools on the administrative workstation so that scripting could be performed from there, rather than directly from the server console. Microsoft has been making it increasingly clear that they don't want sysadmins to be managing servers directly from the servers' consoles (as evidenced by Server Core, Windows Admin Center, comments published by Microsoft, etc.), so I'm just trying to get with Microsoft's program. Installing the EMS on a client workstation is supposedly supported, as per the following reference from https://technet.microsoft.com/en-us/library/bb232090(v=exchg.160).aspx:

The management tools in Exchange Server 2016 include the Exchange Management Shell and the Exchange Toolbox. You can install the management tools on other client computers or servers in the Active Directory domain to help you manage your Exchange organization. The management tools have similar operating system, .NET Framework, and Windows Management Framework (Windows PowerShell) requirements as an Exchange server. The notable exception is: you can install the management tools on client versions of Windows.
I have no idea how Exchange Setup allowed anything beyond the management tools to be installed on a non-server OS, though. The only component that I selected for installation on the admin workstation was the management tools. There may be a bug in Microsoft's prerequisite validation or the like that resulted in actual Exchange Server components being installed on the workstation.

Looking into it further, it appears that only TrustedInstaller has permissions to the MpsSvc service, so I'm thinking I'm going to need to either try to see if I can change the permissions on that service so that the administrative account has access to it, or just manually remove the errant Exchange server from the organization using ADSI Edit. If I mess with the permissions of the MpsSvc, I'll probably need to rebuild the administrative workstation afterwards, because I'm not sure that I would still trust it after that, so I would much rather uninstall cleanly using Microsoft's Setup.exe.

Any other suggestions would be welcome.
- TAE_YOUN_ANN
  MVP
  May 15, 2018
  Hi. Craig
  
  Run the following in the PowerShell and proceed
  
  Set-ExecutionPolicy Unrestricted
  - Craig Power
    Copper Contributor
    May 15, 2018
    Just to close the loop with this, I contacted Microsoft Support (via Volume Licensing email support for Exchange Server.) They recommended creating a brand-new Exchange user mailbox, with the user being a member of Domain Admins, Enterprise Admins, Schema Admins, Organization Management, and the affected workstation's local Administrators group, then logging into the workstation under that account and attempting to uninstall Exchange from an elevated Exchange Management Shell session. This failed with the same error as previously described.
    
    Their next recommended action was to delete the workstation-based Exchange server from the Exchange configuration via ADSI Edit, under the following location:
    
    Configuration Container
    CN=Configuration, DC=Domain_Name,DC=com
    CN=Services
    CN=Microsoft Exchange
    CN=Your_Organization_Name
    CN=Administrative Groups
    CN=Your_Administrative_Group_Name
    CN=Servers
    
    I was aware of how to do this, but was reluctant to take that step out of concern of leaving "debris" in the Exchange configuration. But since other steps were not working, this is what I ended up doing. Hopefully there will not be any repercussions from such a "brute force" method of removing the errant workstation-based Exchange server from the organization.
    
    Microsoft also recommended using the SysInternals AccessChk utility, with the command
    AccessChk -c MpsSvc -v >c:\mps.txt
    and the sc command
    sc sdshow MpsSvc >c:\mps2.txt
    to get information regarding the permissions of the MpsSvc if I wanted them to perform more troubleshooting. I didn't pursue this, though, because I opted for the brute force removal method, making collecting this data moot.
    
    Thanks for all who contributed trying to help.

Forum Discussion

Unable to Uninstall Exchange Server 2016 Due to MpsSvc Access Denied Error

Share

Resources