You’ve created a new certificate for your Lync Server 2013 services and attempt to assign it to Server default and Web services internal:

However, the assignment fails and the following error message is displayed:

Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.

Solution

One of the reasons why the certificate assignment would fail with the error message above is if an administrator or group policy has removed the administrators group from the Lync Server’s Manage auditing and security log policy as shown in the following screenshot:

To correct the problem, simply grant the local administrators group the Manage auditing and security log policy permissions:

You should be able to assign certificates to Lync Server 2013 services once the above has been completed.

Tuesday, September 19, 2017

You’ve recently had to reset the password to the SQL authentication account used by your VMware vCenter Site Recovery Manager to connect to the SRM database so you proceed to update the ODBC System DSN as such:

However, attempting to start the VMware vCenter Site Recovery Manager service fails with the following error:

The VMware vCenter Site Recovery Manager Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.

The following event error is logged in the event logs after the failed start:

Run the installcreds.exe utility to register account credentials on the new host with the old DSN:installcreds.exe -key db:new_SRM_DSN -u sql_admin_userThe installcreds.exe utility can be found in the bin directory of the SRM installation:C:\Program Files\VMware\VMware Site Recovery Manager\bin

The following is an example of the executed command:

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>installcreds.exe -key db:SRMDR -u vmware
VMware internal use only. This program is intended for use only by the SRM installer.
Enter Password:
Installed new credentials for db:SRMDR

You have two Exchange 2016 mailbox servers configured as a DAG and one server providing witness servers. One of the mailbox server experiences an issue and goes down so the remaining mailbox server continues to service mailbox requests and has the databases mounted. The remaining operational server is restarted and you immediately notice that the databases are not mounted after the restart:

Attempting to mount the databases with the Mount-Database command throws the following error:

Executing the Get-DatabaseAvailabilityGroup cmdlet displays the following message:

Warning: Unable to get Primary Active Manager information due to an Active Manager call failure. Error: An Active Manager operation failed. Error: An Active Manager operation encountered and error. To perform this operation, the server must be a member of a database availability group, and the database availability group must have a quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does not allow auto mount. (IsAllNodesUp: False)).

Executing the Get-MailboxDatabaseCopyStatus * cmdlet indicates the status of the mailbox databases in the DAG as Unknown:

Solution

The reason why the databases would not automount and manually mounting them would fail is because the DAG has Datacenter Activation Coordination (DAC) mode enabled and this forces starting DAG members to acquire permission in order to mount any mailbox databases. In the example above, the DAG is unable to achieve a quorum with the second node down and therefore the DAG isn’t started and databases would not be able to mount. If you are sure that the second node is down as in the example above, you can manually start the DAG with the cmdlet:

Wednesday, August 23, 2017

I’ve noticed that many of my colleagues and clients have asked me about the following error that is thrown when they attempt to export an Exchange Server mailbox to PST so I thought it would be a good idea to quickly write a post about the error.

Problem

You attempt to export a mailbox to PST via the Exchange Admin Center but received the following error:

The reason why this error would be thrown is if you are trying to export a mailbox that is on a different version than the admin console you are working from. In the example above, the attempt was made from the Exchange 2016 admin center but the mailbox actually resides on an Exchange 2010 server. Simply execute the export job from the PowerShell prompt of one of the Exchange 2010 servers to get the mailbox to export.

Tuesday, August 22, 2017

I’ve recently had to migrate a client from Exchange 2010 to 2016 and quickly noticed that Outlook Anywhere no longer worked after redirecting Outlook Anywhere and other services such as autodiscover and webmail to the new server. Outlook Anywhere continued to work for users migrated to Exchange 2016 but not for users still on the legacy Exchange server. Using the Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) Outlook Connectivity feature would fail and throw the following error:

While there could be several reasons why this error would be thrown, one of the possible causes is if the Citrix session reliability port 2598 is blocked from NetScaler to application server. Ensure that the NetScaler can access the XenApp server via TCP port 2598.