Rebalance DAG automatically using Task Scheduler

Those of you who manage Exchange Database Availability Groups, particularly in Exchange 2013, will understand the frustration of coming to the office on a Monday morning to find that your Databases have migrated to A. N. Other server because of some scheduled backup or other task which occurred over the weekend.

To solve this problem, we can configure a Scheduled Task to run the RedistributeActiveDatabases.ps1 script, which will balance your databases out based on the Activation Preference set for each server. Before you configure this task, make sure that your Activation Preference settings are applied as per your desired configuration.

For example, say I have a database named MBDB and two servers named Server1 and Server2 (I’m feeling particularly inventive today). To set the Activation Preference for these database copies, I would run the following Powershell command from EMS:

Set-MailboxDatabaseCopy -identity MBDB\Server1' -ActivationPreference 1
Set-MailboxDatabaseCopy -identity MBDB\Server2' -ActivationPreference 2

This configuration will mean that when I run the RedistributeActiveDatabases.ps1 script, the MBDB database will be moved, if required, to Server1, as long as the required Database Mount Dial setting is achieved (the default setting is Best Availability which requires the Copy Queue Length to be no more than 12).

If I wanted to see how my database copies are currently configured, I would run the following Powershell command from EMS:

Get-MailboxDatabase MBDB | fl server, databaseCopies, activationPreference

This would show me all the database copies and their Activation Preference. So we now have our settings configured and we want to setup our Scheduled Task. Open your Task Scheduler and create a new Basic Task. Give the task a name and configure your recurrence schedule for the Task. When you get to the Action menu, choose ‘Start a Program’.

Now we need to tell the task to:

1. Launch Powershell
2. Load the Exchange modules and connect to the Exchange server
3. Run the RedistributeActiveDatabases.ps1 script with the correct switches
4. Supress the confirmation dialog which appears when running the script

To do this, we enter the details as follows:

  • Program/script:
    • C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe
  • Add arguments:
    • -NonInteractive -WindowStyle Hidden -command “. ‘C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto; .’C:\Program Files\Microsoft\Exchange Server\V15\scripts\RedistributeActiveDatabases.ps1’ -DagName DD-DAG -BalanceDbsByActivationPreference -Confirm:$false”
    • Note: Please change the DagName parameter to reference your own DAG!

It looks a little bit like this (OK, it looks just like this):

TaskScheduler DAG Rebalance

Complete the task creation and then go into the properties of the task. On the General page, configure the task to:

1. Run whether the user is logged on or not
2. Run with highest privileges
3. If need be, change the account running the task to a service account of some kind. That account must be a member of the Organisation Management group

Just like this:

TaskScheduler DAG Rebalance 2

Your Scheduled Task is not configured. You can test it out by manually running it. Hopefully this solves a headache for one or two of you out there!

Blocking Outlook App for iOS & Android

I just wanted to share this great article from EighTwOne on how to block the new Oulook app for iOS & Android. I don’t usually share other people’s posts but I thought this was particularly useful as there is quite a storm brewing in the proverbial teacup over this app. If you have concerns about the privacy and security of this app, use the commands listed in the linked article to create a device block or quarantine policy for the app.

EighTwOne (821)

imageYesterday, Microsoft announced the immediate availability the Outlook for iOS and Outlook for Android preview. These apps are the former app named Acompli, which was acquired by Microsoft in December, last year. It is unlikely that Microsoft will develop and support two similar apps, so one can assume the new Outlook app will replace the current OWA for iOS and OWA for Android (or just OWA for Devices) apps.

The app isn’t without a little controversy:

  • The app stores credentials in a cloud environment from Amazon Web Services for e-mail accounts that don’t support OAuth authorization.
  • The app makes use of a service sitting between the app and your mailbox. This service acts as a sort of proxy (hence it requires those credentials), fetching, (pre)processing and sending e-mail. In some way this is smart, as it makes the app less dependent on back-end peculiarities, using a uniform protocol to communicate…

View original post 375 more words

Remote Mailboxes in Exchange Hybrid configuration

I’ve been asked a few questions recently about Remote Mailboxes in Office 365 hybrid configurations. The Remote Mailbox exists on the On Premise Exchange server and is the link between the Office 365 mailbox and the On Prem Exchange Organisation. Without one of these for each Office 365 mailbox, you can’t effectively manage certain Office 365 mailbox properties, you can’t offboard it back to the On Prem Exchange Server, and most importantly, not having a Remote Mailbox breaks mail flow between users On Prem and users in Office 365.

