ADFS v 3.0 (2012 R2) Migration to ADFS 4.0 (2016) – Part 1

Introduction

With the release of Windows Server 2016, Microsoft has introduced new and improved features. One of those features is ADFS 4.0, better known as ADFS 2016.

Organisations have already started leveraging ADFS 2016 as it covers most of their requirement, specially in terms of security.

In this series of blog posts, I will demonstrate how you can upgrade from ADFS v 3.0 (Running Windows Server 2012 R2) to ADFS 2016 (Running Windows Server 2016 Datacenter). In the series to come I will also cover Web Application Proxy (WAP) migration from Windows Server 2012 R2 to Windows Server 2016. Moreover, I will cover integration of Azure MFA with the new ADFS 2016.

The posts in this series assume you have knowledge in Windows Servers, AD, ADFS, WAP, and MFA. This blog post will not go into detailed step-by-step installation of roles and features. This blog post also assumes you have a running environment of AD, ADFS/WAP (2012 R2), AAD Connect already configured.

What’s New in ADFS 2016?

ADFS 2016 offers new and improved features included:

  • Eliminate Passwords from the Extranet
  • Sign in with Azure Multi-factor Authentication
  • Password-less Access from Compliant Devices
  • Sign in with Microsoft Passport
  • Secure Access to Applications
  • Better Sign in experience
  • Manageability and Operational Enhancements

For detailed description on the aforementioned points, please refer to this link.

Current Environment

  • 2x ADFS v3 Servers (behind an internal load balancer)
  • 2x WAP 2012 R2 Server (behind an external load balancer)
  • 2x AD 2012 R2 Servers
  • 1x AAD Connect server

At a high level design, this is how the ADFS/WAP environment looks:

sso

Future environment:

  • 2x ADFS 2016 Servers (behind the same internal load balancer)
  • 2x WAP 2016 Servers (behind the same external load balancer)
  • 2x AD 2012 R2 Servers
  • 1x AAD Connect Server

Planning for your ADFS and WAP Migration

At first, you need to make sure that your applications can support ADFS 2016, some legacy applications may not be supported.

The steps to implement SSO are as follows:

  1. Active Directory schema update using ‘ADPrep’ with the Windows Server 2016 additions
  2. Build Windows Server 2016 servers with ADFS and install into the existing farm and add the servers to the Azure load balancer
  3. Promote one of the ADFS 2016 servers as “primary” of the farm, and point all other secondary servers to the new “primary”
  4. Build Windows Server 2016 servers with WAP and add the servers to the Azure load balancer
  5. Remove the WAP 2012 servers from the Azure load balancer
  6. Remove the ADFSv3 servers from the Azure load balancer
  7. Raise the Farm Behavior Level feature (FBL) to ‘2016’
  8. Remove the WAP servers from the cluster
  9. Upgrade the WebApplicationProxyConfiguration version to ‘2016’
  10. Configure ADFS 2016 to support Azure MFA and complete remaining configuration

The steps for the AD schema upgrade are as follows:

  1. Prior to starting, the Active Directory needs to be in a health state, in particular replication needs to be performing without error.
  2. The Active Directory needs to be backed-up. Best to backup (at a minimum) a few Active Directory Domain Controllers including the ‘system state’
  3. Identify which Active Directory Domain Controller maintains the Schema Master role
  4. Perform the update using an administrative account by temporarily adding the account to the Schema Admin group
  5. Download and have handy the Windows Server 2016 installation media
  6. When ready to update the schema, perform the following:
  7. Open an elevated command prompt and navigate to support\adprep directory in the Windows Server 2016 installation media. Run the following: adprep /forestprep.
  8. Once that completes run the following: adprep/domainprep

Upgrading the Active Directory schema will not impact your current environment, nor will it raise the domain/forest level.

Part 2 of this series will be published early next week. Therefore make sure to please come back and check in details the migration process.

 

Azure AD Connect pass-through authentication. Yes, no more AD FS required.

Originally posted on Lucian’s blog at clouduccino.com. Follow Lucian on Twitter: @LucianFrango.

***

Yesterday I received a notification email from Alex Simons (Director of PM, Microsoft Identity Division) which started like this:

Todays news might well be our biggest news of the year. Azure AD Pass-Through Authentication and Seamless Single Sign-on are now both in public preview!

So I thought I’d put together a streamlined overview of what this means for authentication with regards to the Microsoft Cloud and my thoughts on if I’d use it.

Before:

2016-12-09-before-01

What is Azure AD pass-through auth?

When working with the Microsoft Cloud, organisations from small to enterprise leverage the ability to have common credentials across on-premises directories (ADDS) and the cloud. It’s the best user experience, it’s the best IT management experience as well. The overhead of facilitating this can be quite a large endeavour. There’s all the complexities of AD FS and AADConnect to work through and build with high availability and disaster recovery in mind as this core identity infrastructure needs to be online 24/7/365.

Azure AD Pass-through authentication (public preview) simplifies this down to Azure AD Connect. This new feature can, YES, do away with AD FS. I’m not in the “I hate AD FS” boat. I think as a tool it does a good job: proxying authentication from external to ADDS and from Kerberos to SAML. For all those out there, I know you’re out there, this would be music to your ears.

