Installing Exchange Server 2016 is a relatively painless process provided you take care of the requirements. To test Exchange 2016, I set up a very basic environment on my vSphere home lab with one virtual machine acting as a 2012 based DC and a second one running Exchange Server 2016 sporting the Mailbox role. It is worth mentioning that the Client Access server role has now been amalgamated within the Mailbox server role. This means that, unlike previous versions of Exchange, you can no longer install the Client Access server role separately.
This link outlines the revisited architecture for this latest release of Exchange Server.
Before installing Exchange make sure you do the following;
On the Domain Controller Server:
- Log in using an account which is a member of the Enterprise Admins group
- Mount the Exchange ISO image and run the following;
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms Setup.exe /PrepareAD /OrganizationName:"<organization name>" /IAcceptExchangeServerLicenseTerms Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms
On the Exchange Server:
- Open an administrative PowerShell windows and run the following;
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation
- Install NET Framework 4.5.2
- Install Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
Like I said, installing Exchange 2016 was a straight-forward affair. Everything worked out of the box so I proceeded to finalise the post-installation tasks using the Exchange Admin Center (https://<exchange hostname or ip>/ecp). Again no big deal. Next, I created a mailbox user and fired up Outlook Web App to verify mail flow both internal and external .
To my dismay, any email I tried to send ended up being permanently stuck under the Drafts folder. Putting on my troubleshooting cap, I re-visited the send and receive connectors, created another mailbox to test with and checked some other settings, but the problem persisted. Looking at the application log I noticed a multitude of warnings with an Event ID of 9041.
I also checked the submission logs under C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Mailbox\Connectivity\Submission; pretty obvious something’s wrong on the SMTP front.
2015-12-09T09:59:50.787Z, 08D2FF21CFBE93C3,MapiSubmission, f73a6bf3-abce-476a-8f11-493ef0c9b297,>,"Failed; HResult: 2684354560; DiagnosticInfo: Stage:CommitMailItem, SmtpResponse:441 4.4.1 Error encountered while communicating with primary target IP address: "421 4.3.2 Service not active." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was 192.168.11.171: 2525, details:FailedRecipientCount:0; RetryRecipientCount:0"
Running netstat –aon | findstr “:25” told me the server is correctly listening on port 25 . To make sure, I telnet’ed to port 25 and issued a few SMTP commands to test email submission. I got the same “421 4.3.2 Service not active” error as in the logs above the second I hit enter on the MAIL FROM: <email address> line.
MAIL FROM: email@example.com 421 4.3.2 Service not active
A ton of articles and Google search requests later and I was still one cure short. I learned that this is quite a common problem judging by the number of help requests I came across and it spans Exchange versions 2007 to 2016.
At one point I stumbled on the Get-ServerComponentState Exchange 2016 PowerShell cmdlet, and decided to give it a shot. Bingo! The command returned a list of components all of which inactive. Definitely not good!
Fixing it, entailed running yet another cmdlet this time;
set-servercomponentstate <Exchange server name> -component ServerWideOffLine -State Active -Requester Functional
Note: Activating the ServerWideOffLine component automatically activates all the other components save for a couple which are left inactive by default. Also, if the components fail to activate, try changing the requester type choosing HealthAPI, Maintenance, Sidelined, Functional or Deployment.
I also restarted the transport service for good measure;
Restart-Service –name MsExchangeTransport
So, back to testing mail flow, I telnet’ed to port 25 and carried out the previous manual SMTP procedure and lo and behold, the smtp service responded to the commands without a hiccup. I signed in OWA and as I was hoping for, found zilch emails under Draft folder with a dozen or so test emails sitting in my test account’s Inbox.
I rebooted the server to make sure that once up, the components retained an active state which was the case. Job done.
To be honest, I am not sure why this happened considering this was a fresh installation. That said, I remember trying to install the edge-transport role which for some reason failed. Perhaps this left the components in a state of limbo hence the issue.
Anyway, the moral of the story is, make sure to check the components state before trying anything else should you come across this issue.
Hope you found this information useful.