Wednesday, June 29, 2016

IMAP4 Frontend with Exchange 2013

A customer of Avantgarde Technologies was having issues with IMAP4 on Exchange 2013.  In Exchange 2013 the IMAP Role has changed and how has a "front end" and "backend role".  This is shown by two services below.

The IMAP4 backend role listens on

If we telnet "localhost" we hit the IMAP backend service.

If we telnet the server on any other IP address on TCP143 we hit the IMAP front end service.

This is what is confusing.  By default the IMAP4 frontend proxy server component is disabled even if the service is started.

If you telnet the server on its local IP address as shown below.

You will simply get a blank Telnet screen which will automatically close the session seconds after.

This happens as the ImapProxy frontend is disabled by default on the Server Component State of the server.

To enable it, use the following command.

Set-ServerComponentState -Identity Servername -State Active -Requester HealthAPI -Component ImapProxy

Need IT Support with Microsoft Exchange in Perth?  Click Here.

Tuesday, June 21, 2016

Modern Public Folders in Multi-Tenant Environments

Modern Public Folders is a new feature introduced in Exchange 2013 and also available in Exchange 2016 to allow companies to leverage Database Availability Groups and utilise log shipping as opposed to SMTP for replication providing numerous advantages which we will not focus on in this article.

If you new to Modern Public Folders, here is a good article to get you started:

In this article, we will focus on Modern Public Folders in a multi-tenant environment.  We will be going through how to achieve multi-tenancy with Microsoft Exchange 2013 / 2016.

It is important to note, there are numerous methods for setting up Public Folder in a multi tenant environment.

In the example below we have:
  • One root Public Folder per tenant/company
  • One Public Folder Mailbox per tenant/company
  • One security group to represent all users from each tenant/company
  • Access based enumeration to each tenant/company can only see their root level Public Folder.
With Exchange 2013 and Exchange 2016, the first Public Folder mailbox created is always deployed as the Master Hierarchy Mailbox.  This mailbox is the only Public Folder mailbox with a writeable copy of the Public Folder hierarchy.  All additional Public Folder mailboxes created contain a read-only copy of the hierarchy.

When we are talking about Hierarchy, we are not talking about Public Folder content, only the folder structure which makes up the Public Folders.

First thing we need to create is a master Public Folder Hierarchy mailbox.  In a multi-tenant environment I generally recommend no content be placed in the master Public Folder Hierarchy mailbox and it only be used to maintain the writeable copy of the Public Folder Hierarchy.

As the first Public Folder mailbox created is always the Master Hierarchy, simply use the New-Mailbox command to create the mailbox.  I always recommend clearly naming this mailbox so it is easily identifiable as the Public Folder Mailbox Hierarchy mailbox.  This was done by giving it the name of "MasterHierarchy".

Next create a Public Folder mailbox for each tenant/company.  The intent here is all content for each company will be stored in their respective public folder mailbox.  In this example we will be using my company Avantgarde Technologies as an example tenant.  I'm using the naming convention CompanyPF for each respective Public Folder mailbox.

Next create a new Public Folder at the root "\" of the Hierarchy.  Make sure you specify the Public Folder mailbox you want to store the Public Folder in or by default Exchange will automatically pick any Public Folder mailbox which could be the Master Hierarchy mailbox or another tenants mailbox.

The name of the Public Folder specified below is the name the tenant will see in Outlook.

By default, all root public folders can be seen by all tenants.  To ensure no tenants can see the "Avantgarde Technologies" root level Public Folder, remove the Default user Access Rights as shown in the screenshot below.  This will ensure no one can see this Public Folder.

Lastly, ensure you have a Security Group containing all users from the tenant/company. Grant the group access to the root level Public Folder - I recommend Owner or PublishingEditor rights or refer to the following TechNet article about other Public Folder permissions you can grant here.

Only users of the "Avantgarde Users" security group will be able to see the root Public Folder Avantgarde Technologies and all other Tenants in the environment will be hidden to the Avantgarde Technologies employees.

