Is it possible to install Exchange 2016 on a domain controller?

Can we?

This is a question that comes up every now and then in the technical communities I’m involved in. Is it possible and supported to install Exchange on a domain controller? Often answered incorrectly with a variant of “not supported, unless you run SBS”. The official answer is a bit different: it is supported to install Exchange on a domain controller.

In fact, this is supported since Exchange 2000 and has not changed for every new version up to the recently released Exchange 2016. As we can find in the Exchange 2016 System Requirements page:

Installing Exchange 2016 on directory servers
For security and performance reasons, we recommend that you install Exchange 2016 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2016. After Exchange 2016 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.

So should we?

Supported but not recommended, why is that? There are multiple reasons why you should consider to install Exchange on a member servers.

Firstly both Exchange and an Active Directory domain controller are resource-intensive tasks. For instance, both need to cache data in memory for best performance and will try to claim resources to do so. Running both tasks on the same computer may impact the performance and end-user experience for both AD and Exchange.

Exchange supports an RBAC model which allows an organization to deploy the least amount of privileges to their admins to do their work. However, when an admin needs local administrative access to server which has Exchange installed he gains administrative access to Active Directory too. This would enable the admin to elevate their own privileges which of course is a security risk.

A domain controller with Exchange installed cannot be demoted to remove AD from the computer as long as Exchange is installed, the last version that did support this was Exchange 2000. This may mean that at some later time an organization may find they can’t remove domain controllers from their environment without removing Exchange from the server first. In the recent past this is something that organizations often encountered when they needed to remove Windows Server 2003 domain controllers in order to be able to raise the domain or forest functional level. By the way, you also can’t promote a server with Exchange already installed but that is a much less common scenario.

I briefly touched the subject of security when discussing your admins working on this server, security needs considered with user access in mind too. Some firewall ports need to be forwarded to this server to accept email and give access to OWA/Outlook on the web, ActiveSync, Outlook Anywhere and maybe even legacy protocols as POP3 and IMAP4. Nowadays Exchange is considered secure enough to expose it to the internet directly but do you want to allow hackers to target your domain controller too? Opening firewall ports to allow access from the internet to your domain controller is not something I would call a security best practice.

There’s even more reasons why you should not install on a Exchange server but I won’t do into too much details here. Use your favorite search engine to do a search on this topic and you will find a ton of discussions about this subject.

Yeah, but what if…?

I am aware that for some very small organizations it may not make sense to purchase additional hardware and Windows Server licenses. Certainly not from a cost perspective. With a small load it’s unlikely that performance is going to be an issue and many small business owners will consider the security implications something for large enterprises to be concerned about. After all, Microsoft until recently sold the Small Business Server products that did install Active Directory, Exchange, SharePoint, ISA/TMG and even SQL on a single box. If that was an acceptable solution, why shouldn’t we do that with just AD and Exchange?

Running Exchange on a domain controller is a supported solution and as long as you understand the impact, go ahead and deploy that single server. When performance, security and flexibility play a role and the budget or infrastructure allows for, it’s recommended to deploy a new Windows server and install Exchange on that server.

How to remove the Exchange Autodiscover SCP

Consider a scenario where you moved all your user’s mailboxes to Exchange Online, for instance after a cutover or staged migration and want to remove any dependencies on the local Exchange server. You may find that Outlook still connects to the local Exchange server for Autodiscover lookups, this is because Outlook is hard-coded to query an AD Service Connection Point to locate a server with the Autodiscover service. When this fails Outlook falls back to the next DNS based methods or uses a local XML file.

Exchange Management Shell

There are multiple ways to prevent Outlook from contacting the local Exchange server first, some of them make more sense than others. The preferred way is to use the Exchange Management Shell to clear the entry for the Client Access server from the SCP.

Set-ClientAccessServer –Identity ServerName -AutoDiscoverServiceInternalUri $null

This removes the SCP entry for this Exchange server.

ADSIEdit

If the above method can no longer be used a low level AD editor as EDSIEdit can be used to remove the SCP manually. The full path of the SCP is:

CN=ServerName,CN=Autodiscover,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,DC=Suffix

This object to remove has the Class type serviceConnectionPoint.

Alternative methods

One of the above steps is basically all you need to do. Alternatives include adding an ExcludeScpLookup value to the \Autodiscover registry key (KB article) and some articles even let you remove the Autodiscover virtual directory from IIS. This will of course make Outlook unable to query the local Exchange server for Autodiscover but why should you if you can simply remove the SCP.

How to verify?

As always, the proof is in the pudding. Use the Outlook test E-mail AutoConfiguration feature to verify the clients behavior. We’re specifically interested in the Log tab where we should see that Outlook is no longer able to query the SCP to obtain the Autodiscover url.

To start the Test E-mail AutoConfiguration tool, follow these steps:

