Setup Wizard for Exchange Update Rollup ended prematurely

The issue is well-known, but I never got around to share it myself and just recently saw it once again at a customer, who experienced the problem.
This blog post will cover how to install and the Exchange Rollup Update successfully without getting the “Ended prematurely” error.
The Setup Wizard for Update Rollup fails with the error “ended prematurely”. It has been the same issue for Update Rollups for both Exchange 2007 and Exchange 2010.
The installer fails with the information:

Setup Wizard for Update Rollup 5 for Exchange Server 2010 Service Pack 3 (KB2917508) ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again.

The screen dump below also shows what error look like:

The reason for the error and why the Update Rollup installer is “ended prematurely” is because the server has User Access Control (UAC) activated on the server. For good reason, it is not recommended to disable the UAC.
The error is also shown in the event log, as Event ID: 1024 and with error code 1603.

How to Install the Update Rollup

The recommended process for installing Update Rollups on the server, is using an elevated command prompt (Open a CMD with Run As Administrator) and make sure the Update Rollup is located on a local drive of the server and start the installer using:
SYNTAX example: msiexec /update <UPDATE .MSP FILE>
How to Start Setup Wizard:

msiexec /update Exchange2010-KB2917508-x64-en.msp

How to install the Update Rollup unattended (silent) add the following parameter (/quiet):

msiexec /update Exchange2010-KB2917508-x64-en.msp /quiet

Example as elevated command prompt starting the Update Rollup installer:

This will start the Setup Wizard and you can now walk your way through the installer and install the Update Rollup and when it has been installed, you should see the following:

Other reasons for failing

The above is the most obvious reason for why the Update Rollup fails with “ended prematurely”, but if you see error codes 1603 or 1635 in the event log, there could be other reasons.

Allow IP in SMTP Replay Exchange 2013

In Exchange 2013, I am utilizing a multi-role server that has both the Client Access Server and Mailbox Server roles. We’ll want to head to the mail flow section in the Exchange Administration Center (EAC) that you can access by going to https://OWA.domain.com/ECP.

Once in this mail flow section, we’ll click the tab called receive connectors which will allow us to see all receive connectors that exist.

As you can see, there are connectors for FrontendTransport and connectors for HubTransport.  FrontEndTransport belongs to the Client Access Server Role and the HubTransport role belongs to the Mailbox Server role.
Let’s take a look at the “Default B-E15DAG1″ receive connector that belongs to the HubTransport role  as well as the “Default Frontend B-E15DAG1″ that belongs to the FrontendTransport role.
Taking a look at the “Default FrontEnd B-E15DAG1″, we can see that the connector listens on port 25 as we would expect.

Taking a look at the “Default B-E15DAG1″ receive connector, we can see it listens on port 2525 which is something we haven’t seen before.

All mail flow should come into the Frontend Transport which then delivers it to the appropriate mailbox server where the mailboxes exist.  On a multi-role server, these two roles cannot utilize the same ports as they are two different services.  What this means is, when creating a relay connector, this connector must be created on the Client Access Server role that owns the Frontend Transport because this service is the service that owns port 25.  If you try to create a receive connector on the Mailbox Server role that owns the HubTransport service, mail flow may work temporarily, but it will eventually fail due to both the FrontendTransport and HubTransport services fighting each other for port 25.  Obviously if the Client Access Server and Mailbox Server roles are on different servers, it’s not an issue.
To create our relay connector, we’ll choose the + symbol to create a new Receive Connector.

Give the connector a name and be sure to choose Frontend Transport and Custom. Click Next.

The default settings here are fine.  We want port 25 due to what I mentioned above. Click Next.

In the remote network settings, it is important to ensure that you remove 0.0.0.0-255.255.255.255.  We want to explicitly define what servers are allowed to relay to ensure our server does not turn into an open relay for everybody.  In my case, I am going to add 192.168.50.2 which may be a printer, custom application, etc…  But the server that owns 192.168.50.2 would need to relay.  Once this is done, click Finish.

Once the relay connector is created, open its properties, go to security, and make sure you check Anonymous Users.

So what really happens when you place a check mark in the Anonymous users group in the above screenshot?  A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server.  This is NOT the case.
When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:

• Ms-Exch-SMTP-Submit
• Ms-Exch-SMTP-Accept-Any-Sender
• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
• Ms-Exch-Accept-Headers-Routing

So, as you can see, there is no Ms-Exch-SMTP-Accept-Any-Recipient permission added by default.  Because of this, users will NOT be able to relay off your Exchange Server by default.
To activate Anonymous users to use this connector for relaying, you must issue the following command: Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector.  Once this is done, any server IPs you added to the Remote Network settings will be allowed to relay off your server utilizing port 25.

Now you may be thinking, why should I create this new connector?  Well, Exchange will always look to see how specific you are on a connector.  So let’s say we have a SharePoint Server at 192.168.119.150.  We would create a relay connector and allow ONLY 192.168.119.150 to relay.  So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors.  One being the Default Receive Connector and one being the Relay Connector.  The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150.  Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).
Now, for servers that will have a lot of relay traffic, there are some more steps you need to do on your Receive Connector.  If you see that you have mail flow issues where things periodically work with relaying and sometimes they don’t, it’s recommended to run the following commands on your Relay Connector.
Set-ReceiveConnector -identity “Relay Connector Name” -TarpitInterval 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionTimeout 00:30:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionInactivityTimeout 00:20:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxAcknowledgementDelay 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnection 10000
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPercentagePerSource 100
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPerSource unlimited
So in my case, I would run the following command which would allow me to do Get-ReceiveConnector and pipe into Set-ReceiveConnector to make all the modifications in one command:
Get-ReceiveConnector -Identity “Relay Connector Name” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited

If you are wondering what the default settings were, I ran the following to view the defaults before running Set-ReceiveConnector.