To add additional tenants to the environment, repeat the process documented above.  Make sure you ensure that:
  • All root level public folders have the default user permissions removed straight away to protect privacy of each tenant on your Exchange environment.
  • When creating the root level public folders in PowerShell you manually specify the correct Public Folder mailbox or Exchange will pick one at random.
  • Consider using provisioning scripts to remove user error and protect yourself against privacy breaches.
All sub-folders created in Outlook will automatically append to the parents Public Folder mailbox.

One last thing I want to touch on is the "-DefaultPublicFolderMailbox" of the Set-Mailbox command.  Many people when they initially go about setting up Public Folders for multi-tenant Exchange they think about creating a public folder mailbox for each tenant then using "-DefaultPublicFolderMailbox" for all user mailboxes of each tenant.  Before writing this article I googled around to see if there was already an article similar, and saw people were attempting this incorrect method of deployment.  The reason this approach will not work is as mentioned earlier, all Public Folder Mailboxes have a "read only" copy of the entire Public Folder Hierarchy (meaning all Public Folders in the Exchange Organisation).  This means "yes they do have the Public Folder structure of other tenants/companies in the environment".  We want to ensure tenants only see public folders related to their company by locking down permissions to meet privacy reasons.

I hope this article has been informative for you and I would like to thankyou for reading.

Click here for IT Support in Perth with Microsoft Exchange

Friday, June 17, 2016

Setting Delivery Restrictions and Exchange Administration Center

Delivery Restrictions is a feature of Exchange Server which has been around since Exchange 2000 and allows companies to easily limit who can send to a distribution list or mailbox.  A very common use of Delivery Restrictions is to limit who can send to the "All Users" or "All Staff" distribution group.

In previous releases of Exchange such as 2010, 2007 and even 2003 - delivery restrictions were very easy to configure via the Graphic User Interface (GUI).

In later revisions of Exchange, Delivery Restrictions have been left out of the GUI and now must be configured by PowerShell.

This can be easily configured by using the "AcceptMessageOnlyFrom" attribute on DistributionGroups and Mailboxes for which you want to configure Delivery Restrictions.  The "AcceptMessagesOnlyFromDLMembers" is when you want to limit the group/mailbox to a Group of users who are allowed to send.

To set this, simple:

Set-DistributionGroup "Avantgarde Users" -AcceptMessageOnlyFrom "Clint Boessen"

However what if you want to configure multiple users or groups who need delivery restrictions on a mailbox or distribution group?  The -AcceptMessageOnlyFrom attribute does not allow you to comma separate values.

This is where it becomes more complicated...

Here is the syntax to add multiple groups or users to Delivery Restrictions in PowerShell:

Set-DistributionGroup -Identity "All Staff" -AcceptMessagesOnlyFromDLMembers "All Managers"

Set-DistributionGroup "All Staff" -AcceptMessagesOnlyFromDLMembers((Get-DistributionGroup "All Staff").AcceptMessagesOnlyFromDLMembers + "Executive Assistant")

Set-DistributionGroup "All Staff" -AcceptMessagesOnlyFromDLMembers((Get-DistributionGroup "All Staff").AcceptMessagesOnlyFromDLMembers + "Executive Group")

I hope this post has been helpful!

Need IT Services in Perth from Subject Matter Experts?

Exchange 2016 CU2 - Automatically Move Exchange Databases back to Preferred Server

In Exchange 2016 CU2, Microsoft has released a new feature which has been a request of mine since the release of Exchange Database Availability Groups (DAGs) in Exchange 2010.  I have built many Exchange 2010/2013 and 2016 clustered environments for customers around Perth over the years however one problem I always see is customers do not rebalance databases after Windows Updates.

Many customers (even after trained) do not put DAG nodes into maintenance mode and simply install updates on a node and reboot causing a database failover to occur.  They then do the remaining servers in the cluster usually ending up with all databases residing on a single server.