1. Start Outlook.
2. Hold down the Ctrl key, right-click the Outlook icon in the notification area, and then click Test E-mail AutoConfiguration.
3. Verify that the correct email address is in the E-mail Address box.
4. In the Test E-mail AutoConfiguration window, click to clear the Use Guessmart check box and the Secure Guessmart Authentication check box.
5. Click to select the Use AutoDiscover check box, and then click Test.

Earlier I wrote a short article about this tool, unfortunately available in Dutch only: Autodiscover testen met Outlook. But you’ll get the general idea. Focus on the first or third tab when you’re interested in the Autodiscover results, read the Log tab when you're interested in the Autodiscover process.

MySQL Workbench and ClearDB: "SSL Connection error: unable to get private key file"

When trying to access your ClearDB hosted databases with MySQL Workbench you may run into this error message:

SSL Connection error: Unable to get private key

In the MySQL Workbench connection settings on the SSL tab we need to select three certificate files, the CA certificate, the client certificate and the client key file.

These files can be obtained from the ClearDB database dashboard:

The issue is being caused by the client private key file, the one with 'key' in the name. In order to allow Workbench to connect to the database the password needs to be stripped from this file first. One way to do this is to use OpenSSL:

openssl rsa -in c092bb5f82771e-key.pem -out c092bb5f82771e-key.pem-nopassw.pem

Now use the new file in the Workbench connection settings and try again, Workbench should now be able to connect to your database.

Source

How to view the last monitor response in NetScaler 10.5

When a monitor fails it can be very helpful to check the last result it received. The NetScaler 10.5 web interface does present this information, but you have to know where to look:

Open de properties of the Service Group, expand the Service Group Members, select a Service and click Monitor Details.

The result can be found under the Last Response column:

How to create a Citrix NetScaler LB vserver without an IP address

When configuring a Citrix NetScaler to load balance Exchange 2013 or 2016 you may want to create a load balancing virtual server without an IP and port combo. The reason is that you're going to bind the load balancing virtual server will to a content switching virtual server, clients won't access the lb vserver directly.

Many blog posts as well as Citrix documents as for instance their most recent Exchange whitepaper Microsoft Exchange 2013 with NetScaler: Authentication and Optimization tell you to select Not Directly Addressable. Unfortunately the Directly Addressable check box is no longer available in NetScaler 10.5 and newer.

Well, the feature is still available but has been renamed and moved to another location. If you're using the web interface, choose Non Addressable from the IP Address Type drop-down list no create a virtual server which is not directly accessible.

Maybe it's just me, but I could not found the cmdline alternative in the lb vserver section of the NetScaler Command Reference. So I create one with the web interface and looked it up in the config. Apparently all we need to do is enter the IP address and port number as 0.0.0.0 0.

add lb vserver my_lb_vserver ssl 0.0.0.0 0

In summary, the checkbox for Directly Addressable is replaced with the Non Addressable option in the IP Address Type drop-down list. If you're using the cmdline, set the IP address and port number as 0.0.0.0 0.

What does the new 'Phishing scam' button in Outlook on the web do?

The website formerly known as OWA

In case you misses it, Microsoft recently rebranded Outlook Web App (OWA) to Outlook on the web. I'm sure the marketing people had very good reasons to do so, but the OWA acronym has become a household name since it was introduced in Exchange 5.0. So technically speaking we should use the term Outlook on the web when discussing OWA on Exchange 2016 or in Exchange Online however I will use OWA a lot for probably a very long time. Enough about branding, let's discuss the actual topic.

The new Outlook on the web

Over the past couple of months Microsoft rolled out an updated version of OWA/Outlook on the web to all Office 365 tenants. The new features include Pin, Sweep and the Undo button:

One feature that was added recently, in fact it's even absent from the above screenshot Microsoft used in their announcement, is the new Phishing scam action. This can be found in the actions drop-down list next to Reply all in the reading pane and under Junk in the top actions bar:

The question of course is what exactly happens when you apply this action to your message. At the time of writing there was no public documentation for Exchange or Exchange Online that describes the behavior of this action. However, the button was implemented in the consumer service Outlook.com earlier and is mentioned in the article Email and web scams: How to help protect yourself.

So the Phishing scam action deletes the item and marks the sender as unsafe, just as the Junk action, but it reports the message to Microsoft too. They then use the reported phishing scam emails to improve their filtering techniques to prevent them from arriving in your user's Inbox.

Should I use it?

Definitely encourage your users to use the Phishing scam action on phishing emails, this helps Microsoft fight these scams and make your user's Inbox a safer place. Technology can certainly help here, but in the end user education is the most important and effective way to reduce the risks of being scammed.

Just Office 365?

Interestingly enough the new feature is not in the on-premises Exchange 2016 which was just released this week. From an architectural perspective I see no reason why Microsoft shouldn’t implement the feature in the on-premises product too. After all this feature is nothing more than a slightly adapted version of the Junk feature that is already on-premises Exchange.

My expectation is that we see the Phishing scam action appear in one of the next Cumulative Updates for Exchange 2016. The same applies to Outlook 2006, I expect the same feature to be added in an upcoming update too.