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.

 

 

KMS Guide

Updated on :  11/08/2016 (Windows 10 KMS patch compatibility)
Relevant to:   KMS – all versions


KMS seems to be one of those things that is sometimes quite poorly understood – and many existing blog articles or pieces of documentation seem to gloss over important details (IMO). So, below is my attempt.

Concepts

 MAK – Multiple Activation Key

This type of key is intended to be used on multiple computers, but must be entered manually, via VAMT or in an SCCM task sequence. The activation process occurs once per machine either directly over the internet, via a MAK proxy or via telephone.

The MAK activation method is best suited for

  • Small organisations with 25 or less computers
  • Organisations who have certain machines which are not domain joined and/or do not connect to the business network regularly

KMS – Key Management Server(s)

A Key management server is a service which provides activation on behalf of clients. The KMS server is activated once, and in turn, clients will auto-locate and activate against the KMS service. (more about the details a bit later)

KMS Key – Key Management Server Key

This type of key is intended to be used on a Key Management Server to provide activation for clients and has a couple of important factors:

  • KMS requires what is called an “activation threshold”, which basically means that until you have more than 25 Windows 7/8/8.1 activations or more than 5 Windows Server 2008 R2/2012/2012 R2 activations, the KMS server is not active
  • To remain active, KMS clients must contact the KMS server once every 180 days. If it does not, the client will start showing activation messages.

Volume licensing

I would imagine that if you are reading this blog you are familiar with what volume licensing is. KMS and MAK are both used for volume licensing customers, you cannot activate retail or OEM operating system installs using these methods.


Decisions to be made prior to install

KMS or MAK

Many organisations we deal with use both.

If a machine is off the network for long periods of time or is not domain joined, use a MAK. (Please note that non-domain joined machines can still use a KMS, but usually there is a reason they are not domain joined, which may also mean they cannot access the KMS!)

For all the domain-joined, generally on the network machines, use KMS.

Choosing a KMS key

In my opinion, the Microsoft doco @ http://technet.microsoft.com/en-us/library/ff793412.aspx and http://technet.microsoft.com/en-us/library/ee939271.aspx makes it sound complex.

In short, go with the “highest” version of server you have available and it can then activate everything “below” it.

For example:

If you utilise the Server 2012 R2 standard key (KMS B), it can act as an activation server for 2008R2/2012/2012R2 standard and Win7/8/8.1, but it cannot activate datacentre editions.

If you utilise the Server 2012 R2 datacentre key (KMS C), it can activate other datacentre editions as well as all 2008R2/2012/2012R2 standard/datacentre and Win7/8/8.1.

“But I only want to license Windows 7 machines!” the response frequently comes back.

A KMS key will also license all products that are “lower” in the tree, so using a server 2012 R2 standard KMS key will allow you to license all windows 7 machines (as well as windows 8/8.1 and server 2008R2/2012/2012 R2)

“So why do I have a Windows 7 KMS key then?” is the next question

This is because it is an option to install a KMS on Windows 7, simple as that. This is something we would generally advise against, as most organisations that use a KMS would use it for their servers and workstations.

Choosing a KMS server – OS Version

Using the newest operating system in your environment generally means that you will not need to download additional updates or patches, so simply for that reason, we would recommend using the newest OS version you have available.

Choosing a KMS server – Server load & placement

The KMS role is a very low-load role and we have never had any issues co-locating it with other roles. One common pairing is placing the KMS role on the SCCM primary site server (for organisations of up to 5000 PC’s)

For larger organisations, we see various approaches. Some have dedicated KMS servers, some co-locate on other services.

This section is here because often people ask what the load is like and can be co-located with other roles. The short answer is, very low load service and it be co-located with anything that doesn’t need TCP 1688.

KMS publishing and load balancing

KMS, by default listens on port TCP 1688 and will (by default) publish a DNS SRV record to allow domain-joined clients to locate the KMS service. The record created is called _vlmcs

Windows 7/2008 R2 and above volume license operating systems automatically look for this DNS record.

