Planning for an O365 Migration – Assessment

I wanted to put together a post about how you actually get ready for office365, there are a few different steps that you will need to take and that’s why I am going to do this as a blog series rather than try to include everything in the one post.  This first post is going to focus on the current enviorment, the as is state if you like.

Its really important that we ensure that our current environment is as good as it can be prior to a migration to the cloud.  This is particularly important if the organisation as most do, are going to be using Azure Active Directory.  I always recommend that a customer wanting to do a move to Office365 perform an assessment of their current enviorment first.

By performing an assessment of the “as is state, we have a much better idea of the things that need to be changed, updated or removed.  I call these the remediation items and include them in any report that I prepare for the customer.  This post includes a detailed breakdown of all of the applications and scripts that I use to perform these assessment’s.

Microsoft Assessment and Planning Tool.

The Microsoft Assessment and Planning (MAP) Toolkit is an agentless inventory, assessment, and reporting tool that can securely assess IT environments for various platform migrations—including Windows 10, Windows 8.1, Windows 7, Office 2013, Office 2010, Office 365, Windows Server 2012 and Windows 2012 R2, SQL Server 2014, Hyper-V, Microsoft Private Cloud Fast Track, and Windows Azure.

One of the nice features of The Microsoft Assessment and Planning (MAP) Toolkit is that it is an agentless inventory, assessment, and reporting tool that has the ability to securely assess an environment for various platform migrations—this includes, Windows 8, Windows 7, Office 2010 and Office 365, Windows Server 2012 and Windows 2008 R2, SQL Server 2012, Hyper-V, Microsoft Private Cloud Fast Track, and Windows Azure…. Phew that’s a long list!


In a nutshell the tool provides detailed readiness assessment reports with hardware and software information, plus it also provides recommendations to help organisations with their IT infrastructure planning process.

It is an invaluable application to have in your toolkit and could be used in a number of different scenario’s. Each scenario provides detailed information and also includes the ability to generate reports which can be used to further analyse and distribute the captured information.  The scenarios that you can view are outlined below:

  • Cloud
  • Desktop
  • Server
  • Desktop Virtualisation
  • Server Virtualisation
  • Database

The tool displays the captured information in a simple yet comprehensive interface which is reminiscent of the familiar Windows 8 interface.


The cloud scenario assessment in particular offers a very detailed analysis and provides  comprehensive deployment and sizing recommendations based on the scans completed of the enviorment.

As I mentioned above, the tool provides extensive reporting capabilities including approx. 30 customer reports and proposals that are specific to the environment that the tool has inventoried.  Click here for more information on the reports and proposal that are available, this just makes my job infinitely easier!


Click here to view the MAP toolkit and download the latest version.


The backbone of every enviorment is Active Directory, without this crucial system running well the other components that make up an enviorment will typically experience a myriad of different issues.  Hence it is so important to ensure that prior to any migration, cloud or otherwise that AD is scrutinised and any issues discovered are fixed.  Microsoft have done an excellent job of providing us with a tool that will assist us in this, IDFix.

IdFix is used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Office 365. IdFix is intended for the Active Directory administrators responsible for DirSync with the Office 365 service.

This tool that will assist with preparing a Directory Synchronization deployment with Office 365. It will discover objects in Active Directory that have duplicates, invalid characters, are using a local UPN and a few other things.

One of the invaluable features of this application is that as part of the report which is generated, IDFix provides the administrator with the ability to fix up any issues discovered in the scan via the ACTION column.


Other Useful Scripts

  • Count total user, group and contact objects in Active Directory forest, this script is courtesy of Thomas Ashworth and can be downloaded here.  The results of the script will output to the PowerShell console and will be saved to a CSV file.
  • Active Directory Audit scripts, these scripts are provided courtesy of J House Consulting and there are literally too many to list here!  You can download these scripts by clicking here.  I use a few of these scripts for various things like identifying all computer objects etc.

Exchange Enviorment Report