Moreover, if you wanted to enjoy SINGLE SIGN ON, you needed AD FS. Now, with pass-through authentication, SSO works with just Azure AD Connect. This is a massive win!

So, what do I need?

Nothing too complicated or intricate. The caveat is that the support for this in public preview feature is limited, as with all preview offerings from Azure. Don’t get to excited and roll this out into production as yet! Dev or test it as much as possible and get an understanding of it, but, don’t go replacing AD FS just yet.

Azure AD Connect generally needs a few ports to communicate with ADDS on-premises and Azure AD in the cloud. The key port being TCP443. With pass-through authentication, there are ~17 other ports (with 10 of which included in a range) that need to be opened up for communication. While this could be locked down at the firewall level to just Azure IP’s, subnets and hosts, it will still make security question and probe for details.

The version of AADConnect also needs to be updated to the latest, released on December 7th (2016). From version 1.1.371.0, the preview feature is now publicly available. Consider upgrade requirements as well before taking the plunge.

What are the required components?

Apart from the latest version of Azure AD Connect, I touched on a couple more items required to deploy pass-though authentication. The following rapid fire list outlines what is required:

  • A current, latest, version of Azure AD Connect (v 1.1.371.0 as mentioned above)
  • Windows Server 2012 R2 or higher is listed as the operating system for Azure AD Connect
    • If you still have Server 2008 R2, get your wiggle on and upgrade!
  • A second Windows Server 2012 R2 instance to run the Azure App Proxy .exe to leverage high availability
    • Yes, HA, but not what you think… more details below
  • New firewall rules to allow traffic to a couple wildcard subdomains
  • A bunch of new ports to allow communication with the Azure Application proxy

For a complete list, check out the docs.microsoft.com article with detailed config.

What is this second server business? AADConnect has HA now?

Much like AD FS being designed to provide high availability for that workload, there is the ability to provide some HA around the connectors required for the pass-through auth process. This is where it gets a little squirly. You won’t be deploying a second Azure AD Connect server and load balance the two.

The second server is actually an additional server, I would imagine a vanilla Windows Server instance, in which a deployment of Azure AD Application Proxy is downloaded, executed and run.

The Azure Application Proxy is enabled in Azure AD, the client (AADApplicationProxyConnectorInstaller.exe) downloaded and run (as mentioned above). This then introduces two services that run on the Windows Server instance and provide that connector to Azure AD. For more info, review the docs.microsoft.com article outlines the setup process.

After:

2016-12-09-after-01

Would I use this?

I’ll answer this in two ways, then I’ll give you my final verdict.

Yes, I would use this. Simplifying what was “federated identity” to “hybrid identity” has quite a few benefits. Most importantly the reduced complexity and reduced requirements to maintain the solution. This reduced overhead can maintain a higher level of security, no credentials (rather passwords), being stored in the cloud at all. No hashes. Nadda. Zilch. Zero. Security managers and those tightly aligned to government regulations: small bit of rejoice for you.

No, I would not use this. AD FS is a good solution. If I had an existing AD FS solution that tied in with other applications, I would not go out of my way to change that just for Office 365 / Azure AD. Additionally, in preview functionality does not have the same level of SLA support. In fact, Azure in preview features are provided “as is”. That is not ideal for production environments. Sure, I’d put this in a proof of concept, but, I wouldn’t recommend rolling this out anytime soon.

Personally, I think this is a positive piece of SSO evolution within the Microsoft stack. I would certainly be trying to get customers to proof of concept this and trial it in dev or test environments. It can further streamline identity deployments and could well defer customers from ever needing or deploying AD FS, thus saving in instance cost and managed services cost supporting the infrastructure. Happy days!

Final thoughts

Great improvement, great step forward. If this was announced at Microsoft Ignite a couple of months back, I think it would have been big news. Try it, play with it, send me your feedback. I want to always been learning, improving and finding out new gotchas.

Best,

Lucian

Real world Azure AD Connect: the case for TWO Azure AD Connect servers

Originally posted on Lucian’s blog at clouduccino.com. Follow Lucian on Twitter @LucianFrango.

***

I was exchanging some emails with an account manager (Andy Walker) at Kloud and thought the exchange would be for some interesting reading. Here’s the outcome in an expanded and much more helpful (to you dear reader) format…

***

Background

When working with the Microsoft Cloud and in particular with identity, depending on some of the configuration options, it can be quite important to have Azure AD Connect highly available. Unfortunately for us, Microsoft has not developed AADConnect to be highly available. That’s not ideal in today’s 24/7/365 cloud-centric IT world.

When disaster strikes, and yes that was a deliberate use of the word WHEN, with email, files, real-time communication and everything in between now living up in the sky with those clouds, should your primary data centre be out of action, there is a high probability that a considerable chunk of functionality will be affected by your on-premises outage.

Azure AD Connect

AADConnect’s purpose, it’s only purpose, is to synchronise on-premises directories to Azure AD. There is no other option. You cannot sync an ADDS forest to another with Azure AD Connect. So this simple and lightweight tool only requires a single deployment in any given ADDS forest.

Even when working with multiple forests, you only need one. It can even be deployed on a domain controller; which can save on an instance when working with the cloud.