SRV records have a weight and priority associated with them, and this, by its nature, allows multiple KMS’ to be published and administrators to use them in a round-robin scenario (same priority) or in a fault-tolerance scenario (different priorities)

It is possible to disable publishing for a KMS service, but this is not something we have ever done – and we are not quite sure of a scenario where this would be helpful (but this doesn’t meant there isn’t one!)

KMS1

Patching KMS to support Windows 10

In order to support Windows 10, you will need to patch your 2008R2, 2012 or 2012R2 KMS server as per

https://support.microsoft.com/en-au/kb/3086418


Office KMS

Office 2010 and 2013 have KMS add-on packs, that can be installed on an existing KMS server, these are available at:

Office 2010 KMS Host – http://www.microsoft.com/en-au/download/details.aspx?id=25095

Office 2013 KMS Host – http://www.microsoft.com/en-us/download/details.aspx?id=35584

Office 2016 KMS Host – https://www.microsoft.com/en-us/download/details.aspx?id=49164


Installing KMS + Office KMS step by step

These steps remain the same whether you are installing on Windows 2008 R2, 2012 or 2012 R2.

  • Decide which server will host your KMS. We recommend utilising the latest server version you have access to and the highest “edition” (at the time of writing, this is Server 2012 R2 Datacentre)
  • Logon to the server and open an elevated command prompt (this process will fail if you do not elevate the command prompt!)
    • C:
    • Cd windows\system32
    • Cscript slmgr.vbs /ipk <your product key, with the dashes>
    • Cscript slmgr.vbs /ato
  • You now have a KMS server
  • To verify the install and look at the number of currently activated machines
    • Cscript slmgr.vbs /dlv

KMS2

  • To install the Office KMS host (we will use 2013 in this example, however it is very similar to the 2010 process)
    • Download the KMS host update from the links above
    • Run the install
    • Enter your product key when prompted
  • To verify the install and look at the number of currently activated machines
    • Cscript slmgr.vbs /dlv all
    • Look for the appropriate office 15 (or 14) section

KMS3


Common questions

Question:            I want to move my KMS server, how do I move the activation database etc.?

Answer:               There is no activation database or anything that needs to be moved. Simply create a new KMS, install the KMS key and activate. Then decommission the “old” KMS by running slmgr.vbs –upk (uninstall product key) and then either delete the “old” _vlmcs record from DNS, or use slmgr.vbs -cdns

Question:            If my KMS client is off the network for more than 180 days, what do I do ?

Answer:               Simply re-attach it to the network, it will find the KMS server and renew its activation. If the client will regularly be off the network for more than 180 days, it would be wise to consider using a MAK for this client.

Question:             The SRV record has not registered in DNS.

Answer:                Sometimes a restart of the KMS service is required. Net Stop sppsvc then net start sppsvc

Sometimes, if an existing record already exists from a previous KMS, you may need to grant permissions over the DNS record, but frankly, its easier just to delete it and restart the KMS service (command above)

 


Common mistakes

Mistake: Using a KMS key on a number of client machines, either because the difference between MAK and KMS wasn’t clear, or my licensing person gave me the wrong key.

This can be quite easily fixed by changing the key on the affected clients :

Mistake: Deploying MAK keys in a task sequence, when you actually want to use a KMS.

If you want to use KMS, simply leave the product key section in your task sequence blank.

To “fix” existing clients, you will need to identify the machines with a MAK and install the default KMS key. The VAMT can be used to help identify and update these machines.

Mistake: Using the windows 10 KMS key on a server results in Error 0xC004F015

You need to use the server KMS keys on a server OS (as discussed above), please read the above article or visit https://support.microsoft.com/en-us/kb/3086418


Official doco references

Understanding MAK activation – http://technet.microsoft.com/en-us/library/ff793435.aspx

Understanding KMS activation – http://technet.microsoft.com/en-us/library/ff793434.aspx

Default KMS keys – http://technet.microsoft.com/en-us/library/jj612867.aspx

Deploying KMS – http://technet.microsoft.com/en-us/library/ff793409.aspx