This fantastic PowerShell script, the Exchange environment report was masterminded by Steve Goodman .  This script is my go to as a consultant, especially for Exchange Hybrid builds.  It was born out of the Exchange TAP Tool and the primary objective of the script is to generate a report which gives you a fairly granular overview of your current Exchange enviorment.  The supported versions are 2003, 2007, 2010, 2013 and 2016.  I have included an excerpt from Steve’s blog post for what the tool actually reports on:

  • Total Servers per Exchange version & service pack
  • Total Mailboxes per Exchange version & service pack, plus Office 365 remote mailboxes
  • Totals for Exchange roles across the environment
  • A site-by-site breakdown for the following:
    • Mailboxes per site
    • HTTPS FQDNs used for Internal, External and SCP URLs
    • CAS array names
    • Exchange servers, version, update rollup and version, service level, highlighted installed roles, OS version and service pack

A breakdown of each Database Availability Group including:

  • DAG name, member count and member list
  • Database information such as:
    • Name
    • Mailboxes per database and Average Size
    • Archive mailboxes per database and Average Size only shown if a DB includes Archive mailboxes
    • Database and whitespace size
    • Database and log disk free space percentage
    • Last full backup date/time (new) – only shown if at least one DAG DB has had a full backup
    • Circular Logging state (new) only shown if at least one DAG DB has circular logging enabled
    • Server hosting the active copy
    • List of servers hosting copies and copy count
    • A breakdown of Non-DAG databases including Exchange 2007 and 2003 DBs, including the database information above, along with Storage Group name (where applicable).ExchangeReport.png

Office365 Bandwidth and Network Connectivity Test

Bandwidth and network connectivity is an important consideration and often one that is overlooked by many organisations.  Unfortunately by not taking this into consideration potential problems can arise down the track when there is not enough available bandwidth for the current workload.  I use the office 365 bandwidth test and network connectivity test available here.

Note:  you will need to make sure you have the latest version of java runtime installed to see the results of the test.


So there you have it a consultants secrets revealed!  I hope that you find this post useful and that it aids you in a successful migration to Office365, I will try and keep this updated as I find new tools and develop new scripts.



To ADFS or not to ADFS…

To ADFS or not to ADFS that is question…  So this is a topic that frequently comes up in discussion with customers and I thought that it would be good to put something together where we discuss the business benefits of both identity solutions.

Something I find missing from most technical articles that talk about ADFS or Synchronised or even cloud identity for that matter is why you might choose one method over another.  I think that it is really important to keep in mind as a consultant that every customer has a unique set of requirements and a solution which might fit one customer is not necessarily going to suit another.

I realise that for the most part that this is a given, but you would be surprised at how often I see a consultant design a solution based primarily on their knowledge of having done something similar before and therefore defaulting to this, instead of considering other possibilities and working in consultation with the customer to determine exactly what they need as opposed to what they tell you that they want!

There are some key questions I believe should be asked first to determine what are the primary driving factors for choosing one identity model over the other.  These questions need not be from a technical stance, but more from an operational approach and most importantly should focus on what long term aspirations the business has.  What is their 5 year roadmap, do they want to ultimately be on the cloud or do they see themselves operating in a hybrid model with some services still on-prem?

So what are these questions, what do I need to be asking my customers?  Well we need to be asking the type of questions that make them consider what their non-negotiables are, what type of user experience they are chasing and what value proposition they expect to get from the project.

To summarise, here are some template questions that are a good starting block to make the often blurred line of what the customer wants versus what they need clearer.

  1. Would you consider your user base to be fairly comfortable with the concept of logging into and authenticating to multiple systems.  – Use examples to make them really think about what you are asking them.  Most users are comfortable using for example Facebook, LinkedIn, Gmail, etc. and so the process of logging into another system is not going to be something that is new to them.  We as consultants tend to forget that most of our user base are becoming more and more comfortable with technology as a service and how it is becoming much more commonplace in our day to day world.
  2. Consider the type of support calls that you receive from your user base, what percentage of them are related to lost passwords, forgotten usernames, etc.
  3. What security do you require?  This is a rather pointed question but is essential in understanding the type of identity model to implement.  For example is there a requirement to restrict users to accessing Outlook whilst on the corporate WAN only, or do you want to limit when users are able to use ActiveSync?
  4. Do you have a current multi factor authentication model in place, is there a plan to continue to use this and try and integrate this with Azure AD, or would you be happy implementing the multifactor offering provided in Azure AD premium?
  5. Is there a concern over syncing password hashes to the cloud, could this be mitigated with a simple information session where you as a consultant explain exactly what this means and how this process happens.
  6. Do you have the in-house capability to support a complex identity model, is your IT department skilled in this particular area.  Could your IT department recover from an outage or a system failure within a specified time frame.  Could you hold them to an SLA to support this system?
  7. What are the infrastructure requirements, do you have the bandwidth to spin up new servers?
  8. What is the desired user experience, would your user’s be comfortable with entering their login details and selecting “remember my password” at first login and then at subsequent password changes?
  9. How much of your user base work from the office on a regular basis, how many of them work from home or off site?