The case for two Azure AD Connect servers

As of Monday April 17th 2017, just 132 days from today (Tuesday December 6th), DirSync and Azure AD Sync, the predecessors to Azure AD Connect will be deprecated. This is good news. This means that there is an opportunity to review your existing synchronisation architecture to take advantage of a feature of AADConnect and deploy two servers.

2016-12-06-two-aadc-v01

Staging mode is fantastic. Yes, short and sweet and to the point. It’s fantastic. Enough said, blog done; use it and we’re all good here? Right?

Okay, I’ll elaborate. Staging mode allows for the following rapid fire benefits which greatly improves IT as a result:

1 – Redundancy and disaster recovery, not high availability

I’ve read in certain articles that staging mode offers high availability. I disagree and argue it offers redundancy and disaster recovery. High availability is putting into practice architecture and design around applications, systems or servers that keeps those operational and accessible as near as possible to 100% uptime, or always online, mostly through automated solutions.

I see staging mode as offering the ability to manually bring online a secondary AADConnect server should the primary be unavailable. This could be due to a disaster or a scheduled maintenance window. Therefore it makes sense to deploy a secondary server in an alternate data centre, site or geographic location to your primary server.

To do the manual update of the secondary AADConnect server config and bring it online, the following needs to take place:

  • Run Azure AD Connect
    • That is the AzureADConnect.exe which is usually located in the Microsoft Azure Active Directory Connect folder in Program Files
  • Select Configure staging mode (current state: enabled), select next
  • Validate credentials and connect to Azure AD
  • Configure staging mode – un-tick
  • Configure and complete the change over
  • Once this has been run, run a full import/full sync process

This being a manual process which takes time and breaks service availability to complete (importantly: you can’t have two AADConnect servers synchronising to a single Azure AD tenant), it’s not highly available.

2 – Update and test management

AADConnect now offers (since February 2016) an in-place automatic upgrade feature. Updates are rolled out by Microsoft and installed automatically. Queue the alarm bells!

I’m going to take a stab at making an analogy here: you wouldn’t have your car serviced while it’s running and taking you from A to B, so why would you have a production directory synchronisation server upgraded while its running. A bit of a stretch, but, can you see where I was going there?

Having a secondary AADConnect server allows updates and or server upgrades without impacting the core functionality of directory synchronisation to Azure AD. While this seems trivial, it’s certainly not trivial in my books. I’d want my AADConnect server functioning correctly all the time with minimal downtime. Having the two servers can allow for a 15 min (depending on how fast you can click) managed change over from server to server.

3 – Improved management and less impact on production

Lastly, this is more of a stretch, but, I think it’s a good practice to not have user accounts assigned Domain Admin rights. The same applies to logging into production servers to do trivial tasks. Having a secondary AADConnect server allows for IT administrators or service desk engineers to complete troubleshooting of sync processes for the service or objects away from the production server. That, again in my books, is a better practice and just as efficient as using primary or production servers.

Final words

Staging mode is fantastic. I’ve said it again. Since I found out about staging mode around this time last year, I’ve recommended to every customer I’ve mentioned AADConnect too, to use two servers referencing the 3 core arguments listed above. I hope that’s enough to convince you dear reader to do so as well.

Best,

Lucian

Real world Azure AD Connect: multi forest user and resource + user forest implementation

Originally posted on Lucian’s blog at clouduccino.com. Follow Lucian on Twitter @LucianFrango.

***

Disclaimer: During October I spent a few weeks working on this blog posts solution at a customer and had to do the responsible thing and pull the pin on further time as I had hit a glass ceiling. I reached what I thought was possible with Azure AD Connect. In comes Nigel Jones (Identity Consultant @ Kloud) who, through a bit of persuasion from Darren (@darrenjrobinson), took it upon himself to smash through that glass ceiling of Azure AD Connect and figured this solution out. Full credit and a big high five!

***

tl;dr

  • Azure AD Connect multi-forest design
  • Using AADC to sync user/account + resource shared forest with another user/account only forest
  • Why it won’t work out of the box
  • How to get around the issue and leverage precedence to make it work
  • Visio’s on how it all works for easy digestion

***

In true Memento style, after the quick disclaimer above, let me take you back for a quick background of the solution and then (possibly) blow your mind with what we have ended up with.

Back to the future

A while back in the world of directory synchronisation with Azure AD, to have a user and resource forest solution synchronised required the use of Microsoft Forefront Identity Manager (FIM), now Microsoft Identity Manager (MIM). From memory, you needed the former of those products (FIM) whenever you had a multi-forest synchronisation environment with Azure AD.

Just like Marty McFly, Azure AD synchronisation went from relative obscurity to the mainstream. In doing so, there have been many advancements and improvements that negate the need to ever deploy FIM or MIM for ever the more complex environment.

When Azure AD Connect, then Azure AD Sync, introduced the ability to synchronise multiple forests in a user + resource model, it opened the door for a lot of organisations to streamline the federated identity design for Azure and Office 365.

2016-12-02-aadc-design-02

In the beginning…