In Exchange 2016 CU2 there is a new shiny feature which "automatically fails back" the database to the preferred server based on Activation Preference.  This is known as "PreferenceMoveFrequency".

After all your Exchange 2016 servers (or more technically the Primary Active Manager) have been upgraded to Exchange 2016 CU2, you will have a new DAG property called PreferenceMoveFrequency.

What this switch does is define a frequency (measured in time) when the Microsoft Exchange Replication service will rebalance the database copies by performing a lossless switchover that activates the copy with an ActivationPreference of 1.

How cool is that... automatic failback to preferred members.

Now when I build a new Exchange cluster for a customer, after I leave and close out the project I can be sure that the databases will automatically fail back to the preferred server after the customer installs Windows Updates on cluster nodes.  This is important as it keeps the load across the cluster balanced.

To set this feature, simply use the following PowerShell command:

Set-DatabaseAvailabilityGroup -Identity DAG01 -PreferenceMoveFrequency ([TimeSpan]::Zero)

Need specialised Exchange consulting in Perth?  Contact Avantgarde IT Services on 08 9468 7575

Sunday, June 12, 2016

Reduce your IT Support costs by purchasing quality hardware upfront

During my career in the IT Industry, I see many small business entities purchase cheap consumer grade hardware from a local computer store in order to reduce IT costs.  This is bad practice and almost always leads to significantly higher IT Support costs in the long term.

For more information, please see my article "The Importance of Quality Hardware to reduce IT Support Costs"

Reduce your IT Support Costs in Perth by talking to us now.

Tuesday, June 7, 2016

.NET Framework 4.6.1 and Exchange 2013 / 2016

Currently with Exchange 2013 CU12 and Exchange 2016 CU1, it is not supported to install .NET Framework 4.6.1 as it causes issues databases unexpectedly dismount or failover to alternative servers within a DAG cluster.  This issue is documented on the following KB article:

To ensure .NET Framework 4.6.1 does not install on your Exchange Servers, make sure you put the following registry key in place on your Exchange Servers:
  1. Back up the registry.
  2. Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press Enter.
  3. Locate and click the following subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP
  4. After you select this subkey, point to New on the Edit menu, and then click Key.
  5. Type WU, and then press Enter.
  6. Right-click WU, point to New, and then click DWORD Value.
  7. Type BlockNetFramework461, and then press Enter.
  8. Right-click BlockNetFramework461, and then click Modify.
  9. In the Value data box, type 1, and then click OK.
  10. On the File menu, click Exit to exit Registry Editor.
What if I have already installed .NET Framework 4.6.1 on my Exchange Servers?  If so use the following procedure:
  1. If the server has already automatically updated to 4.6.1 and has not rebooted yet, do so now to allow the installation to complete
  2. Stop all running services related to Exchange.  You can run the following cmdlet from Exchange Management Shell to accomplish this:  (Test-ServiceHealth).ServicesRunning | %{Stop-Service $_ -Force}
  3. Go to add/remove programs, select view installed updates, and find the entry for KB3102467.  Uninstall the update.  Reboot when prompted.
  4. Check the version of the .NET Framework and verify that it is showing 4.5.2.  If it shows a version prior to 4.5.2 go to windows update, check for updates, and install .NET 4.5.2 via the KB2934520 update.  Do NOT select 4.6.1/KB3102467.  Reboot when prompted.  If it shows 4.5.2 proceed to step 5.
  5. Stop services using the command from step 2.  Run a repair of .NET 4.5.2 by downloading the offline installer, running setup, and choosing the repair option.  Reboot when setup is complete.
  6. Apply the February security updates for .NET 4.5.2 by going to Windows update, checking for updates, and installing KB3122654 and KB3127226.  Do NOT select KB3102467.  Reboot after installation.
  7. After reboot verify that the .NET Framework version is 4.5.2 and that security updates KB3122654 and KB3127226 are installed.
  8. Follow the steps here to block future automatic installations of .NET 4.6.1.
Need IT Support Perth?  Contact Avantgarde Technologies on 08 9468 7575