I am certain that there will be a host of other questions that need to be asked, the above are however a good starting point to engage the customer and get a conversation happening.

Let’s now move onto looking at the different identity models themselves in more detail.

Cloud Identity

Cloud Identity is the simplest method for providing user authentication in Office 365.  Users are completely managed and stored in the cloud.  Specifically, users are stored in the cloud in Windows Azure Active Directory and managed via the Office 365 Admin Portal or via PowerShell.  In this model users are only stored in the cloud and are not associated with any on-premises identity provider like an on-premises Active Directory.

AAD Connect (Directory Synchronization with Password Sync)

Directory Synchronization is used when you have an existing on-premises directory and you want those same users to have access to Office 365.  By installing AAD Connect, this tool will sync the user accounts up to Office 365 every 3 hours.  It eliminates the need to manually create and manage users in the cloud.  And with Password Sync, it also eliminates the need to manage user passwords in two different locations.  User identities and passwords are created and managed on-premises and synchronized to the cloud.

Federated Identity

With Federated Identity, also known as Single Sign-On, you authenticate to Office 365 using your on-premises identities.  This is commonly done with on-premises Active Directory using Active Directory Federation Services (ADFS).  ADFS requires deploying additional servers both internally and Internet-facing.   In this scenario, if for any reason users are unable to authenticate via their local AD, then users will not be able to authenticate to Office 365 and will not be able to access any of the Office 365 services.  It is therefore highly recommended that you deploy this particular scenario with high-availability / redundancy in mind.  With the release of Azure IaaS, we are seeing more customers beginning to consider and start hosting ADFS infrastructure within Azure to solve the high-availability issue.  This approach can also be beneficial when there are environmental considerations to keep in mind, for example we have a customer in Brisbane who lost access to their entire infrastructure during the 2011 floods.  By making the decision to position their ADFS servers in Azure they were able to mitigate this risk and could should an incident like this happen again continue servicing users.

If you want to know more about hosting ADFS infrastructure within Azure then I would highly recommend that you have a read of this white paper, take it to bed with you and a hot cup of jo. Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure. This content looks set to move soon so here is another link which also has some good reading points.  Understanding Office 365 identity and Azure Active Directory

So this gives you a good overview on each of the identity models, what’s interesting is that with each release of the directory synchronisation tool AAD Connect more features become available that begin to make synchronised identity a more appealing option to many businesses particular SMB clients.  The reason for this is largely due to the additional cost and complexity of deploying the required additional servers and high-availability that comes with a Federated Identity model.

There are a number of arguments to support both models, I believe that each model has its place and neither should be overlooked as a solution but perhaps what would be helpful would be to understand the different options from different perspectives, which is what the following aims to do.

The User Experience:

ADFS VS Synchronised

We can see in the table above which compares the user experiences that whilst ADFS does offer a more seamless sign on experience it does not differ greatly from directory synchronisation in applications like SharePoint online.  It is important to understand that whilst many tout ADFS as being SSO (Single Sign On) it is in fact not and the SSO experience is limited to the service offering in question.  For example SharePoint and CRM online are not single sign on aware applications, and users will still need to authenticate to these even when a domain joined workstation is connected to the internal network.

Skype for Business (aka. Lync) is really the only application where single sign on offers that seamless experience for the end user.  So, therefore one of the questions when considering ADFS should be,  “is the additional infrastructure, resources required and extra spend justified knowing that it is not a true SSO solution?”

Fun Fact:  Did you know that Skype for Business (aka. Lync) is what we call an active requestor application, it is aware of the ADFS server and talks directly to it to get a token to be used to connect to Office 365.  Outlook on the other hand is not and any token retrieval is handled under the hood by Office 365.