The following outlines a common real world scenario for numerous enterprise organisations. In this environment we have an existing Active Directory forest which includes an Exchange organisation, SharePoint, Skype for Business and many more common services and infrastructure. The business grows and with the wealth and equity purchases another business to diversity or expand. With that comes integration and the sharing of resources.

We have two companies: Contoso and Fabrikam. A two-way trust is set up between the ADDS forests and users can start to collaboration and share resources.

In order to use Exchange, which is the most common example, we need to start to treat Contoso as a resource forest for Fabrikam.

Over at the Contoso forest, IT creates disabled user objects and linked mailboxes Fabrikam users. When where in on-premises world, this works fine. I won’t go into too much more detail, but, I’m sure that you, mr or mrs reader, understand the particulars.

In summary, Contoso is a user and resource forest for itself, and a resource forest for Fabrikam. Fabrikam is simply a user forest with no deployment of Exchange, SharePoint etc.

How does a resource forest topology work with Azure AD Connect?

For the better part of two years now, since AADConnect was AADSync, Microsoft added in support for multi-forest connectivity. Last year, Jason Atherton (awesome Office 365 consultant @ Kloud) wrote a great blog post summarising this compatibility and usage.

In AADConnect, a user/account and resource forest topology is supported. The supported topology assumes that a customer has that simple, no-nonsense architecture. There’s no room for any shared funny business…

AADConnect is able to select the two forests common identities and merge them before synchronising to Azure AD. This process uses the attributes associated with the user objects: objectSID in the user/account forest and the msExchMasterAccountSID in the resource forest, to join the user account and the resource account.

There is also the option for customers to have multiple user forests and a single resource forest. I’ve personally not tried this with more than two forests, so I’m not confident enough to say how additional user/account forests would work out as well. However, please try it out and be sure to let me know via comments below, via Twitter or email me your results!

Quick note: you can also merge two objects by sAmAccountName and sAmAccountName attribute match, or specifying any ADDS attribute to match between the forests.

Compatibility

aadc-multi-forest

If you’d like to read up on this a little more, here are two articles reference in detail the above mentioned topologies:

Why won’t this work in the example shown?

Generally speaking, the first forest to sync in AADConnect, in a multi-forest implementation, is the user/account forest, which likely is the primary/main forest in an organisation. Lets assume this is the Contoso forest. This will be the first connector to sync in AADConnect. This will have the lowest precedence as well, as with AADConnect, the lower the precedence designated number, the higher the priority.

When the additional user/account forest(s) is added, or the resource forest, these connectors run after the initial Contoso connector due to the default precedence set. From an external perspective, this doesn’t seem like much of a bit deal. AADConnect merges two matching or mirrored user objects by way of the (commonly used) objectSID and msExchMasterAccountSID and away we go. In theory, precedence shouldn’t really matter.

Give me more detail

The issue is that precedence does in deed matter when we go back to our Contoso and Fabrikam example. The reason that this does not work is indeed precedence. Here’s what happens:

2016-12-02-aadc-whathappens-01

  • #1 – Contoso is sync’ed to AADC first as it was the first forest connected to AADC
    • Adding in Fabrikam first over Contoso doesn’t work either
  • #2 – The Fabrikam forest is joined with a second forest connector
  • AADC is configured with user identities exist across multiple directories
  • objectSID and msExchMasterAccountSID is selected to merge identities
  • When the objects are merged, sAmAccountName is taken Contoso forest – #1
    • This happens for Contoso forest users AND Fabrikam forest users
  • When the objects are merged, mail or primarySMTPaddress is taken Contoso forest – #1
    • This happens for Contoso forest users AND Farikam forest users
  • Should the two objects not have a completely identical set of attributes, the attributes that are set are pulled
    • In this case, most of the user object details come from Fabrikam – #2
    • Attributes like the users firstname, lastname, employee ID, branch / office

The result is this standard setup is having Fabrikam users with their resource accounts in Contoso sync’ed, but, have their UPN set with the prefix from the Contoso forest. An example would be a UPN of user@contoso.com rather than the desired user@fabrikam.com. When this happens, there is no SSO as Windows Integrated Authentication in the Fabrikam forest does not recognise the Contoso forest UNP prefix of @contoso.com.

Yes, even with ADDS forest trusts configured correctly and UPN routing etc all working correctly, authentication just does not work. AADC uses the incorrect attributes and sync’s those to Azure AD.

Is there any other way around this?

I’ve touched on and referenced precedence a number of times in this blog post so far. The solution is indeed precedence. The issue that I had experienced was a lack of understanding of precedence in AADConnect. Sure it works on a connector rule level precedence which is set by AADConnect during the configuration process as forests are connected to.

Playing around with precedence was not something I want to do as I didn’t have enough Microsoft Identity Manager or Forefront Identity Manager background to really be certain of the outcome of the joining/merging process of user and resource account objects. I know that FIM/MIM has the option of attribute level precedence, which is what we really wanted here, so my thinking as that we needed FIM/MIM to do the job. Wrong!

In comes Nigel…

Nigel dissected the requirements over the course of a week. He reviewed the configuration in an existing FIM 2010 R2 deployment and found the requirements needed of AADConnect. Having got AADConnect setup, all that was required was tweaking a couple of the inbound rules and moving higher up the precedence order.

Below is the AADConnect Sync Rules editor output from the final configuration of AADConnect:

2016-12-01-syncrules-01

The solution centres around the main precedence rule, rule #1 for Fabrikam (red arrows pointing and yellow highlight) to be above the highest (and default) Contoso rule (originally #1). When this happened, AADConnect was able to pull the correct sAmAccountName and mail attributes from Fabrikam and keep all the other attributes associated with Exchange mailboxes from Contoso. Happy days!

Final words

Tinkering around with AADConnect shows just how powerful the “cut down FIM/MIM” application is. While AADConnect lacks the in-depth configuration and customisation that you find in FIM/MIM, it packs a lot in a small package! #Impressed

Cheers,

Lucian

Azure AD Connect – Using AuthoritativeNull in a Sync Rule

There is a feature in Azure AD Connect that became available in the November 2015 build 1.0.9125.0 (listed here), which has not had much fanfare but can certainly come in handy in tricky situations. I happened to be working on a project that required the DNS domain linked to an old Office 365 tenant to be removed so that it could be used in a new tenant. Although the old tenant was no long used for Exchange Online services, it held onto the domain in question, and Azure AD Connect was being used to synchronise objects between the on-premise Active Directory and Azure Active Directory.

Trying to remove the domain using the Office 365 Portal will reveal if there are any items that need to be remediated prior to removing the domain from the tenant, and for this customer it showed that there were many user and group objects that still had the domain used as the userPrincipalName value, and in the mail and proxyAddresses attribute values. The AuthoritativeNull literal could be used in this situation to blank out these values against user and groups (ie. Distribution Lists) so that the domain can be released. I’ll attempt to show the steps in a test environment, and bear with me as this is a lengthy blog.

Trying to remove the domain minnelli.net listed the items needing attention, as shown in the following screenshots:

This report showed that three actions are required to remove the domain values out of the attributes:

  • userPrincipalName
  • proxyAddresses
  • mail

userPrincipalName is simple to resolve by changing the value in the on-premise Active Directory using a different domain suffix, then synchronising the changes to Azure Active Directory so that the default onmicrosoft.com or another accepted domain is set.

Clearing the proxyAddresses and mail attribute values is possible using the AuthoritativeNull literal in Azure AD Connect. NOTE: You will need to assess the outcome of performing these steps depending on your scenario. For my customer, we were able to perform these steps without affecting other services required from the old Office 365 tenant.

Using the Synchronization Rules Editor, locate and edit the In from AD – User Common rule. Editing the out-of-the-box rules will display a message to suggest you create an editable copy of the rule and disable the original rule which is highly recommended, so click Yes.

The rule is cloned as shown below and we need to be mindful of the Precedence value which we will get to shortly.

Select Transformations and edit the proxyAddresses attribute, set the FlowType to Expression, and set the Source to AuthoritativeNull.

I recommend setting the Precedence value in the new cloned rule to be the same as the original rule, in this case value 104. Firstly edit the original rule to a value such as 1001, and you can also notice the original rule is already set to Disabled.

Set the cloned rule Precedence value to 104.

Prior to performing a Full Synchronization run profile to process the new logic, I prefer and recommend to perform a Preview by selecting a user affected and previewing a Full Synchronization change. As can be seen below, the proxyAddresses value will be deleted.

The same process would need to be done for the mail attribute.

Once the rules are set, launch the following PowerShell command to perform a Full Import/Full Synchronization cycle in Azure AD Connect:

  • Start-ADSyncSyncCycle -PolicyType Initial

Once the cycle is completed, attempt to remove the domain again to check if any other items need remediation, or you might see a successful domain removal. I’ve seen it take upto 30 minutes or so before being able to remove the domain if all remediation tasks have been completed.

There will be other scenarios where using the AuthoritativeNull literal in a Sync Rule will come in handy. What others can you think of? Leave a description in the comments.

Completing an Exchange Online Hybrid individual MoveRequest for a mailbox in a migration batch

I can’t remember for certain, however, I would say since at least Exchange Server 2010 Hybrid, there was always the ability to complete a MoveRequest from on-premises to Exchange Online manually (via PowerShell) for a mailbox that was a within a migration batch. It’s really important for all customers to have this feature and something I have used on every enterprise migration to Exchange Online.

What are we trying to achive here?

With enterprise customers and the potential for thousands of mailboxes to move from on-premises to Exchange Online, business analyst’s get their “kind in a candy store” on and sift through data to come up with relationships between mailboxes so these mailboxes can be grouped together in migration batches for synchronised cutovers.

This is the tried and true method to ensure that not only business units, departments or teams cutover around the same timeframe, but, any specialised mailbox and shared mailbox relationships cutover. This then keeps business processes working nicely and with minimal disruption to users.

Sidebar – As of March 2016, it is now possible to have permissions to shared mailboxes cross organisations from cloud to on-premises, in hybrid deployments with Exchange Server 2013 or 2016 on-premises. Cloud mailboxes can access on-premises shared mailboxes which can streamline migrations where no all shared mailboxes need to be cutover with their full access users.

Reference: https://blogs.technet.microsoft.com/mconeill/2016/03/20/shared-mailboxes-in-exchange-hybrid-now-work-cross-premises/

How can we achieve this?

