Recently I started migrating from Exchange 2013 to 2019.  As you might imagine installing the first Exchange 2019 server is a big deal.  I spent a lot of time preparing, but still hit a few issues, and wanted to document them here.

Setup initially failed with the below error:

The following error was generated when “$error.Clear();
Set-LocalPermissions

” was run: “System.Security.AccessControl.PrivilegeNotHeldException: The process does not possess the ‘SeSecurityPrivilege’ privilege which is required for this operation.
at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
at Microsoft.Exchange.Management.Deployment.SetLocalPermissions.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)”.

The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.

Note: There were similar errors in the ExchangeSetup.log file.

An internet search for “The process does not possess the ‘SeSecurityPrivilege’ privilege which is required for this operation.” turned up a rather old Technet discussion which mentioned 5 potentially missing user rights assignments.  After checking each I determined that even though the installation account was a domain admin it didn’t have the “Manage Auditing and Security Log” right.

Limiting access to this this right is a common security hardening measure.  Doing a cursory search I found Microsoft mentioning the vulnerability and countermeasures here and here.  They tersely state that “Manage Auditing and Security Logs” enables the erasure of important evidence of unauthorized activity.  Luckily I’ve got friends in the security business who gave the more articulate summary below:

“Naturally, an attacker wants to go undetected as long as possible. If the attacker has access to “Manage Auditing and Security Logs”, they can clear or simply change the logging to hide their malicious activity.  Limiting access to this right denies an attacker the ability to easily cover their tracks and helps ensure an organization’s detection and forensic capabilities.” -Kevin Kidder, KidderSec Technologies LLC.

In an enterprise environment these restrictions are most likely delivered through group policy, however to resolve the issue in the near-term I added the installation account to the local “Event Log Readers” group. That grants the right at least for the duration of the install, but I’ll have to address it more eloquently later. Unfortunately subsequent installation attempts failed with the below error:

FAILED

A Setup failure previously occurred while installing the AdminTools role. Either run Setup again for just this role, or remove the role using Control Panel. For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.InstallWatermark.aspx

Note: There’s no “AdminTools” role they probably mean Management Tools.

Apparently, the previous failure did some damage. This must have something to do with tracking installation progress, possibly for the purpose of recovery.  The link was to documentation of a 2016 readiness check.  I might forgive that if it had anything useful, but it was little more than an apology for not having any information at all:

ms.exch.setupreadiness.InstallWatermark

“Sorry, but we haven’t added content for this Exchange 2016 readiness check yet. However, we’re gathering feedback that will help us add the most relevant content to this topic. Please take a minute to send us feedback about the information you were hoping to find.”

I directly checked the 2019 readiness check documentation but didn’t find anything.  I did find documentation for an Exchange 2013 readiness check, but it was no help in resolving the issue. It merely suggested a reinstall albeit with an unusual syntax.  I tried it anyway and it didn’t work either.

Eventually I tried a complete uninstall and reboot, but even that didn’t get me past the error.

Out of desperation I decided to go hunting in the Registry and wouldn’t you know, the very first place I looked I found a lead.

I renamed the key as seen above, I reran the installation and it went through without issue. Of course this also proves the lack of “Manage Auditing and Security Log” right caused the initial issue. I’ll have to follow-up to determine if the right is needed permanently or just for the installation.

If anyone else encounters the “watermark” issue, regardless of the cause, I recommend uninstalling first.  If that doesn’t work seek & delete the registry key then retry the installation.  I wouldn’t recommend forcing the installation to proceed by deleting the key without first uninstalling.

A few recommendations I’ll be passing to Microsoft:

1. There should be readiness checks for the required rights.  Microsoft has recommendations around user rights assignments and should be prepared for the possibility their customers have implemented those recommendations. It seems reasonable to check for the required rights before allowing a flawed installation to continue.
2. Microsoft should document both the installation tracking mechanism and the “watermark” readiness check.  That alone would’ve saved me a lot of time and frustration.
3. The uninstall procedure should’ve cleaned up the registry.

Hopefully Microsoft will address these problems. In the meantime, I hope this post helps you get through these installation issues a little easier.  Feedback is always welcomed, comment, click follow or grab the RSS feed to get notifications of future posts.