The branding is another hot topic, we would like to brand our sign on page, we can only do that with ADFS…. Mmmmh not so, once upon a time branding was only available to customers using Azure AD Premium or ADFS.   It is now a feature that is available for free and allows customers to brand their Office 365 sign on page with their corporate logo and images, you can even put a disclaimer or a hello at the bottom of the sign on page.  And get this, it’s available to you without ADFS.  Yes that is right you can brand the sign on page when using AAD Sync for all of your users.

I don’t know about you but in my experience most users won’t remember a seamless migration to the cloud nor will they have any knowledge of the fact that you may have picked up your entire organisation and moved them to exchange online.  What they will remember however is a new experience, something that is different from what they do everyday and this is something that be achieved easily and for free!

Moving on, there are some reasons that customers will still prefer ADFS and directory federation over AAD Sync with Password Sync.  Some of these reasons include:

  • ADFS can be configured such that users who are already logged on to a domain joined and connected machine do not require any password re-entry to sign in to Office 365.  (Arguably thought if you select remember my password the same can be said for AADSync with password sync.) This gives you true single sign-on since re-entry of the password is not required. With AADSync and password sync a user must still re-enter their password, although it will be the same password as the one that they use on-premises.
  • ADFS allows for client access filtering, which restricts access to Exchange Online to users based on their IP address, you can also limit when users are able to use ActiveSync, when they can access Outlook etc. using Client Access Policies.
  • ADFS will honour Active Directory configured login time restrictions for users.
  • ADFS has the ability for users to change their passwords whilst they are outside the corporate network. (Cloud Auth also does this, but that is another post for another day)
  • ADFS permits use of on-premises deployed multi-factor authentication products.

The Admins perspective

As many of you reading this blog post would know implementing ADFS using traditional methods means a lot of additional infrastructure, it also requires additional technical knowledge that not all in house IT departments have.  In addition there is a requirement to ensure that the ADFS infrastructure is highly available at all times, an outage of ADFS can be compared to that of a domain controller going down.  It is a serious outage and would result in users being unable to authenticate.

There is also a common misconception that by installing directory synchronization with password sync that if the ADFS servers were to go offline then users could still authenticate using password sync.  This is not the case, it would take approx. 3 hours to cut over to password sync and in that time the ADFS servers could have been brought back online.  This is a caveat that is worth bearing in mind when considering using ADFS.

Another frequent complaint is that the support desk is inundated with I’ve forgotten my password requests and I need users to be able to reset their passwords on the fly.  Did you know that this functionality is available for subscribers to Azure AD Premium using directory synchronisation with password right back.  Previously a feature that was limited to ADFS.

Azure AD Premium, you hear me say… mmmh that sounds expensive!  Well its pricey compared to the free version of course, however it is a lot cheaper than implementing ADFS and it may just offer some of the key services that your customer was previously considering ADFS for!

So what are some of the cool features?  Well there is:

  • Microsoft Identity manager or Forefront Identity Manager

A whole other topic!

  • Self Service Password Reset (write back to on premises)

Enabling your users to manage their own cloud Azure Active Directory or on-premises Active Directory passwords takes just a few simple steps.

  • Advanced Security Reports

You can use Azure Active Directory’s access and usage reports to gain visibility into the integrity and security of your organization’s directory. With this information, a directory admin can better determine where possible security risks may lie so that they can adequately plan to mitigate those risks.

In the full Azure Management Portal, reports are categorized in the following ways:

  • Anomaly reports – Contain sign in events that we found to be anomalous. Our goal is to make you aware of such activity and enable you to be able to make a determination about whether an event is suspicious.
  • Integrated Application report – Provides insights into how cloud applications are being used in your organization. Azure Active Directory offers integration with thousands of cloud applications.
  • Error reports – Indicate errors that may occur when provisioning accounts to external applications.
  • User-specific reports – Display device/sign in activity data for a specific user.
  • Activity logs – Contain a record of all audited events within the last 24 hours, last 7 days, or last 30 days, as well as group activity changes, and password reset and registration activity.
  • Multi Factor Authentication

Azure Multi-Factor Authentication helps safeguard access to data and applications while meeting user demand for a simple sign-in process. It provides additional security by requiring a second form of authentication and delivers strong authentication via a range of easy verification options:

  • phone call
  • text message
  • mobile app notification—allowing users to choose the method they prefer
  • mobile app verification code
  • 3rd party OATH tokens