In the past and from what I had been doing for, what I feel is, the last 4 years, required one or two PowerShell cmdlets. The main reference that I’ve recently gone to is Paul Cunningham’s ExchangeServerPro blog post that conveniently is also the main Google search result. The two lines of PowerShell are as follows:

Step 1 – Change the Suspend When Ready to Complete switch to $false or turn it off

Get-MoveRequest mailbox@domain.com | Set-MoveRequest -SuspendWhenReadyToComplete:$false

Step 2 – Resume the move request to complete the cutover of the mailbox

Get-MoveRequest mailbox@domain.com | Resume-MoveRequest

Often I don’t even do step 1 mentioned above. I just resumed the move request. It all worked and go me the result I was after. This was across various migration projects with both Exchange Server 2010 and Exchange Server 2013 on-premises.

Things changed recently!?!? I’ve been working with a customer on their transition to Exchange Online for the last month and we’re now up to moving a pilot set of mailboxes to the cloud. Things were going great, as expected, nothing out of the ordinary. That is, until I wanted to cutover one initial mailbox in our first migration batch.

Why didn’t this work?

It’s been a few months, three quarters of a year, since I’ve done an Office 365 Exchange Online mail migration. I did the trusted Google and found Paul’s blog post. Had that “oh yeah, thats it” moment and remembered the PowerShell cmdlet’s. Our pilot user was cutover! Wrong..

The mailbox went from a status of “synced” to “incrementalsync” and back to “synced” with no success. I ran through the PowerShell again. No buono. Here’s a screen grab of what I was seeing.

SERIOUS FACE > Some names and identifying details have been changed to protect the privacy of individuals

And yes, that is my PowerShell colour theme. I have to get my “1337 h4x0r” going and make it green and stuff.

I see where this is going. There’s a work around. So Lucian, hurry up and tell me!

Yes, dear reader, you would be right. After a bit of back and forth with Microsoft, there is indeed a solution. It still involves two PowerShell cmdlet’s, but, there is two additional properties. One of those properties is actually hidden: -preventCompletion. The other property is a date and time value normally represented like: “28/11/2016 12:00:00 PM”.

Lets cut to the chase; here’s the two cmdlets”

Get-MoveRequest -Identity mailbox@domain.com | Set-MoveRequest -SuspendWhenReadyToComplete:$false -preventCompletion:$false -CompleteAfter 5
Get-MoveRequest -Identity mailbox@domain.com | Resume-MoveRequest

After running that, the mailbox, along with another four to be sure it worked, had all successfully cutover to Exchange Online. My -CompleteAfter value of “5” was meant to be 5 minutes. I would say that could be set with the correct date and time format and have the current date and time + 5minutes added to do it correctly. For me, it worked with the above PowerShell.

Final words

I know it’s been sometime since I moved mailboxes from on-premises to the cloud, however, it’s like riding a bike: you never forget. In this case, I knew the option was there to do it. I pestered Office 365 support for two days. I hope the awesome people there don’t hate me for it. Although, in the long run, it’s good that I did as figuring this out and using this method of manual mailbox cutover for sync’ed migration batches is crucial to any transition to the cloud.

Enjoy!

Lucian

Exchange Deployment in the Cloud

A little Introduction

Some organisations, would still prefer hosting their own Exchange server(s), rather than migrating to Office 365. And since the Cloud is the way to go for many organisations, deploying an Exchange server in the Cloud, be it Azure or AWS, could be challenging on so many levels. This includes latency, failovers, data disk corruption, replication and so forth.

If you’re unsure on how to start, unfortunately Azure does not provide a free test drive for Exchange server (as of this writing). Fortunately however, a free test drive of Exchange 2013 is available in AWS (excluded from the blog). Nevertheless, Microsoft does provide a guide for deploying a test/dev Exchange 2016 in Azure found here .

Also, this blog will not go into details on server (hardware) requirements and step-by-step Exchange Installation. This blog assumes you have knowledge of either Azure or AWS, and Microsoft Exchange.

Note that previously Exchange server was not supported in Azure, but this is no more as Microsoft now supports the platform if deployed in Azure.

Deployment of Exchange 2016 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability requirements are met. In the case of providers who are provisioning virtual machines, these requirements include ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure to be utilized by Exchange meets the performance requirements that were determined during the sizing process. Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.

You can read more about it here and here .

Exchange in the Cloud

Assuming one Exchange Server 2013 will be deployed in Azure, the only supported way to send email to external domains from Azure compute resources is through an SMTP relay (otherwise known as an SMTP smart host). The Azure compute resource sends the email message to the SMTP relay, and then the SMTP relay provider delivers the message to the external domain. Microsoft Exchange Online Protection is one provider of a SMTP relay, but a number of third-party providers also offer this service.[1] Symantec Cloud is one service that provides SMTP relays, as detailed in the design below.

[1] https://blogs.msdn.microsoft.com/mast/2016/04/04/sending-e-mail-from-azure-compute-resource-to-external-domains/

exchange-server-2013-v1

As this blog is about Exchange in the Cloud (Azure), our focus will be on that. The above diagram takes into consideration a complete failover of the primary site. That is, the Azure Exchange server will be responsible for sending and receiving emails as well, should the primary site goes down.