Quite often, when administrators first start using Office 365 in Hybrid mode, they will create a new user simply by creating the AD account, synchronising it using DirSync/AADSync, and then licensing the user. This will give you a mailbox in Office 365, but will also cause the problems listed above. The correct way to provision new users in Office 365 is to create new Remote Mailboxes. If a Remote Mailbox isn’t present or has been accidentally deleted, you can create one and link it up to the Office 365 mailbox.

To do this:

From Exchange Management Shell (On Premise):

Enable-RemoteMailbox username –RemoteRoutingAddress

The RemoteRoutingAddress is always in the format of, for example:

Enable-RemoteMailbox joeb –RemoteRoutingAddress

You then need to get the Mailbox GUID of the Office 365 mailbox. To do this, go into Office 365 PowerShell and run:

Get-Mailbox –Identity emailaddress | fl Identity,ExchangeGUID

Copy the Mailbox GUID into your clipboard and go back to the Exchange Management Shell (On Premise):

Set-RemoteMailbox username –ExchangeGUID 8e992097-24c1-432c-8a89-98e3c7a7d283

Anything in italics needs to be changed to a parameter relevant to your requirements. Once you’ve completed this, perform a delta/incremental sync and the two shall become one (so to speak!)

There is a KB article from Microsoft on a similar issue (trying to Offboard a mailbox where the Remote Mailbox GUID is not the same as the 365 GUID) here:

Thanks for reading 🙂

Office 365 – Outlook Profiles in a Cutover Migration

One of the drawbacks of performing a cutover migration from an On Premise Exchange environment to Office 365 is that Outlook profiles must be recreated to connect to the Office 365 servers. If done manually on every single workstation in your company, this could be a very time consuming process as you would have to create a new profile, set it as the default and configure it for the user.

One way of automating some of this process is to use Group Policy to run a script to create a new, blank Outlook profile and set it as the default profile. The user will then be presented with the first time profile setup screen when opening Outlook and should be able to use Autodiscover to automagically find their new Office 365 profile settings:

Outlook New Profile SetupOutlook Configure Profile

Outlook Profile Complete

To create the batch file required to do this, copy and paste the following text into a file and save it as a .bat file:

For Office 2010:

reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\O365"
reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles" /v DefaultProfile /t REG_SZ /d "O365" /F
reg add "HKCU\Software\Microsoft\Exchange\Client\Options" /v PickLogonProfile /t REG_DWORD /d "0" /f

For Office 2013:

reg add HKCU\Software\Microsoft\Office\15.0\Outlook\Profiles\O365
reg add "HKCU\Software\Microsoft\Office\15.0\Outlook" /v DefaultProfile /t REG_SZ /d "O365" /F

The script will create a new profile called O365 and set it as the default profile. Create a new Group Policy object to run the .bat file in Group Policy Preferences. You can safely leave the GPO in place for a few days to allow for people who may not be in the office for your go live day as it will not overwrite or remove existing profiles.