If you want to learn more about Azure Active Directory Premium I would encourage you to take a look a session that a colleague of mine did, Mark Rhodes at the Ignite conference on the Gold Coast.

So in summary what are we saying…  We are saying that when it comes to choosing an identity model go with the simplest solution that suits your requirements.  You are not locked into any of these identity models and should you find that your requirements change down the track then going to ADFS from synchronised is a doable exercise as is going to a synchronised identity from ADFS.

offCAT – All you need to know (Office Configuration Analyzer Tool 2.1)

So here I was drinking my morning tea and working out what my day has in store for me, mostly studying and then more studying as I am sitting my Office365 exams when I came across an email linking to this potential gem – offCAT or Microsoft Office Configuration Analyzer Tool.

The Microsoft Office Configuration Analyzer Tool (OffCAT) 2.1 provides a quick and easy way to analyze Microsoft Office programs for known configurations that cause problems.

I love applications like this which make my job infinitely easier and allow me to get a more granular understanding of what is happening under the hood!


This is an output of the report I have run on my Outlook application and as you will see from the screenshot, offCAT has picked up a number of issues that are present.  There is a decent breakdown of these issues in the right hand window pane which gives us some further information.

I particularly like that you are able to export the report and email it, which is helpful if you need to get a second set of eyes on a potential issue.

Moving further along the tabs, we see that there is a configuration option which again I really like.  It gives us a fairly decent overview of the current setup and provides us with some feedback by way of the little icons to indicate whether we should review the configuration for certain settings.


The other aspect of this application which is rather helpful is when the install completes, a new menu option will appear in the ribbon called “offCAT” this allows you to detect problems from within the application itself.  Nifty eh?!


So there you have it, I’d highly recommend that you download this little piece of Microsoft goodness and have a play with it.  This is a nice new addition to my already quite extensive toolkit which I will be sharing over the coming weeks / months /  years, who knows its an ever evolving landscape!

Anyway keep reading my stuff!

In at the deep end – Exchange Hybrid Goodness Part 2

So…. we move onto the illustrious part 2 of our Exchange Hybrid blog goodness.  In part 1 we covered the versions, pre-reqs, useful tools and some of the more finer points that tend to get overlooked as part of a hybrid build.

In part 2 we are actually going to get onto the build phase of Exchange, hold onto your hats this is going to get a little fun!

I am making an assumption that as per part 1 of this series you have reviewed your current environment and have patched your Exchange 2007 servers to the latest required patch levels.  We should now be raring to go and ready to install our first Exchange 2013 server.

Installing Exchange 2013 is actually pretty straight forward and doesn’t need any sort of technical kung fu to get going….. Did I just say straight forward, haha I was joking! Generally speaking its straight forward, there are a couple of pre-installation tasks that we need to complete before we can kick the install off.

In my scenario I am going to be installing Exchange 2013 on a Windows server 2012 machine, there are a few things that we need to be aware of before we jump in and start the install, these are;

  • The Active Directory forest functional level should be at the very minimum Windows Server 2003
  • At least one of the domain controller’s should be running Windows Server 2008
  • As in other versions prior to 2013 the best practice advice is to deploy Exchange 2013 as a member server

In my particular scenario the Exchange Server 2013 that I am building is going to be a multi role server so it will be my Client Access Server (CAS) and my Mailbox (MBX) server.  There is a little tidbit of information here that I think it is worth mentioning as it is not something that a lot of people are aware of when they begin considering adopting a hybrid approach for their organisation.  This little bit of information is that, Microsoft to encourage businesses to adopt a hybrid approach and ultimately move their mail off of on-prem servers to Exchange online offers what is known as a hybrid Exchange product key.

What this license entitles you to is an install of Exchange Server 2013 with both the MBX and CAS roles installed acting solely as the hybrid server.  This license is only free for as long as you are not hosting mailboxes on the server, the moment that you begin creating or migrating mailboxes is when you are in breach of the licensing terms.  You can get a hybrid license by clicking on this link, you will be taken to the page below:


If you select “Get Key” the next page will ask you to specify what version of on-premises Exchange hybrid servers you have installed or that you plan to install.  The wizard will then verify the eligibility of your Office365 subscription and if successful will give you a license to be used with your hybrid build..