Installing Exchange in the Cloud, be it Azure or AWS is fairly similar to that of on premise deployment. You can also successfully deploy DAG.

Exchange Deployment Consideration

There are many shapes of organisations, large organisations, mid-size organisations, enterprises, small organisations, start ups and so on. Why then should any of these organisations host an Exchange server in Azure? The short answer is that they shouldn’t.

In some rare scenarios, and temporary solution it might be advisable to host an Exchange server in Azure. These include if an organisation doesn’t have a secondary datacentre to host another platform for redundancy (or DAG in Exchange terms). In an other case if a company is planning to move to Office 365.

The only reasonable solution for hosting an Exchange server in Azure would be for setting up DAG, but this scenario applies on large organisations.

Exchange in Azure

The following considerations are required for an Exchange server deployment in Azure:

  1. Virtual Network
  2. Virtual machine (adhere to Exchange recommendation as per Microsoft’s best practice)
  3. Availability Set
  4. Public Load Balancer
  5. Network Security Group
  6. Smart host

And don’t forget about your witness server, depending on your environment.

The trickiest part in this deployment however lies within the load balancer, whether on premise or in Azure. You could use Azure Load Balancer for your Azure deployed Exchange server, or get KEMP LoadMaster found in the Azure Marketplace (my personal recommendation, although more costly), this would even allow you to also load balance between Azure and external network. While Azure Load Balancer can only load balance in the same VNet region.

There are many articles out there discussing topics on Exchange in Azure, however I would recommend checking Microsoft’s own Exchange on IaaS: Concerns, Tradeoffs, and Best Practices here .

Conclusion

Should an organisation really have Exchange on IaaS? It really depends on the company and requirements. The best solution however, is to have a hybrid deployment (Exchange/Office 365), or an ideal solution is to completely move to Office 365.

I hope you found this informative. Please add your comments below.

Thank you for reading.

Auto-Acceleration for SharePoint Online

Working with one of my colleagues recently, we were tasked with implementing Smart Links to speed up the login processes for a client’s SharePoint Online implementation.

The client was working towards replacing their on-premises implementation of SharePoint and OpenSpaces with SharePoint Online. The issue they faced was that when when a user tries to access a SharePoint Online site collection and is not already authenticated with Office 365, the user will be directed to the default Microsoft Online login page. The user then provides their email address and something called home-realm discovery is performed. This is where the Microsoft Online login screen will use the domain portion of the users email address to determine whether the domain is managed by Office 365, in which case the user will need to provide a password. If the domain is Federated (i.e. not managed by Office 365), the user is re-directed to the Identity Provider (IdP) for the user’s organisation – i.e. AD FS. At this point providing internet security settings within the user’s web browser are correct, they will be authenticated using their logged in credentials. Although this is the default SharePoint Online experience, it was different to the seamless on-premises SharePoint experience with Windows Integrated Authentication.

After spending a little time working through David Ross’ great blog on the topic, we discovered that due to a change in the URL construct with AD FS 3.0, the Smart Link process is no longer supported by Microsoft and has been replaced with Auto-Acceleration for SharePoint Online. This feature reduces logon prompts for the user by instructing SharePoint Online to use a pre-defined home-realm, rather than perform home-realm discovery, when a user accesses the site and “accelerating” the user through the logon process.

However, there are two caveats for getting Auto-Acceleration to work:

  • You can have multiple domains but there must be a single SSO end-point to authenticate users (AD FS or a 3rd party IdP such as Okta, can be used).
  • Auto-acceleration only works with sites that are accessible internally to the organisation, it will not work for external sites.

There isn’t much documentation around for this feature, however it’s pretty simple:

  1. If you haven’t already, download the SharePoint Online Management Shell https://www.microsoft.com/en-au/download/details.aspx?id=35588
  2. Connect to SharePoint Online using the SPO Management Shell:
    $adminUPN="[UPN for Office 365 Admin]"
    $orgName="[Your tenant name]"
    $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password."
    Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $userCredential 
  3. Type the command Set-SPOTenant –SignInAccelerationDomain “yourdomain.com”
  4. If your IdP supports guest users, you can also run Set-SPOTenant -EnableGuestSignInAcceleration $true
shane_fisher_kloud_telstraid

AAD Connect – Using Directory Extensions to add attributes to Azure AD

I was recently asked to consult on a project that was looking at the integration of Workday with Azure AD for Single Sign On. One of the requirements for the project, is that staff number be used as the NameID value for authentication.

This got me thinking as the staff number wasn’t represented in Azure AD at all at this point, and in order to use it, we will need to get it to Azure AD.

These days, this is fairly easy to achieve by using the “Directory Extensions” option in Azure AD Connect. Directory Extensions allows us to synchronise additional attributes from the on-premises environment to Azure AD.

Launch the AADC configuration utility and select “Customize synchronisation options”

aadc_config_p1

Enter your Azure AD global administrator credentials to connect to Azure AD.

aadc_config_p2

Once authenticated to Azure AD, click next through the options until we get to “Optional Features” and select “Directory extension attribute sync”

aadc_config_p3

There are two additional attributes that I want to make use of in Azure AD, employeeID and employeeNumber. As such, I have selected these attributes from the list.

