Automating Mailbox Regional Settings in Exchange Online

When you migrate (or create) a mailbox in Exchange Online, the first time a user goes to open their mailbox they are prompted to select their Timezone and Language. I recently had a client ask for a more automated method of pre-populating these values, so thought I’d have a look into it.

Of course, there’s no global way to define these settings for users before they get a mailbox, so the settings have to be set once the mailbox has been migrated – this really only leaves the option of a custom powershell script – either something you run after each migration (or creation), or on a periodic schedule.

First, to the settings themselves. As it turns out, you can use the same commands that you’d use in on premise Exchange: Get-MailboxRegionalConfiguration and Set-MailboxRegionalConfiguration – which also means this script could be adapted to be used on premise as well. The two settings we’re concerned with here are “Language” and “TimeZone”. Since the client we’re dealing with here is solely based in Australia, we’re going to be setting all users to a language of “en-AU”. For the TimeZone, Microsoft provide a list of valid values here: https://support.microsoft.com/en-us/kb/2779520

Except that they’re missing two Australian time zones. The actual valid values for Australia are:

  • AUS Central Standard Time – Darwin
  • Cen. Australia Standard Time – Adelaide
  • AUS Eastern Standard Time – Canberra, Melbourne, Sydney
  • E. Australia Standard Time – Brisbane
  • Tasmania Standard Time – Hobart

So with that in mind, we can use the following commands:

Since we’re talking about a national business with users in different time zones, the time zone value is going to need to change for each user. In order to automate this, we’ll need some source information available that indicates in which state the user is located – ideally, you’re going to be using the ‘Office’ field in the user’s AD account – though obviously you could use any available attribute. The reason I recommend ‘Office’ (or ‘physicalDeliveryOfficeName’) is because it’s synchronised to Office 365 with the user account (and becomes ‘Office’).

Note: You don’t actually need the value in Office 365 – if you’re running the script on premise, you can query your AD directly and ignore the attributes in 365. When I wrote the script I opted to solely use data that was in Office 365 – primarily because I was developing the script remotely and didn’t have direct access to their AD – so if you want to use your local AD instead of values in 365, you’ll need to modify the script!

For this client, the ‘Office’ value for each user is prefixed with the state (ie: SA, NSW, QLD, WA) – so it was relatively simple to use a ‘Switch’ function in Powershell (similar to a ‘Case’ statement in vbscript).

In order to use the script, you need the following:

You’ll also need to update the 5 variables at the top of the script (paths, etc), as well as the Time Zones (and criteria) in the Switch statement.

 

Using Azure RM Site to Site VPN with a Dynamic IP

In the interests of saving a bit of money, I decided to switch my ADSL service from an expensive business connection to a cheap residential connection. In Australia this also means switching from a static IP address to a dynamic IP address. With most web-based services now able to be proxied via Microsoft’s Web Application Proxy (and other services using unique ports), it seemed like everything would be fine with a combination of a Dynamic DNS service and port forwarding. I only run a development environment at home, so if I could save some money without any real impact, all the better!

After I made the switch, I realised that I’d forgotten about my site-to-site VPN between my development environment and Azure Resource Manager (AzureRM). For those familiar with AzureRM and Site to Site VPN, you’ll know that your on premise IP address is configured in a “Local Network Gateway” object. I thought perhaps that you could enter a DNS entry in the IP address field – no such luck.

So I had a look around online to see if anyone else had some easy solution I could poach. While I could find a solution for Azure Classic, the objects are completely different in AzureRM (and the powershell commands are different) – so while it gave me a direction, I couldn’t use the solution as-is. So I had a look at the available AzureRM powershell cmdlets – primarily Get-AzureRmLocalNetworkGateway  and Set-AzureRmLocalNetworkGateway . The problem I came across was that ‘Set’ command really only accepts two parameters – a LocalNetworkGateway object, and AddressPrefix (for your local address spaces). No option to change the Gateway IP. The documentation didn’t give any additional information either.

Based on previous experience with powershell, I had assumed that the LocalNetworkGateway input object would need to refer to an existing object. As a last resort, I decided to try modify it before setting anyway – and it worked! So essentially we can do something like:

Obviously this is a fair way from an automated solution that can be run on a schedule! In order to put it into a workable solution, the following overall steps need to be taken:

  1. Configure a dynamic DNS service (such as www.noip.com) – this’ll need to be automatically updated via your router or client software
  2. On the server that will be running the scheduled task, install the Azure Powershell Cmdlets (as per https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/)
  3. Create an administrative account in Azure AD that has administrative access on the subscription (they must be listed in the Azure Classic portal under Settings > Administrators). It’s important to note that when using the Login-AzureRM Credentials  command that the credentials used must be an ‘organisational account’ – you can’t use a Microsoft Live account (even if it’s a subscription administrator).
  4. Use some method of saving credentials for use in Powershell. I prefer to use a key-based encryption so it’s transportable between computers – a guide on doing this can be found here: http://www.adminarsenal.com/admin-arsenal-blog/secure-password-with-powershell-encrypting-credentials-part-2/
  5. Update the following values in the following script:
    1. DynDNS: the external DNS entry that resolves to your dynamic IP
    2. SubscriptionName: the name of your Azure subscription. This can be retrieved using Get-AzureRMSubscription
    3. User: the organisational administrative account
    4. PasswordFile: the file containing the encrypted password
    5. KeyFile: the file containing the encryption key (obviously you want to keep this safe – as it can be used to reverse engineer the password!)
    6. Address Prefixes on line 42.
  6. When running the script via Task Schedule, ensure you also specify the ‘Start In’ directory – otherwise you need to hard code paths in the script.