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

[Craig Power]

I am unable to uninstall Exchange Server 2016 on a Windows 10 v1709 computer.  Running setup.exe /mode:uninstall, I receive the following error during the prerequisites check:

-----

The following error was generated when "$error.Clear();
 if (Get-Service
MpsSvc* | ?{$_.Name -eq 'MpsSvc'})
 {
 Set-Service MpsSvc -StartupType
Automatic
 Start-SetupService -ServiceName MpsSvc
 }
 " was run:
"Microsoft.PowerShell.Commands.ServiceCommandException: Service 'Windows
Defender Firewall (MpsSvc)' cannot be configured due to the following error:
Access is denied ---> System.ComponentModel.Win32Exception: Access is denied

-----

I am attempting to uninstall while using a domain admin / Exchange admin account, which is also an administrator on the administrative workstation.

What do I need to do so that Exchange Setup passes this prerequisite check to allow Exchange to be uninstalled from the administative workstation?

As background, I was trying to install only the Exchange management tools on a workstation that is used for system administration.  Upon initially running Exchange Setup via the GUI on the administrative workstation and selecting only the management tools option, I received a message indicating that a previous installation had been attempted, and would I like to try to continue with that installation, to which I responded Yes.  (I had tried to install the management tools previously, but the installation at that time failed.  However, I do not recall what the specific installation error was for that failed installation attempt.)

After allowing the Exchange installation to continue, the result was that the installation completed successfully, but appears to have installed a full instance of Exchange Server on the workstation, not just the management tools.  This has now resulted in the administrative workstation now hosting shadow queues for Exchange, which is intefering with mail delivery (the intended environment is just a single-server Exchange installation.)

[#2]

Temporarily disable windows defender.

[#3]

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.

[#4]

Hi. Craig

Run the following in the PowerShell and proceed

Set-ExecutionPolicy Unrestricted

[#5]

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.

[#6]

@Craig Power 
Не хватает прав на управление службой

AccessChk -c MpsSvc -v >c:\mps.txt

MpsSvc

  Medium Mandatory Level (Default) [No-Write-Up]

  R  NT AUTHORITY\Authenticated Users

                SERVICE_QUERY_STATUS

                SERVICE_QUERY_CONFIG

                SERVICE_INTERROGATE

                READ_CONTROL

  RW NT AUTHORITY\SYSTEM

                SERVICE_QUERY_STATUS

                SERVICE_QUERY_CONFIG

                SERVICE_CHANGE_CONFIG

                SERVICE_INTERROGATE

                SERVICE_ENUMERATE_DEPENDENTS

                SERVICE_START

                READ_CONTROL

                WRITE_DAC

                WRITE_OWNER

  RW BUILTIN\Administrators

                SERVICE_QUERY_STATUS

                SERVICE_QUERY_CONFIG

                SERVICE_INTERROGATE

                SERVICE_ENUMERATE_DEPENDENTS

                SERVICE_START

                READ_CONTROL

                WRITE_DAC

                WRITE_OWNER

  R  BUILTIN\Users

                SERVICE_QUERY_STATUS

Получение текуших разрешений на службу:

C:\WINDOWS\system32>sc sdshow MpsSvc

D:(A;;CCLCLORC;;;AU)(A;;CCDCLCSWRPLORCWDWO;;;SY)(A;;CCLCSWRPLORCWDWO;;;BA)(A;;CCLCLO;;;BU)S:(AU;FA;CCDCLCSWRPWPDTLOSDRCWDWO;;;WD)

https://habr.com/ru/post/75090/

Последние 2 буквы обозначают кому мы разрешаем или запрещаем:

EA Enterprise administrators

BA Built-in administrators

SY Local system

Добавление прав для EA как у SY:

sc sdset MpsSvc D:(A;;CCLCLORC;;;AU)(A;;CCDCLCSWRPLORCWDWO;;;SY)(A;;CCLCSWRPLORCWDWO;;;BA)(A;;CCLCLO;;;BU)(A;;CCDCLCSWRPLORCWDWO;;;EA)S:(AU;FA;CCDCLCSWRPWPDTLOSDRCWDWO;;;WD)