Now that we have a license key to use, we move onto installing the pre-reqs for Windows 2012.  Now this is a straightforward task, simply copy the few lines of powershell I have below and windows installer will take care of the rest for you.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

Once all of these windows features have been installed you will need to reboot the server. Its now time to install the last few applications which I have listed below with links to the download locations:

Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

Microsoft Office 2010 Filter Pack 64 bit

Microsoft Office 2010 Filter Pack SP1 64 bit

To start the Exchange install you need to make sure that the account you are using has the appropriate rights to Active Directory this is because as part of the install Exchange will make changes / update the Schema.  The account either needs to be added to the Schema admins or the Organisation Management group, generally speaking I usually add my account to both and make sure that it is running as a domain admin and local admin on the server aswell.

I am not going to take you step by step through the Exchange install as it is fairly straight forward, just make sure that you select the Mailbox and Client Access roles on the Server Role Selection window.


After you have made all of your selections, the setup will start.  At this point I would strongly recommend that you either feed yourself or top up on your caffeine quota for the day as the install generally takes quite a bit of time to complete.


Once completed restart the server.

As I am sure that you are aware the Exchange Management Console (EMC) and the Exchange Control Panel (ECP) are no longer in this version of Exchange and both tools have been replaced by the Exchange Admin Center (EAC).  This is a web-based management console which has been specifically optimised for on-premises, online, and hybrid Exchange deployments, in other words its pretty hot property!

There are several advantages to using the web based EAC, one is that you can partition Internet and intranet access from within the ECP IIS virtual directory. With this functionality, you can control whether users are allowed to have Internet access to the EAC from outside of your organization, while still allowing an end user to access Outlook Web App Options.  Pretty cool right?!

Because the EAC is now a web-based management console, you’ll need to use the ECP virtual directory URL to access the console from your web browser. In most cases the EAC’s URL will look similar to the following:

  • Internal URL: https://<CASServerName>/ecp   The internal URL is used to access the EAC from within your organization’s firewall.
  • External URL:   The external URL is used to access the EAC from outside of your organization’s firewall. Some organizations may want to turn off external access to the EAC.

See Turn off access to the Exchange admin center for instructions on how to do this

In our particular scenario as I mentioned in part 1 we are installing Exchange 2013 in a coexistence scenario where we are still running Exchange 2007, and my mailbox is still housed on the Exchange 2007 mailbox server.  What this means is that the browser will default to the Exchange 2007 ECP.

You can access the EAC by adding the Exchange version to the URL. For example, to access the EAC whose virtual directory is hosted on the Client Access server MBX-13, use the following URL: https://MBX-13/ecp/?ExchClientVer=15.

Conversely, if you want to access the Exchange 2007 ECP and your mailbox resides on an Exchange 2013 Mailbox server, use the following URL: https://MBX-07/ecp/?ExchClientVer=14.

Its now time to install the latest CU, CU10 is available.  I would strongly recommend that you buck tradition and install the latest CU that you are able to get your hands on.  There are several reasons that I suggest this, primarily though its because any changes / updates that are made to the hybrid wizard will be better catered for in an up to date on-prem Exchange server.

Now that we have Exchange installed, we can move onto the hybrid aspects of this blog series which is really what we have been building upto!  Stay tuned for part 3 🙂

In at the deep end – Exchange Hybrid Goodness Part 1

Well!  After a short introduction a month a go its been a fairly busy 5 or so weeks!  What with Christmas and New Years happening I haven’t had much of an opportunity to take to my blog and chat about some stuff.

Without further ado though lets talk about a subject that’s fairly close to my heart and one I particularly enjoy – Exchange Hybrid!  Yes you heard me right, I have done a few of these builds now and I wanted to put together something that would get all of the goodness together in one place.  This blog post is part 1 of a 3 part series, this first part will talk about the pre-reqs, the tools to get you started and the things that are most commonly overlooked.

First things first lets talk version’s, this post is all about 2013 hybrid we have done away with the days of Exchange 2010 hybrid and vast improvements have been made to the somewhat complex undertaking of the hybrid wizard for 2010.  It is definitely the way to go, its fully supported by Exchange 2007 and 2010 so unless you are running 2003 (tell me you aren’t right?!) then its a no brainer.

Lets talk about the pre-reqs, what do we need to get it going…..