When this process in used in conjunction with the Group Policy for controlling Autodiscover ( you can have a 80% automated cutover migration which should be smooth sailing for yourself and your users!

Thanks to my colleague Kevin for sharing his experiences and allowing me to blog about this.

Exchange Online – Lock down mail flow

By default, Office 365/Exchange Online allows mail to be received from any external source. This is done using a ‘hidden’ default inbound connector. The properties of this connector cannot be viewed or modified, even in Exchange Online Powershell.

This is all well and good and allows you to be able to send/receive mail out of the box in Office 365, however is does cause a problem if you are using a 3rd party mail solution such as Mimecast or Websense. If you do happen to be using a 3rd party mail filter and you leave the default inbound connector alone, somebody could bypass your filter by sending you mail directly to your Office 365 hostname. From a best practices and security point of view, this is most definitely a bad thing.

To combat this and limit Office 365 from receiving mail only from your mail filter, go into your Exchange Admin centre and create a new Inbound Connector under Mail Flow>Connectors.

New Inbound Connector

The settings of your Inbound Connector should be as follows:

Type: Partner
Connection Security: Force TLS (only if your mail filter supports forced TLS. This will add an extra layer of security. Otherwise, use Opportunistic TLS)
Sender Domains: *
Sender IP Addresses: (enter your mail filters IP addresses here)

This example states that Office 365 will only receive mail from the IP address and nothing else. The * wildcard under Sender Domains applies the connector to all mail. If I were to use Exchange Online Powershell to perform the same task, my command would look like this:

New-InboundConnector -Name Lockdown -ConnectorType Partner -RequireTls $true -SenderIPAddresses -SenderDomains *

This simple configuration change will ensure that nobody can bypass your mail filter and spam you with invitations to enlarge something or other 🙂

Resource Mailboxes show availability as Busy

When you create a Resource Mailbox in Exchange 2010, 2013 or Office 365, the default permissions applied to the calendar for the Default user group is ‘AvailabilityOnly’. This means that you can see appointments in the calendar, however you cannot see the subject, attendees, or any further details. When this is being used for a piece of equipment or a meeting room, this configuration appears to be counterproductive.

After all, if you desperately need that piece of equipment (the corporate skipping rope for instance), how do you know who has booked it so you can go and argue with them about who should be able to use it that lunchtime? If you are on the board of a company, how do you know which of your minions have mistakenly booked the meeting room during your monthly board meetings so you can go and give them a verbal warning?

Almost all of my customers ask me these important questions, and the answer is simple. You run the following Powershell command against the Resource Mailbox and set the Default access rights to the more informative ‘Reviewer’ permission. Users can now see the subject, the attendees and the details of the booking.

Set-MailboxFolderPermission alias:\calendar -User Default -AccessRights Reviewer

Powershell. Helping you achieve the unachievable.

Exchange 2013 CU7 and more!

Today Microsoft have released a new slew of updates for On Premise Exchange environments!

There have been various hotfixes and scripts released to fix a multitude of sins in Exchange 2013 CU6, and Microsoft have rolled these hotfixes and more into their latest CU7 release. This update does require a Schema Update, so please run setup /prepareschema first. See for more information. Additionally there are some UM Language Packs for Exchange 2013 CU7 available.

In other news, the Exchange 2010 CU8 update has been recalled at the time of writing and is not available for download. This is because deployment of said update can lead to Outlook being unable to connect to Exchange :-/ If you have already installed, it is recommended that you rollback the update.

Lastly is the Exchange 2007 SP3 UR15 for all those retro Exchange nerds still running Exchange 2007. See KB here for information

Check out for the full rundown!

Powershell – Automatically Update E-mail Address based on Recipient Policy

During a recent large Office 365 Hybrid Deployment, I came across the issue of many users (400+) having the ‘Automatically Update E-mail Address based on Recipient Policy’ option unticked. This meant that the users in question did not have the correct routing address of specified. When attempting to migrate the mailboxes of said user accounts, they failed with the following error:

The target mailbox doesn't have an SMTP proxy matching ''

This address is required for mail routing between On Premise users and Office 365 users, therefore without if the mailbox move cannot take place. This address is added to all Email Address Policies which contain the hybrid domains during the Hybrid Configuration, in order to put the correct routing in place.

The company in question only had one email address per user in the format of so there was no reason not to have this option enabled. The only exception were a few users who had a different SMTP suffix (, so these users needed to be left alone. The first thing I had to do was identify which users had the email address policy disabled. To do this I ran the following command:

get-mailbox | Where {$_.EmailAddressPolicyEnabled -eq $false} > C:\Temp\emailpolicy.txt

After realising there were 400+ mailboxes to enable this on, it became obvious that this was a problem which only Powershell could solve. Before I started, I first used the command listed on a previous blog to export a list of all Primary SMTP addresses as a reference. I then ran the following command to find all users with a particular SMTP suffix and enable the ‘Automatically Update E-mail Address based on Recipient Policy’ option:

Get-mailbox | Where {$_.EmailAddresses -like ‘*’} | Set-mailbox -EmailAddressPolicyEnabled $true

If you just wanted to apply the policy to all users, you would use the following command:

Get-mailbox | Set-mailbox -EmailAddressPolicyEnabled $true

How to export a list of all Primary SMTP addresses and aliases

I was about to upgrade an Email Address Policy from Exchange 2003 version to support the modern version of Email Address Policies. Due to problems I have had in the past with these policies, I wanted to export a list of all Primary SMTP addresses and any other email aliases present for each user, and I wanted it in an easy to read CSV format. This is the command I ended up using, which is a slightly modified version of the command provided by the Enterprise IT blog

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\exportsmtp.csv -NoTypeInformation

This can prove useful to do at the start of an Exchange deployment, ensuring you have a copy of the email addresses in use at the start of the project. It can also be useful for auditing purposes. This script will work in Exchange 2007, 2010 or 2013.

TechEd Europe 2014

TechEd Europe 2014

Today I am packing my bags and preparing myself for a week away in sunny Barcelona for TechEd Europe 2014. This will be the first TechEd event I have ever been to, and to say I am excited is a bit of an understatement!

I’ve got my schedule all planned out using the Content Builder, and have at least 2 sessions scheduled for every single time slot. What with the breakout sessions, hands on labs and focus groups it’s going to be a very busy week!

My focus for the breakout sessions will be around Office 365/Exchange, Hybrid Identity and the Enterprise Mobility Suite. I’ve also got a couple of Windows 10 sessions in there for light relief, but we will see how things pan out.

I am hoping to be writing a daily blog to sum up each days events and I hope you’ll join me on my TechEd journey.