aadc_config_p4

Completing the wizard will configure AAD Connect to sync the requested attributes to Azure AD. A full synchronisation is required post configuration and can be launched either from the configuration wizard itself, or from powershell using the following cmdlet.

Start-ADSyncSyncCycle -PolicyType initial

Once the sync was complete, I went to validate that my new attributes were visible in Azure AD. They weren’t!

After some digging, I found that my attributes had in fact synced successfully, they just weren’t in the location I wanted them to be. My attributes had synced as follows:

Source AD                                                                    Azure AD

employeeNumber                                                         extension_tenantGUID_employeeNumber

employeeID                                                                    extension_tenantGUID_employeeID

 

So… This wasn’t exactly what I was looking for, but at least the theory works in practice.

Fortunately, this problem is also easy to fix. We can configure AAD Connect to synchronise to a different target attribute using the synchronisation rules editor.

When we configured Directory extensions above, a new rule was created in the synchronisation rules editor for “User Directory Extension”. If we edit this rule, we can see the source and target attributes as they are currently configured, and we are able to make changes to these rules.

Before making any changes, follow the received prompt guiding you not to change the existing rule, but instead clone the current rule and then edit the clone. The original rule will be disabled during the cloning process.

As seen below, I have now configured the employeeNumber and employeeID attributes to sync to extensionattribute5 and 6 respectively.

aadc_config_p6

A full synchronisation is required before the above changes will take effect. We are now in a position to configure Single Sign On settings in Azure AD, using extensionAttribute5 as the NameID value.

I hope this helps some of you out there.

Cheers,

Shane.

Skype for Business Mac Client – General Availability

I currently run a MacBook Pro for my daily driver, it’s the ‘spice of life’ I say! A MacBook Pro, a Google Pixel phone and the Microsoft Office 365 collaboration suite is what makes up my toolset. Now more then ever collaboration and data is becoming more accessible via a device flavour that you prefer. Running Mac OSX while working with the Microsoft stack presents two issues I’ve had to endure to this point as an end user and adminstrator:

  1. I want to leverage the full capability of Kloud’s Skype for Business platform while in OSX
  2. I want to execute PowerShell CLI natively in OSX

I’ve marked October 26th in my calendar as the day where I get to put a line through one of my wish list items. Skype for Business Mac client has become generally available and free to download here. I noticed while I can download the client from Microsoft.com, I’m yet to have it available to me in the Office 365 portal where I’m still offered my very old friend Lync 2011 to install.

This software isn’t all that new to me personally, I’ve been on versions of the preview client for a while now with mixed emotions. That being said, that’s what a preview program is all about! For those wondering what you will get with this first release (16.0.0.3638) here is a closer look.

Installation

The installation package will ask you to shutdown Safari and once you have hit ‘next‘  or ‘continue‘ the correct amount of times you will be presented with the login splash screen.

office-mac-2

Once you have logged in successfully with your credentials you will receive the ‘run-once‘ welcome wizard. Which probably gives away most of the capability you will have so I won’t double up.

It’s not my intention to turn this into one of those ‘unboxing videos‘ you see on youtube, but here are some key features that I feel you will need to know about since either using the preview or being a first time consumer of Skype for Business on Mac.

All the normal and expected features are here:

  • Instant Message
  • Tabbed Conversations
  • Audio Call
  • Video Call
  • Multi-Party Instant Message, Audio and Video
  • Share Desktops
  • Join Meetings
  • Dial PSTN Numbers
  • Receive PSTN Calls
  • Listen to Voicemails
  • View conversation, IM and call history

Preview to General Availability

Voice users, you get the very important advanced calling options in preferences which wasn’t in the preview. This includes:

  • Call Forwarding Behaviour
  • Dialin Conferencing Pin/Settings Link
  • Voicemail Greeting Option

office-mac-pref-calls

A dial pad and/or a field to paste a number prior to dialling in the GUI was missing, not any more:

office-mac-dialpad

When you click to join a Skype for Business meeting from a URL in a calendar item you will be prompted to trust the ‘Skype for Business Meeting Join Plug-in‘ allowing native meeting join into the Skype for Business application from a Hyperlink:

office-mac-meeting-plugin

What things are missing? And,….will I really need them?

I’ll let you be the judge if these are things that you just can’t live without. Here’s a few notable mentions I can see:

  1. Team Call / Delegates options (was available in Lync 2011)
  2. Audio Test Call Service
  3. Ability to share desktop while in 1-1 window (was available in Lync 2011)
    1. Workaround: You must ‘Meet Now’ and invite the user, desktop share is then available
  4. Ability to send files in 1-1 or meeting windows (was available in Lync 2011)
  5. Unanswered call delay and procedure options (Call timer and forward)
  6. Meeting Recording settings

Final thoughts

At the end of the day if its stable, its a win. The preview was problematic for me, with breaks in network connection and re-connection being my main issue. Microsoft have advised that there is server cumulative updates to install to the backend for best compatibility which could aid experience. From a client perspective they advise that you uninstall all previous clients (Lync 2011 or Skype for Business Preview). All these ‘need to know‘ fine print can be found in the ‘Details‘ section of the client download.

Happy downloading.