If you are running Exchange 2007 you will need to make sure that the servers are patched to Service Pack 3 RU10.  If it’s 2010 then you will need to make sure that your servers have been updated to Service Pack 3.

Now as with all things Exchange, I turn to my trusty friend the Exchange Deployment Assistant.  The Exchange Server Deployment Assistant is a web-based tool that asks you a few questions about your current environment and then generates a custom step-by-step checklist that will help you deploy different versions of Exchange Server for different types of scenarios.  This little known tool is a god send and I would highly recommend that prior to undertaking any type of Exchange deployment that you take a long, loving look at this little sweetheart.


After plugging your scenario into the Deployment Assistant, you will be presented with a deployment report which includes step by step instructions, you even have the option of printing out the report in a Microsoft Word format. There are a couple of hybrid scenarios that we could cover, this blog post is going to be focusing on getting Exchange 2007 setup in a hybrid topology with Exchange 2013 acting as the hybrid transport role.

The first steps to any deployment or migration is planning!  Generally I like to take stock of the current environment and work out what I have and where we are up to with the build levels, how many mailboxes I have etc.  To do this, I run a power shell script which was created by the clever Steve Goodman.  His script, inspired by the output of an Exchange TAP tool, aims to automatically generate a report that gives you an overview of your environment, Exchange 2003, 2007, 2010, 2013 and 2016 servers and database availability groups.  To learn more about this tool and to download it head over to his blog post.


Once we have our environment report, we are able to determine whether any service packs or patches need to be applied to any of the servers in preparation for Exchange 2013.  At this stage in the game I would recommend that you plan an outage window and get those servers patched if need be.

This report should also give us a good indication as to who is a a bit of a hoarder when it comes to their emails (a few friends spring to mind here, one in fact who will no doubt be reading this and nodding his head in agreement), and those who like to get organised and stay organised with our nice compact, ‘couple a hundred’ MB mailboxes.  The sizing is a good thing to be aware of because its going to give us a good benchmark to work out how long its going to take to move mailboxes online.

I have a particular nifty little calculator that I use to estimate the throughput of a mailbox migration, this little nugget of goodness will allow me to work out the time of a single mailbox migration or the time taken for simultaneous mailbox moves.  I simply plug in my speeds and the average mailbox size and it should give me the estimate in hours.


Something that may help you get into the mindset of adopting a hybrid approach is to understand that the hybrid component is really a very small part of the entire process.  We effectively have to stand Exchange 2013 up in “coexistence” with Exchange 2007 before we can even begin to get mailboxes online.

Note: if you are running Exchange 2007 on a Windows server that is running 2008 make sure that you disable IPV6 as it can cause some connection issues between the 2 versions of Exchange.  Refer to this blog here for good instructions on how to do it and check that its been done.

Introducing Exchange 2013 into an Exchange 2007 environment is a fairly straightforward task. However that being said, generally speaking one of the most overlooked, and least documented topics is the proper configuration of URLs for Proxy and Redirection.

A good place to start is with this blog post by Michael Van Horenbeeck. This article explains when Exchange 2013 will proxy connections to Exchange 2007 and when it will redirect the connection.  This is a worthwhile read as most instances of coexistence fall into the trap of not setting up the legacy namespaces, I suggest setting these namespaces up even if you are doing a hybrid build as it keeps things nice and neat.

It is worth noting however that this isn’t always applicable to everyone’s environment. For example if we were to setup a hybrid environment which was only going to be used for a short period of time it would be preferable to use for the URL’s for the Exchange 2013 server, and keep the existing 2007 URL’s in place changing only the autodiscover URL to point to the 2013 CAS.

In our scenario we have a very simple setup.  We have a single Exchange 2007 server and a single Exchange 2013 server.  Hybrid is likely to be in operation for a period of time whilst mailboxes are migrated over in batches to Exchange online so therefore I have chosen to update the 2007 URL’s to use the legacy namespace.

Prior to Exchange 2013 being introduced, our 2007 URLs were configured as follows:

Our DNS was configured as follows: – –

The default internalURL and AutoDiscoverServiceInternalURI values are derived from the server FQDN, but these have since been changed.  Your configuration may be different depending on how it was setup.

Likewise, when Exchange 2013 is introduced into the environment, the default values are derived from the server FQDN.

