TechEd – Day 2

We are now into Day 3 of TechEd and my tiny mind is struggling to keep up with the wealth and breadth of information which is out there. So far I have attended breakout sessions and labbed the following subjects:

– Work Folders
– SMTP Transport in Office 365
– Exchange Online Roadmap
– Azure Security
– Office 365 Adoption Strategy
– Enterprise Mobility Overview & Deep Dive
– Office 365 Security & Compliance
– Advanced Features of ADFS 3.0

I have so much more planned and am attempting to be as sponge like as possible. My OneNote is overflowing with information and I’m very excited about the future of Microsofts mobile first, cloud first vision.

Notes from Barcelona – Empowering and protecting your mobile users

After a day and a half of TechEd, my mind is filled with two words…Enterprise Mobility. And the more I hear, the more sense it makes. Gone are the days where a user had a single corporate device, plugged into the wall with a LAN cable. These days, a user typically has anywhere between 2-5 devices, most of them mobile, and that user fully expects to be able to access some kind of corporate data on those devices. The line between a device for work and another for play is blurred to the point of being invisible, and IT needs to adapt to be able to empower and protect users. EMS isn’t just a product suite, but a concept, which will increase productivity and security for your users.

On any given day, our users, in particular remote and mobile users, are logging into many different SaaS applications on many different devices, most of which are unmanaged. One new way for a company to get an idea of what SaaS apps are in use is to deploy the Cloud App Discovery tool from Microsoft. By deploying a lightweight agent to all, or a subset of machines, you can see which apps are in use, who is using them and how much data is being pushed through them. This can help you identify which apps are used most frequently, and will also show you if these can be integrated with Azure Active Directory to provide secure Single Sign On. Surprisingly the average amount of applications found is around 150! Integrating Azure Active Directory with these SaaS apps will bring a new level of security to your IT environment by controlling the authentication mechanism being used, thus avoiding credential leakage.

Enterprise Mobility covers many facets of securing mobile devices, mobile data and cloud services. Securing your SaaS apps is one,but what about your mobile devices? The half life of a mobile device is getting shorter all the time and it is not feasible for IT to keep track of who owns what device. With Microsoft Intune and Azure RMS in Office 365, you can enable your users to enrol and manage their own devices whilst keeping your data safe and secure.

For example, in order to access corporate email on their mobile or tablet device, a user must enrol their device with Microsoft Intune. Once this is done, conditional access is configured so that corporate data can only be accessed by approved applications. A Word Document attachment in your OWA app cannot be saved anywhere other than OneDrive for business, and cannot be edited by any app other than Word. This way, data leakage is reduced significantly. Policies for this are easy to configure in a few clicks and require no user involvement. The concept here is to enable users by providing access to apps which assist productivity, such as collaborative document management in Sharepoint and OneDrive for Business. However this data also needs to be secured for legal and compliance reasons, and conditional access can address this.

This is just a taste of the features available in the Enterprise Mobility Suite. The concept of integrating your SaaS applications with Azure AD and enabling and securing your users mobile and tablet devices using Intune will significantly improve the security and productivity of your users. Add to this the Azure Rights Management Services and Self Service Password Reset features and you are a much more mobile and secure company. BYOD is a reality and it’s time IT embraced it.

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.

Controlling Autodiscover using Group Policy

27/03/2015 – Update: This has turned into my second most popular blog post, and is also one of the first I ever wrote. For that reason, I have given it a major update and hopefully made it more readable and helpful!

Autodiscover is a very important part of any Exchange deployment these days, whether it is a cloud-based Office 365 deployment or an On Premise deployment. It is the primary method by which your clients discover where their Exchange Server is located and what configuration is set. Manual configuration of Outlook profiles is still possible, but is very much a thing of the past.

How does Autodiscover work in Outlook?

When you configure a new Outlook profile, or open Outlook with a profile already configured, the client will go through a series of lookups to discover the correct server to connect to. This process looks something like this:

1. SCP object lookup – Outlook performs an Active Directory query for Service Connection Point (SCP) objects. When an Exchange Server is installed, it registers an SCP object in Active Directory. As this is the first lookup that Outlook does, this means that if your Outlook client can contact a Domain Controller, and you happen to have an Exchange Server installed in your forest, it will find the SCP record and attempt to connect to that Exchange Server.

2. Root domain query based on your primary SMTP address – Outlook uses the root domain of your primary SMTP address to try to locate the autodiscover service, and then tries to connect to that URL to retrieve the autodiscover XML file: https://autodiscover/autodiscover.xml. For example, my Outlook client will look up If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

3. Query for the autodiscover sub-domain – Outlook uses the autodiscover sub-domain to try to locate the service. This is the most commonly configured way of deploying autodiscover from my experience. Outlook will attempt to connect to that URL to retrieve the autodiscover XML file: For example, my Outlook client will look up If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

4. HTTP redirect – Outlook uses HTTP redirection if Outlook cannot reach the Autodiscover service through method 2 or 3. This is an unlikely scenario as all Exchange traffic should be going over HTTPS, not HTTP.

5. SRV record query in DNS Outlook uses an SRV record lookup in DNS to try to locate the Autodiscover service. It is not uncommon to use SRV records, is frequently used for providing autodiscover services for customers with multiple Primary SMTP domains. This feature has been deprecated with the launch of the Autodiscover Domain feature in Exchange 2013 and 2010 SP3 RU1. More information on the concept of Autodiscover for multiple domain names can be found in this excellent article:

Why would I want to control this behaviour?

There are many situations in which you may want to control which of these lookups are actually performed. Here are a few examples:

1. You are performing a Cutover migration from Exchange>Office 365. In this case, when you make the switch and move your MX records to Office 365, you will need to do one of two things:

a. Remove Exchange completely from your environment before attempting to configure new Outlook profiles for your users. Doing this will remove the SCP record from Active Directory.

b. Configure your Outlook clients to skip the SCP lookup.

Both of these methods will ensure that your clients discover their autodiscover settings using method 3 (as long as you have your DNS configured properly!). If you don’t do this, your Outlook clients will always discover their Exchange server using method 1 (SCP lookup). Of course, you could manually configure each Outlook profile, but that is way more hassle than it’s worth!

2. You are moving back to an On Premise environment from Office 365 (god forbid!). If you are doing this you must disable SCP lookups before implementing Exchange, as otherwise your Outlook clients will find your Exchange Server before they find your Office 365 autodiscover settings. SCP lookups can then be re-enabled once you have offboarded.

3. You may simply want to optimise your autodiscover experience. For example, if you are using pure Office 365 (no Hybrid), you might aswell disable all types of lookup except for method 3, as that is the only method which will work. This can lead to speed improvements, particularly when launching Outlook.

How do I control Autodiscover?

The best way of doing this is to use the magic of Group Policy! Firstly, if you don’t already have it, download and install the .adm or .admx file for managing your preferred version of Office, be it Office 2007, 2010 or 2013. The Autodiscover settings for Office 2013 are built into the ADMX file for the whole application, whereas Office 2010/2007 use a special Autodiscover .adm file.

Office 2007:

Office 2010:

Office 2013:

To learn how to install these files, please see the ‘Loading the ADMX templates’ section of this article:

You may already have these files installed and have a Group Policy object for managing Office settings. If you do, then edit your existing policy. If not then create a new Group Policy Object and link it to the required OU. Edit your policy and navigate to the following setting:

    • Outlook 2013: User Configuration>Policies>Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange
    • Outlook 2010/2007: User Configuration>Administrative Templates>Classic Administrative Templates>Microsoft Outlook 2010>Account Settings>Exchange>AutoDiscover

As counter-intuitive as it sounds, Enable the ‘Disable Autodiscover’ parameter and select between the options shown in the screenshot below. In this example I’ve just disabled the SCP lookup.

Disable Autodisover GPOYou can confirm what lookups your Outlook client is performing by doing an Autodiscovery test. If you’ve never done this before, here’s how:

1. Go to the Outlook icon in your taskbar, hold Ctrl and right-click on it. You should see a couple of hidden options, select ‘Test E-mail AutoConfiguration’


2. Untick ‘Use Guessmart’ and ‘Secure Guessmart Authentication’, enter your e-mail address and password and test.

3. Once the test is complete, go to the Log tab to see which lookups were performed and which was successful.

Hopefully this blog post will help you out, please leave comments with suggestions or feedback. Thanks for reading!

Assosiated TechNet article:  

Mixed Server 2012 R2 / Server 2003 Domain Controller Environment & Kerberos Issues

A few months ago, the firm I work for had an issue with one of our implementations of Server 2012 R2. It was our 2nd install of Domain Controllers running this OS, and the environment we installed was experiencing Kerberos errors which caused intermittent login issues on servers and workstations. After much troubleshooting we were stumped, and the workaround of ‘reboot the server/client and you will be able to login again’ wasn’t exactly a satisfactory fix for ourselves or the client. We logged a call with Microsoft, who were also stumped by the problem as we were the first partner to report this. A registry workaround was given to us which solved the clients woes temporarily, but now a hotfix is available! We have successfully deployed this hotfix and it has cured the problem.

I won’t write a huge spiel about this problem as Microsoft have already done this for me, but if you are experiencing login issues on Windows 7, Server 2008 R2 and/or Server 2012 R2 and you have recently deployed 2012 R2 Domain Controllers in a 2003 domain environment, you may be suffering from this issue. Look in your DCs event logs for the following event:

Event ID: 4
Source: Kerberos
Type: Error
“The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/  This indicates that the password used to encrypt the Kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (, and the client realm.   Please contact your system administrator.”

Please follow this link to read more about the problem and to download the hotfix:

Move-DatabasePath error ‘WMI exception occurred on server’

Today I discovered a problem affecting the migration of a database path to a new location in Exchange 2010. After running the Move-DatabasePath cmdlet and specifying the -LogFilePath and -EdbFilePath parameters, I was faced with an error which read:

Failed to connect to target server “DDExch”. Error: WMI exception occurred on server ‘DDExch.DDAD.local’:
Call cancelled
+ CategoryInfo          : InvalidOperation: (DDDB02 Live:DatabaseIdParameter) [Move-DatabasePath], InvalidOperatio
+ FullyQualifiedErrorId : 6C2ED31B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath

It turns out that this error is related to having a large quantity of log files in Exchange 2010. The version I am running is SP3 but I am unsure as to whether this makes any difference. I also tried running this in EMC and had the same result.

To resolve this problem, either perform log truncation using your preferred Exchange backup tool, or enable circular logging to truncate the logs. Remember, after enabling circular logging, you will need to dismount and mount the database for it to take effect. I would recommend that you disable circular logging after this and dismount/mount the DB again.

Hope this helps some folk struggling with a database migration.