SCOM – Exchange Client Proxy Error

I was implementing System Center Operations Manager in a project at a customer for monitoring Exchange.
After loading the Exchange Management Pack, a bunch of errors like these were logged:

The Ehlo options for the client proxy target 10.2.38.164 did not match while setting up proxy for user on inbound session 08D2F00F25C773B2. The critical non-matching options were <maxSize>. The non-critical non-matching options were <NONE>. Client proxying will continue.

The Ehlo options for the client proxy target did not match while setting up proxy for user on inbound session 08D2F00F25C773B2. The critical non-matching options were . The non-critical non-matching options were . Client proxying will continue.

This error is logged for servers holding the mailbox role, even though it states Hub Transport in the source (that is no longer a standalone role in Exchange 2013).

 

So, looking at the alert description we can see it somehow relates to max size, and is generated in response to the EHLO options when a test connection is made to the server in question.
To dig into this, we need to determine the what the maximum message size defined in the Exchange organization is. This can be done using an Exchange Management Shell with this command:

Get-TransportConfig | ft maxsendsize, maxreceivesize

This lists the sizes configured for the Exchange organization.

Next, we need to determine which receive connector is configured with the different limit. This can be done by either looking at the receive connectors on the server listed in the error or running a command to list all receive connectors in the organization and correct those who deviate:

Get-ReceiveConnector | ft name, maxmessagesize

Examine the output, find the receive connector in question and correct its message size restriction. Or use this command to find all receive connectors with the deviating limit and correct them at the same time. Change the MB limit to fit your need.

Get-ReceiveConnector | Where-Object {$_.maxmessagesize -ne 35MB} | set-receiveconnector -maxmessagesize 35MB

Restart the Exchange Transport Service and voila, the error will go away.

Un-installing Exchange 2013 server fails with “Setup can’t continue with the uninstall because the eseutil has open files”

So, I was at a customer uninstalling an Exchange 2013 server as the customer had finished their migration to Office 365.

Went through the usual process of decommissioning the server, such as ensuring no mailboxes where left, removing arbitration boxes and so on.
Got to the point where the actual uninstall could take place, and was faced with this:

E2K13 eseutil uninstall error

Thought to myself, that was kinda weird… Looking in Task Manager showed that ESEUTIL has a lot of processes running:

E2K13 eseutil task manager

Well, since all data had been migrated away from the server and all databases had been removed I didn’t see much point in finding out why all these ESEUTIL processes where spawned.

A simple reboot later, and the uninstall procedure continued without any problems.

Quickly setting up an Exchange 2010 or 2013 DAG cluster…

So, you’ve installed a couple of Exchange 2010 or 2013 servers and want to setup DAG quick and easy…

Well, just copy/paste these powershell commands (and edit the few parameters that can vary from your installation and you’re good to go.

Create DAG cluster

New-DatabaseAvailabilityGroup -Name <network name of DAG cluster> -WitnessServer <Netbios name of witness server> -WitnessDirectory <local path on witness server to where you want the witness directory stored> -DatabaseAvailabilityGroupIPAddresses <IP address of DAG cluster>

This will form the DAG cluster.

Add nodes to DAG cluster

Add-DatabaseAvailabilityGroupServer -Id <netbios name of DAG cluster> -MailboxServer <Netbios name of server to be added>

This will add the server in question to the DAG cluster and the command must be run once per server to be added (unless you use an answer file, but I won’t cover that here).

Create databases

New-MailboxDatabase -Name <Name of mailbox database> -EDBFilePath <Local path to where you want the file stored, remember to include filename and extension of the EDB file> -LogFolderPath <Local path to where you want the log files to be created>

This will create the databases you want. Remember that the paths chosen above must be available on all servers.

Move arbitration, system or discovery mailboxes to the newly created databases

Get-MailboxDatabase -Arbitration | New-MoveRequest -TargetDatabase <name of target mailbox database>

This will start to move the arbitration mailboxes to the selected database. Use this only if you want to delete the default database. Otherwise, continue to “Add database copies to database”

Check status the move requests created above

Get-MoveRequest

This will show the status of the move requests created above. Once they all lists as completed, you can go ahead and delete them as I will show below.

Delete the move requests created above

Get-MoveRequest | Remove-MoveRequest

This will remove the move requests listed above and you will be able to delete the default database created during installation.

Cleanup disconnected mailboxes

Get-MailboxStatistics –Database <name of database to be removed> | Where-Object {$_.DisconnectReason –eq ‘Softdeleted’} | ForEach {Remove-StoreMailbox –Database $_.database –identity $_.mailboxguid –MailboxState Softdeleted

Remove default database

Remove-MailboxDatabase -Identity <Name of the database you wish to remove>

This will remove the database specified. This must be done once per DAG node you installed, as each mailbox server that is installed will create a default database.

Add database copies to databases

Get-MailboxDatabase | Where-Object {$_.replicationtype -ne ‘Remote’} | Add-MailboxDatabaseCopy -MailboxServer <Netbios name of server to be added> -ActivationPreference <activation preference in number form>

This command adds the mailbox database copy to the server in question. Off course the server must be added as a DAG node as done above. I’ve purposely built the command to scan for non-replicated databases, so it can be used on a later occasion if you add more databases.
The activation prefence lists in what order you want the servers to activate the database, for example 1 is primary, 2 is secondary, 3 is tertiary and so on. If you are adding more than one additional server, the above command can also be used by appending | Add-MailboxDatabaseCopy -MailboxServer <Netbios name of server to be added> -ActivationPreference <activation preference in number form> and simply change the server name as well as increment the activation preference number.

With these steps, you have a running Exchange 2010 or 2013 DAG cluster and are ready to deploy mailboxes on these…

Exchange 2010 setup fails with “There are no more endpoints available from the endpoint mapper”…

So, first blog post here at my new blog 🙂

I’m currently working on a project for a customer wanting to upgrade their aging Exchange 2003 platform (which one must say is about time) to Exchange 2013. As this co-existence scenario is not supported we need to take an intermediate step and implement Exchange 2010 first.

As we were installing the first Exchange 2010 server it threw when trying to install the Hub Transport Role:

There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

As a result the installer ended and left us stranded there.

So first off, we needed to figure out why the RPC endpoint mapper error occured as we would most likely encounter it once more. Going through the requirements listed on the official Technet pages, I found that the customer had for some reason disabled Windows Firewall (as in the service, not just through Windows Firewall MMC snap-in).
This could be the likely reason for this error to occur, so we re-enabled it and tried to restart the installer but it then gave this message:

A setup failure previously occurred while installing the HubTransport role. Either run Setup Again for just this role, or remove the role using control panel

So, the error should be pretty forward as stated in the error message. But restarting the setup notified us that we needed to re-run it from Control Panel and going there didn’t allow us to either install nor uninstall (as nothing was actually installed on the server as a result of the first error).
As the Exchange installer runs, it writes various registry keys to keep track of the installation process. Removing these keys put us back on track to a successful installation.
We simply deleted the keys Watermark and Action located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\HubTransportRole (and as always, make a backup of anything before you edit the registry).

So, after doing this we were able to run a successful installation of Exchange 2010 🙂