For Coexistence and interoperability between Exchange 2013 and 2007, these values all need to be changed.  The first step in the migration process is to update these values so that all users connect to OWA, EAS, and OA via Exchange 2013.  The details of why can be found in Michael Van Horenbeeck’s blog post, essentially Exchange 2013 can proxy and redirect back to 2007, but 2007 cannot proxy forward to Exchange 2013.

Before we can change over any of these URL’s we need to test thoroughly and we need to make sure that the SAN cert which we have for Exchange has been updated with the new namespace.  For my particular scenario the customer decided to use a wildcard cert, this option is usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

The security question which I know you want to ask, is also relatively easy to answer. There is a common assumption that wildcard certs are less secure than other certs, say for example the commonly used SAN cert.

Microsoft’s own documentation even has to references “the security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain.

Symantec or Verisign as most know them details some of those implications here:

  • Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
  • Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

If however, like in our scenario we are using a wildcard cert to secure a single internet facing CAS server then the above issues do not cause me or the customer too much concern.  If however you are planning on deploying a large Exchange organisation with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.

If I am in a production scenario I generally like to test everything that I can before making any changes to the already configured Exchange 2007 server.  Usually I will set up some fake URL’s on the 2013 server and using host file manipulation test all of the connections to make sure that the proxying and redirecting is working prior to cutting things over to the new URL’s.

After the testing has been completed.  It is time to update the Exchange 2013 and 2007 URLs.  Once complete the new URL’s should look a little like this:

Our DNS will now look like this:

Let’s take a closer look at some of the configuration.

OWA – Redirect.  When a user whose mailbox still resides on 2007, accesses OWA via the 2013 CAS, they will be redirected back to 2007 via externalURL value:

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrl –ExternalURL

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrl –ExternalURL

ActiveSync – Proxy. I would recommend that as a best practice we setup ActiveSync to proxy from 2013 to 2007 as some ActiveSync devices do not handle the redirect correctly.  I have seen this occur with some Apple devices running older versions of IOS.

In order to force a proxy scenario, the externalURL value for 2007 is set to $null.  The internalURL on 2007 should be configured with

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL –ExternalURL

Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL –ExternalURL $null

Outlook Anywhere – Proxy. All OA connections, both 2007 mailboxes and 2013 mailboxes will now connect via the 2013 CAS.  2013 will proxy connections back to 2007 for legacy mailboxes.

The externalHostName for 2013 and 2007 should be the same, (

Note: Exchange 2007 does not support “Negotiate” authentication (refer to image below).  This means that the externalClientAuthenticationMethods should be configured to match whatever is configured for 2007, which is either Basic or NTLM.  For Outlook Anywhere to proxy from 2013 to 2007, the IISAuthenticationMethods on 2007 will need to be reconfigured to support both Basic and NTLM.  By default, Exchange 2007 IISAuthenticationMethods is set to just Basic.  NTLM must be added for the proxy to work.


Set-OutlookAnywhere –Identity “Ex2013\Rpc (Default Web Site)” –InternalHostname –ExternalHostName –ExternalClientAuthenticationMethod Basic –IISAuthenticationMethods Basic,NTLM

Set-OutlookAnywhere –Identity “Ex2007\Rpc (Default Web Site)”  –IISAuthenticationMethods Basic,NTLM

Exchange Web Services – (AutoDiscover) Autodiscover is used to retrieve the Exchange Web Services configuration for the 2007 users.  Refer to another of my posts on how autodiscover works.

Set-WebServicesVirtualDirectory –Identity “Ex2013\EWS (Default Web Site)” –InternalURL –ExternalURL

Set-WebServicesVirtualDirectory –Identity “Ex2007\EWS (Default Web Site)” –InternalURL –ExternalURL

AutoDiscover – Both the 2007 and 2013 Service Connection Point (SCP) locator can be configured to point to the Autodiscover URL

Make sure that the the internal and external DNS is updated so that the A record for the autodiscover.domain resolves to the Exchange 2013 Client access server.

Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUri

ECP –  Exchange 2007 did not have an ECP virtual directory.  Therefore only the 2013 ECP virtual directory needs to be configured.

Set-EcpVirtualDirectory –Identity “Ex2013\ecp (Default Web Site)” –InternalURL –ExternalURL

That’s it for now, part 2 is on the horizon and will be coming shortly!