Category Archives: Office 365 Grid

Guidelines for Office 365 User Provisioning and De-provisioning Processes – The Lost Documentation

BACKGROUND AND PURPOSE

Introducing Office 365 and Azure AD in an Enterprise environment always raises the question around how object provisioning-, de-provisioning- and organizational change-processes will be affected. These are three common concerns and questions that I get from Enterprise customers in the planning phase of an Office 365 onboarding project:

  1. The customer is using an identity management (IDM/IAM) solution for provisioning accounts, and want’s to better understand how Office 365 / Azure AD will affect that landscape.
  2. The customer have special de-provisioning routines for retaining user data (i.e. keeping the mailbox and home folder data etc.), and needs to know how these processes should be updated when Office 365 is introduced.
  3. The customer understands the provisioning and de-provisioning processes, but want’s to automate them as much as possible.

The purpose of this article is to provide guidelines on how to approach this topic. Please note that these guidelines are intended for large Enterprises that seeks a high level of automation in these processes. Small-/medium-sized organizations with a lower number of employee attrition and/or organizational changes per week/month does not always have to implement automation processes for provisioning/de-provisioning/org changes.

As always with the “Lost Documentation” articles, most of this information is available from Microsoft, scattered over various TechNet- and MSDN-articles – this is my attempt to assemble the information in one place, to assist fellow Solution Architects, system administrators and project managers in the journey to Office 365.

PROVISIONING A USER FOR OFFICE 365 – WHAT COULD POSSIBLY GO WRONG?

Implementing user provisioning processes in Office 365 is generally very easy and straight-forward. Many often think that if you have complex provisioning processes in place today, you will have a hard time make it work for Azure AD / Office 365. This is almost never the truth, as the provisioning processes for Azure AD / Office 365 is “put on top” of what you already have. You kan keep provisioning users based on data from your HR system, and assign them roles based on data in a payroll system, or whatever it is that you are doing – as long as the user is created in Active Directory – it will be provisioned in Azure AD / Office 365 through a separate appliance-like synchronization engine (AAD Connect) without you having to change anything in the current provisioning routines. However, some processes will require updates – i.e mailbox provisioning in Exchange – and you will also be required to assign an Office 365 license to your users before they can use any of the services. The higher ambition you have for automation around these processes, the more challenging this topic will be for you – simply because automation is handled differently by every customer so there is no general answer to how it is achieved.

Below is guidelines for approaching provisioning automation, which can help you update your own routines and processes.

GUIDELINE #1: KNOW YOUR USER PROFILES BETTER THAN EVER BEFORE

The nature of SaaS: Office 365 is a subscription-based service, sold and consumed in a SaaS-model. Each user has assigned services in Microsoft’s data-center, with associated SLAs. A fundamental aspect of this delivery model is that each user must have an assigned license to be able to consume the service. A challenge for large Enterprise customers is that they are used to the traditional ways of purchasing Microsoft licenses (not services), which required a yearly inventory (“true-up”) of how many users were having Office applications, Exchange mailboxes, Skype for Business/Lync profiles, access to SharePoint etc. – and all you had to do as a customer was to share this updated figure with Microsoft – pay accordingly – and continue to use the services.

There have never before been any “enforcement method” that makes Office, Exchange, Skype for Business or SharePoint stop working if you are using more licenses that you have accounted for in your “true-up” – everything has just worked and it has been very much up to your own customer loyalty to make sure that you actually have payed for every user that you have provided with Microsoft software – such as Exchange mailboxes, Office applications, Skype for Business/Lync profiles and access to SharePoint Sites. And of course, this would include all your employees, but also any external user, like consultants getting Exchange mailboxes so that they could send and receive e-mail with your domain.

Don’t under-estimate the task: With Office 365 in place, the reality is changed. Users that are not assigned a license does not get access to any services (can’t activate the Office applications, no mailbox access in Exchange Online, no OneDrive for Business, no access to SharePoint Sites etc.). There is no “grace period” – you will need to have the right number of licenses reserved from your Enterprise Agreement through the VLSC Portal, and these licenses need to be assigned to a user (activated on that user’s account – read more later in this article) in order for that user to be able to use the services. This fact will require you to both know exactly how many users you are providing with Office 365 services, and if you are providing more than one license plan (SKU), i.e you have purchased a mix of E1, E3, E5 and K plans – you will need to know exactly what individuals should be mapped to exactly what license plan.

The task of mapping each user to a user profile (license SKU) is often extremely under-estimated. It is important to understand the consequences of not having the user profile mapping completed before commencing the Office 365 onboarding project. The consequence includes:

  1. The onboarding project will be stalled, as licenses will either run out, or the technical team doing the onboarding will at a certain point in time need to know what licenses to assign for each user, as all users are onboarded.
  2. The business case for moving to Office 365 will be impacted. Let’s say you invested in 50 000 E3 licenses, because that was the amount of Office ProPlus licenses you bought in the traditional license model. As it then turns out, you were actually providing these services for 55 000 users, you just had not calculated for all the external people who you have provided with IT-tools. This would mean an additional cost of 10% over your initial Office 365 investment.
  3. Users would get insufficient or wrong services assigned. Imagine if you assign E1 licenses to a department of 5000 users where you deploy Office 365 ProPlus – no one would be able to activate their Office applications, and your support organization would have to take the hit. Another consequence of getting the wrong services assigned is that you pay an extreme over-price for a user getting more services than he or she ever would actually use.

So before you dig deeper into the technology around provisioning, it is recommended that you map each and every user account in your organization to a user profile, which also translates to a license SKU.

Clean-up: Also note that accounts (i.e. Active Directory users with or without Exchange mailboxes) that are not actively used cannot be provisioned without an active license, which means that if you have licenses for 50 000 users, but you have 60 000 mailboxes in Exchange, where 5000 are Shared Mailboxes and Equipment/Room Mailboxes (these are free in Office 365 / Exchange Online), you have an overhead of 5000 user mailboxes which will need to either be removed or to acquire a license. Cleaning up your Active Directory and Exchange Server from inactive user objects and mailboxes before Office 365 onboarding is as important as the user profiling work itself.

GUIDELINE #2: UNDERSTAND IDENTITY/USER PROVISIONING AND LICENSING

Identity Bridge: The recommended way for Enterprise customers to provision users, groups and contact objects in Azure AD / Office 365 is by extending your on-premises Active Directory to the cloud through an appliance-like synchronization tool called Azure AD Connect (AAD Connect). The tool was previously known as DirSync and AADSync, and there was also a standalone FIM / MIM Management Agent – all these three still works, but future development will only be done in AAD Connect, which makes that the best choice for every organization today, regardless of complexity and identity landscape in general. Hand-in-hand with identity synchronization for provisioning and administration, a security token service (like ADFS) is usually implemented to provide single sign-on to Office 365 – this however has actually nothing to do with provisioning, why it will not be mentioned more in the article.

Sync: With AAD Connect in place, the on-premises Active Directory will be replicated to the Azure AD / Office 365 every 30 minutes. All your users, groups and contact objects will be provisioned in Azure AD / Office 365, but no Office 365 services are assigned to any users until you assign a licenses yourself as an admin. AAD Connect makes sure that you keep administrating your identities the same way you are today, and that you won’t have to maintain multiple identities (on the ground and in the cloud). It also makes sure that what ever identity provisioning routines you have in place today will continue to work as before, as long as they provision identities in Active Directory, AAD Connect will do the rest on top of what you already have.

Beware of 3rd-party or self-made sync: It is not recommended to replace AAD Connect with a 3rd party or self-developed synchronization / provisioning script (i.e. PowerShell / REST API provisioning). The main reason is that it will not be supported for all complex scenarios (such as Exchange Hybrid Configuration, attribute write-back scenarios, etc.). There is a AAD Federation Compatibility List (previously known as the “Works With Office 365 Identity Program”) that lists 3rd party STS services compatibility towards federation with Azure AD / Office 365 – found here – however, not many are reading the top note on the page that says that the solutions listed are only tested for federation scenarios – synchronization and multi-factor authentication scenarios provided by 3rd party vendors are not supported by Microsoft.

Synced users needs licenses: When AAD Connect is in place and is replicating your Active Directory data to Azure AD / Office 365, you will need to license users in order to activate them for Office 365 service – such as being able to active Office 365 ProPlus or read content from SharePoint Online. Assigning licenses can be done manually via the Office 365 Admin Portal, but if you want to automate this for Office 365 licenses, you have to create your own solution as of now. The recommendation is to implement a PowerShell-script that assigns licenses based on Active Directory attributes or Security Group membership. This script can run as a Scheduled Task, for example on the same server that hosts AAD Connect. A good place to look if you want to automate user licensing with PowerShell is at this post by Office 365 MVP Johan Dahlbom (and in this post he explains how to do it with Azure Automation).

Two things before you sync: It is recommended that you inspect your Active Directory for directory quality errors before you automate your identity provisioning and administration with AAD Connect. Use the IdFix tool to run the inspection and then remediate all errors found. It is also recommended that you change your users UPN-names to match their primary SMTP-addresses before you sync. You don’t have to change the samAccountName, so users can keep logging in to Windows etc. the same way as before. The main reason to why you should change UPN-names to match SMTP-addresses is that users should know what username to use when accessing Office 365 in the mobile context (it has to be in the UPN-format). If you have contemplated Alternate Login ID as the solution for this, beware of the limitations (great article here by Joe Palarchio) – I generally do not recommend using it.

GUIDELINE #3: UNDERSTAND MAILBOX PROVISIONING – DURING AND AFTER COEXISTENCE

With our user profiling, AD/Exchange clean-up, identity bridge and automated licensing in place, we are ready to look at process updates required for provisioning Exchange mailboxes.

Different ways depending on if you do hybrid or not: If you have established an Exchange Hybrid Configuration, you will provision mailboxes as an administrative task much like you have done before, until the last Exchange Server and the hybrid configuration is fully decommissioned. If you are not in a hybrid configuration, you will provision mailboxes simply by assigning a license for Exchange Online to one of your users. Let’s break down the rationales and guidelines:

As long as you are in an Exchange Hybrid Configuration with at least one Exchange Server still running on-premises, you can provision new mailboxes directly in Exchange Online by creating new “Remote Mailboxes”. A Remote Mailbox is a mailbox in Exchange Online that you can see and manage from your Exchange Server administration tools. You can of course create Remote Mailboxes from your Exchange administration tools (GUI), but for automation purposes it is recommended to use PowerShell. For updating your mailbox provisioning routines to create remote mailboxes in Exchange Online while you still have Exchange Server on-premises, study and use the PowerShell cmdlets for provisioning new Remote Mailboxes. Here are some examples:

To create a new Remote Mailbox for an Active Directory Mail User that you have provisioned on-premises, synced to Azure AD and assigned an Office 365 license (the most common scenario), run the following command in the Exchange Management Shell:

Enable-RemoteMailbox -Identity <UPN-name> -RemoteRoutingAddress <USERALIAS>@<TENANTNAME>.mail.onmicrosoft.com

To create a new user in the on-premises AD and a new Remote Mailbox that will be enabled when the new user is synced by AAD Connect (a fairly common scenario), run the following command in the Exchange Management Shell, and then license the user:

New-RemoteMailbox -UserPrincipalName user@domain.com -Name “Display Name” -OnPremisesOrganizationalUnit OU=Users,DC=addsdomain,DC=com -Password (ConvertTo-SecureString -AsPlainText “Pa$$word” -Force)

To create a new Shared Mailbox directly in Azure AD / Exchange Online as a Cloud ID (without any corresponding AD-user on-premises), run the following command in PowerShell, after connecting to Exchange Online:

New-Mailbox -Shared -Name <UPN-name> -PrimarySmtpAddress <User>@<DOMAIN>.com

(If you want the Shared-/Room-/Equipment Mailboxes to be represented in the on-premises AD, you will need to provision them as User Mailboxes first and convert them to shared mailboxes afterwards and remove the licenses – Shared-/Room-/Equipment mailboxes does not require a license once they are provisioned as such).

If you are not in an Exchange Hybrid Configuration, you provision mailboxes simply by assigning users with the correct attributes and an Office 365 license (that includes Exchange Online). The attributes that must be populated before you sync and license the users are: proxyAddresses (should include all necessary SMTP- and SIP-addresses), mail (should be populated with the primary SMTP-address), UPN (should preferably match the primary SMTP-address), Display Name (as you want it to appear in the Global Address List). The same process goes for Distribution Groups – you provision them in the on-premises AD with these attributes (minus UPN) populated, and then let AAD Connect synchronize them to Azure AD / Exchange Online.

About administration of Exchange Online: When AD synchronization with AAD Connect is enabled, most attributes are owned by AD on-premises, and you will therefore not be able to fully administer Exchange Online from the web-based administration portal (Exchange Control Panel). Some Exchange-attributes (such as proxyAddresses) simply must be administered in the on-premises AD and be synchronized to Azure AD / Exchange Online for the change to have effect. Because of this, it is worth noting that if you are decommission all Exchange Servers on-premises, you might need to build in more Exchange administration to your IDM / IAM provisioning and self-service tools than what you had before. End-users that administer Distribution Groups in Outlook are also affected, as this will for the same reasons stop working after the users mailbox is moved to Exchange Online – self-service tools for Distribution Group/List management will be required.

GUIDELINE #4: UNDERSTAND SKYPE FOR BUSINESS (LYNC) ONLINE PROVISIONING

Skype for Business Online (formerly known as Lync Online) provisioning works in the following way:

  1. If you have Lync Server or Skype for Business Server on-premises, and have users provisioned there with active SIP-profiles, and you are using AAD Connect so sync your AD on-premises to Azure AD / Office 365, no provisioning will occur in Office 365 for the SIP-enabled users, regardless if you license these users for Skype for Business Online in Office 365.
  2. If you license SIP-enabled users for Skype for Business Online, and then remove the SIP-profile from Lync-/Skype for Business Server on-premises, users will be provisioned for Skype for Business Online at the next AAD Connect sync cycle (often referred to as a “cut-over move”).
  3. If you are leveraging a Lync-/Skype for Business hybrid configuration, users must be licensed for Skype for Business Online, and you can then move users from the on-premises pool to the online pool. When all users are moved, you can for the purpose of provisioning decide to keep or remove the on-premises Lync-/Skype for Business Server environment, and select another provisioning method from this list of guidelines.
  4. If you are not having Lync-/Skype for Business Server on-premises, you provision users for Skype for Business Online simply by assigning them an Office 365 license (with Skype for Business Online included). It is recommended that you in this case populate the proxyAddresses attribute in the on-premises AD with a SIP:-address that matches the primary SMTP address.

GUIDELINE #5: UPDATE YOUR PROCESSES FOR DE-PROVISIONING USERS

There are many different aspects of user de-provisioning, including return of licenses, removing permissions, store/hold user data, etc. By understanding the fundamentals of how Azure AD / Office 365 de-provisioning works, you will be able to update your current processes to work with Office 365. Here are the fundamentals you should know about:

  1. If you are disabling a user in the on-premises AD, you are disabling the user in Azure AD / Office 365, but the license is still active.
  2. If you are deleting a user from the on-premises AD, you are deleting the user in Azure AD / Office 365. When this happens, all data is soft-deleted for 30 days and the license is returned to the license pool. If you restore the user within these 30 days (restore the user in the on-premises AD and sync the user again), all data will be kept. If you don’t restore the user within 30 days, and have not applied any rules for data Hold, the data is lost.
  3. If you remove the license from a user in Office 365 (for example if you move the user to a OU for de-provisioned users, disable the account and strip it from it’s group memberships as your de-commissioning routine in the on-premises AD), all data is soft-deleted for 30 days. If you re-assign the license to the user within the 30 days, and have not applied any rules for data Hold, all data will be kept. If you don’t re-assign the license within 30 days, the data is lost.
  4. If the user is licensed when it is deleted and the Manager field is populated for that user in AD, the Manager will be notified and given access to the users OneDrive for Business site for 30 days through the Access Delegation mechanism, explained here. If you remove the license before actually deleting the user, the Access Delegation process will not be triggered.
  5. There are different ways to keep the data for more than 30 days after you have removed the license from a user. The general recommendation is to use the Hold capabilities, administered from the Office 365 Protection Center.

GUIDELINE #6: UPDATE YOUR PROCESSES FOR ORGANIZATIONAL CHANGES

When users go through a department change, country transfer or other forms of organizational change, there are often identity-related processes that goes with it. In Azure AD / Office 365, it is much like with the provisioning; you can keep doing what you did before and let AAD Connect handle all the provisioning aspects in Azure AD / Office 365 for you. There is however one concern regarding the UPN attribute that you should be aware of. Here are the fundamental guidelines for organizational changes:

  1. If the organizational change is resulting in attribute updates, or even changes of Organizational Units, in the on-premises AD – let AD Connect take care of updating this in Azure AD / Office 365 for you through the regular synchronization cycle.
  2. Beware of delays that can occur, such as generation of the Offline Address book used in Outlook that can make updates in the Global Address List need a day to show up to all users, or back-end replication to SharePoint Online to let all organizational attributes show the correct values.
  3. If the organizational change requires a change of the UPN-name and the user is licensed, you will need to manually give it a push in Azure AD in order for it to change, AAD Connect can not change UPN-names in Azure AD / Office 365 for licensed users. To manually fix the UPN-name for the licensed user, follow the steps outlined in Scenario 2 in this article. A summary of the steps: change the UPN-name in the on-premises AD, let AAD Connect run a sync cycle, then connect PowerShell to your Azure AD tenant and run this command in PowerShell:

Set-MsolUserPrincipalName -UserPrincipalName [CurrentUPN] -NewUserPrincipalName [NewUPN]

SUMMARY AND DISCLAIMER

All guidelines presented here are based on my field experience and are made available for your own interpretation to assist in updating provisioning/de-provisioning routines in the move to Office 365. I hope you will benefit from these guidelines, and that you will give me suggestions for more topics that would make this article more complete. I am always listening to feedback on Twitter. Thank you for reading.

Solving Problems Accessing the Microsoft Intune Admin Console on IE11 (Silverlight and ActiveX Filtering Errors)

BACKGROUND

Consider the following scenario:

  1. You have successfully activated EMS or Microsoft Intune license SKUs to your Azure AD Subscription and to your admin account.
  2. You can successfully access and use the Microsoft Intune Account Portal (https://account.manage.microsoft.com/)
  3. When attempting to access the Microsoft Intune Admin Console (https://admin.manage.microsoft.com/) using your admin account and IE11, the Dashboard is never presented – instead you get stuck on a blue spinning circle that never disappears (see picture 1), or you get a message saying “This application requires Microsoft Silverlight.” even if Silverlight is already installed on the machine (see picture 2).
  4. When getting the second symptom, a link is provided to “Get Microsoft Silverlight”. When attempting to install Silverlight from the provided link, you get a message saying that “The same version of Silverlight is already installed”.

Spinning circle

This application requires Microsoft Silverlightintunesl3

CAUSE

The first symptom (the spinning blue circle that never disappears) may be related to ActiveX Filtering. Disabling it ( Gear Icon or Tools / Safety / ActiveX Filtering) should make the Dashboard load – or present the second symptom.

The second symptom (Dashboard does not load but instead say that the machine is missing Microsoft Silverlight even if it is installed) is related to a faulty procedure to detect Silverlight within Microsoft Intune.

The third symptom (Silverlight installation fails if you follow the link to download and install Silverlight from the message presented as part of symptom #2) is expected, as there is not a problem with your Silverlight installation – the message appears due to an issue related to Microsoft Intune and how it detects Silverlight on the machine.

RESOLUTION

Follow these steps to be able to access the Microsoft Intune Admin Console using IE11:

  1. Open Internet Explorer 11 and navigate to https://admin.manage.microsoft.com/
  2. If you get Symptom 1 (Spinning Circle), click the Gear Icon and click Safety \ ActiveX Filtering. Reload the page. This should either load the Dashboard or produce Symptom 2.
  3. If you get Symptom 2 (Message that Silverlight is not installed on the machine when it actually is), close all instances of Internet Explorer and navigate to Windows Control Panel \ Programs and Features and uninstall Microsoft Silverlight.
  4. After the uninstallation of  Microsoft Silverlight finishes, open Internet Explorer and navigate back to https://admin.manage.microsoft.com/. This time, follow the link “Get Microsoft Silverlight”, download and run the linked file and complete the installation wizard.
  5. Close all instances of Internet Explorer and start it again, navigate back to https://admin.manage.microsoft.com/. The Dashboard should now load, but if it still does not and Symptom 1 or Symptom 2 appears even this time, click the Gear Icon and click Safety \ ActiveX Filtering, then reload the page. The Dashboard will load.

Microsoft Intune Admin Console Dashboard

Hands on with AADSync (RTM) / AAD Connect – a Guide to Multi-Forest AD Synchronization and Attribute Filtering

ARTICLE UPDATED JUNE 2015 TO INCLUDE AAD CONNECT (NEW NAME, VERSION AND BUNDLING FOR AADSYNC).

INTRODUCTION

Office 365 is in many aspects best compatible with an on-premise infrastructure where the customer have followed Microsoft’s guidelines and best practices for design and configuration. A perfect example of such guideline is to keep all Active Directory user data associated with employees (personal user objects) within a single Active Directory forest. For many organizations, this is not the reality, often due to a background of growth by acquisitions where the acquired organisation remain their Active Directory data in their own forest that they always have been using. Such landscape is referred to as a “Multi-forest scenario” (one organization with users are spread across many Active Directory forests).

The aspect that makes the multi-forest scenario problematic is the user provisioning and administration. For single-forest customers (the number of domains within the forest does not matter), it have always been easy to deploy Directory Synchronization from your Windows Server AD forest to Azure AD by using DirSync – but that method have not been supporting the multi-forest scenario (DirSync supports single-forest synchronization only). Different alternatives have since the launch of Office 365 become available to address directory synchronization in the Multi-forest scenario (like the FIM AAD Connector), and there are still different ways to go at it – but now, better native support for this scenario is becoming a reality with the new Azure Active Directory Connect (AAD Connect) that previously was available as AAD Sync (AAD Connect is the new name, version and bundling for AAD Sync). This article will provide an overview of the alternative methods, and a detailed step-by-step guide on how to configure multi-forest synchronization from two separate Active Directory forests to one single Azure AD/Office 365 tenant. We will also look in to the feature of Attribute Filtering within AAD Connect to demonstrate how selected AD attributes can be skipped in the synchronization (please note that filtering out attributes is now possible but not generally recommended, I will explain why later in the article).

MASTERING THE MULTI-FOREST SCENARIO – OPTIONS OVERVIEW (OR “READ THIS FIRST”)

If you are considering Office 365 (or other AAD integrated applications) and multiple Active Directory forests is your reality, consider the options below. Option D will later in the article be explained in detail. There is no preferred order or priority for the given options.

OPTION A – CONSOLIDATE THE FORESTS FIRST: If Active Directory consolidation (merging the forests in to one) is an option, that activity could be completed prior to adopting Azure AD/Office 365 to avoid the multi-forest scenario complexity. The objects that needs to be consolidated to one forest are the user objects for the employees and groups that relate to any of the Office 365 services (i.e distribution lists and mailbox security groups). Computer objects and service accounts etc can still remain in the trusted forest when activating AAD/Office 365 services.

OPTION B – MIX SYNCED IDs WITH CLOUD IDs: If the majority of users resides in one AD forest, and a limited number of users are in a separate forests, a good option can be to implement AD integration (AADSync, ADFS) to the primary forest, but create Cloud ID (separate identities in Azure AD) for the users that are in the separate forests. This creates a mix of integrated and separate identities in the same tenant. If you are using ADFS in the primary forest, keep in mind that users in the other forests (that get’s the Cloud IDs) can not have the same domain in their username, because federation is activated per domain (if domain1.com is activated for federation, domain1.com users can not use Cloud IDs with user@domain1.com usernames, they would have to use another domain for their usernames).

OPTION C – USE SHADOW ACCOUNTS: This option is similar to Option B, but with the ability to centrally manage all identities. Instead of creating Cloud IDs for the users residing in the separate forest(s), create corresponding user objects (“shadow accounts”) in the primary AD forest for those users instead, and let AAD Connect provision these accounts in AAD/Office 365. These “shadow accounts” allows the users in the separate forest(s) to login with a centrally managed account, but they will not have Single Sign-on with ADFS as they are not logging in to Windows with the same account as they are using for AAD/Office 365. This option allows ADFS Claim rules, centrally managed password policies and other benefits that comes with proper Active Directory integration – but have considerations regarding end-user experience for the shadow users (there is a separate password associated with the shadow account, etc).

OPTION D – SYNCHRONIZE ALL FORESTS WITH AAD CONNECT: The final option is to actually enable multi-forest synchronization. This can be accomplished either by using the AAD Connector in FIM that still is available (but should not be used as it will not be developed further), or by using AAD Connect. It is recommended to use AAD Connect, as the FIM agent (as well as DirSync) is believed to be deprecated over time and replaced with AADSync completely. AAD Connect works like DirSync always have, but have native support for connecting with multiple Active Directory forests. How to implement and configure this option is explained in detail below.

IMPLEMENTING MULTI-FOREST SYNC WITH AAD CONNECT – SCENARIO OVERVIEW

I will now explain how to configure multi-forest synchronization step by step by step. The screen shots are collected from AADSync, but from June 25 2015, you should downlad and use AAD Connect to configure multi-forest – the wizard in the screenshots matches the one in AAD Connect for the AAD Sync steps. Before jumping in to configuration, let’s have a look at the given scenario.

SOURCE: Two separate AD Forests containing users – FOREST-A.int and FOREST-B.int
TARGET: One Azure AD/Office 365 tenant.
METHOD: We will configure AAD Connect (AAD Sync used in the screen shots) to synchronize objects from both forests to the tenant. We will also configure AADSync to filter out the ipPhone, homePhone and extensionAttribute9 AD attributes from the synchronization.

Overview. Users from FOREST-A and FOREST-B will be syncrhonized to Azure AD.

Overview of users in FOREST-A

Overview of users in FOREST-A

Overview of users in FOREST-B.

Overview of users in FOREST-B.

CONFIGURING MULTI-FOREST DIRECTORY SYNCHRONIZATION STEP-BY-STEP

Pre-requisites:

  1. You have an AAD/Office 365 tenant
  2. You have activated all your smtp-domains that are used in the organization (both forests) in your tenant.
  3. Your users have either or both their UPN-name and mail-attribute in Active Directory populated to match their primary smtp-address.
  4. You have one machine available to install AADSync (can be joined to any of the forests). The machine can access domain controllers in both forests and is able to resolve both forest DNS names.
  5. You have user account credentials to read both AD Forests, and you have a Global Administrator account to write to your Azure AD.
  6. The total number of objects that you will syncrhonize is not more than 100 000 (would require a full SQL setup which is not covered in this guide). The limit for full SQL setup was 50 000 in DirSync, but is now lifted to 100 000 for AAD Connect.

Make sure you meet all pre-requisites above. Then, let’s get started.

  1. The first step is to activate Active Directory Synchronization in your tenant. Do so by logging in to the admin portal, browse to users and follow the link at the top for setting up AD Synchronization.

    1activatedirsync

    Navigate to Users in your admin portal and follow the highlighted link to set up AD Synchronization. Notice in the screenshot that there are only two users (Cloud IDs) present in the tenant as of now.

  2. Click Activate to enable AD Synchronization in your tenant.
    2activatedirsync
  3. Download AAD Connect to the server where you want to install the tool. Get it here.
  4. Launch the installer executable (MicrosoftAzureADConnectionTool.exe).
    5launch_aads
  5. The installer let’s you choose the installation path and accept license terms. Click Install to continue.
    6wizard_Start
  6. The necessary components are now installed to the server (Sign-in Assistant, SQL LocalDB, SQL Native Client, the actual Sync Service etc). After the component installation, the wizard interface may disappear completely for about 30 seconds, but it will come back when it have finished loading the configuration wizard.
  7. The first step in the configuration wizard is to connect to your Azure AD. Enter the credentials for a Global Administrator in the tenant and hit Next to continue.
    7wizard1
  8. Next, enter credentials for the first forest you want to synchronize. Start by adding the forest to which you have joined the AADSync server (in this case this is FOREST-A). Hit Add Forest to verify the connectivity and credentials, and to add the next forest.
    8wizard2
  9. Add the next forest. Notice that I use the forest FQDN to specify the domain in the Username field (FOREST-B.int\jesper). I recommend this when adding the external forests to avoid an error that states “The specified domain does not exist or cannot be contacted.”, which may occur if only using the NetBIOS name (FOREST-B\jesper).
    9wizard3
  10. When both forests are added to the list, hit Next to continue.
    10wizard4
  11. The next option screen in the wizard covers settings for user matching. These options require careful consideration if you are using GAL Sync (or for any other reason have users represented as User and/or Contact objects in both forests) and/or are planning for a future Active Directory consolidation/migration of the forests that you currently are configuring for AADSync. Read the following rationales for these options before proceeding:


    Matching across forests: If your user objects only occurs in their respective forest, and are not replicated as a contact object or duplicate account in the other forest, leave the “Matching across forests” option at its default – “Your users are only represented once across all forests”. If objects are represented in many forests, you must make a selection for an attributed that can be used as a matching attribute to merge/join the duplicates to one Azure AD identity, or you will have collisions during the synchronization. More information is available if you follow the “Learn more about user matching” link in the wizard.

    Matching with Azure AD
    : These two options are used for identity federation. The sourceAnchor attribute is the immutable ID for the user, and must not be changed during the lifetime of a user object. The default choise – objectGUID – is a good choise IF YOU ARE NOT PLANNING AN ACTIVE DIRECTORY CONSOLIDATION OR MIGRATION IN THE FUTURE. The objectGUID attribute will change if the user is moved to another forest, and would in that case create a duplicate user in Azure AD (and a big mess to clean up). Use the objectGUID if you are certain that the affected user objects will remain in their current forest for their remaining lifetime. The userPrincipalName attribute is the attribute that will populate the Username in Azure AD (the corresponding UPN-name in AAD). Having users signing in to AAD/Office 365 with their primary smtp-address as their username is a best practice, so use the default – userPrincipalName – if attribute is matching the users smtp (email) addresses (or if you are planning them to do so). If your UPN names do not match the primary smtp-address and you are not planning on changing the UPNs to do so, consider using the mail-attribute instead (in that case, just remember to configure ADFS to use the same attribute by following these instructions).


    In summary: If your users are represented once across the forests (no GAL Sync or equal in place) and if your UPN-names are matching primary smtp-addresses, you can go ahead with the default options here, like I do in this example. Make your selection and hit Next to continue.
    11wizard5
  12. Next up are Optional features. At the time taking this screenshot, Password Synchronization was not available in AADSync (RTM version, build 1.0.0419.0911), but this is available now (from October 2014). Password write-back is also in its final stages of development and will soon be available to customers that have an Azure AD Premium subscription (not included in Office 365). The Exchange Hybrid option must be selected if you are planning to set up an Exchange Hybrid Configuration between one of your on-premise Exchange organizations and Exchange Online (multi-org Exchange hybrid is now supported, but was not from the beginning). I am selecting Exchange hybrid deployment and Azure AD app and attribute filtering to demonstrate the new capabilities to filter out attributes from AADSync. Please note that I do not recommend that you use app and attribute filtering (see explanation below under “Should I filter out apps…”), I am making the selection in this example to demonstrate the capability. Make your selection and hit Next to continue.
    11wizard6
  13. If you selected the “Azure AD app and attribute filtering” in the previous step (not generally recommended), you will now have the option to filter out Azure AD apps (Office 365 services etc). Filtering out apps and attributes is possible, but before you decide doing so, please read the following rationale:
    Should I filter out apps and/or attributes from the synchronization? My general answer to this question is “No”. There are in my opinion three main reasons why you shouldn’t.REASON A – NO SECRETS IN ACTIVE DIRECTORY: By default, all users can read all attributes (not the passwords) for all objects in Active Directory. If you want to filter out attributes because you have secret data stored in AD attributes, you are doing things very wrong. Any user can open any AD or LDAP administration tool (like Active Directory Users and Computers) and read and/or export all your directory data from any machine in the network. If you are allowing shared AD accounts (like POS/kiosk accounts), you will not have any chance to log or trace such export either. You should not store any secret data in Active Directory attributes (another Microsoft Best Practice), and therefore synchronizing attributes to AAD that any user can read anyway should not be imposing a security threat to your organization.     
    REASON B – KEEP IT SIMPLE, IT IS YOUR PRIVATE DATA: If you filter out apps/attributes in your synchronization, you are immediately configuring a “special setup” with a complexity parameter added to it. Your tenant and your Azure AD is your private data. You are not sharing it with Microsoft or anyone else. Keep your AAD synchronization solution as simple as possible, trust Office 365, and synchronize all attributes as recommended to avoid incompatibility (surprises) in the future as AAD/Office 365 develops.     
    REASON C – FUNCTIONALITY AND RICH USER EXPERIENCE:
    To allow the very best end-user experience, GlobalAddress Lists, Lync Contact Cards, SharePoint profile sites etc should all be populated with as much information possible. If you decide to filter out attributes, you will take away functionality and “rich content” from your end users. It is also worth mentioning that Microsoft services, such as Exchange and Lync, depend on Active Directory attributes for their functionality – so filtering out an attribute that is not technically needed today might cause an upcoming feature not to work in your environment in the future. In this example, we are filtering out three attributes, but we will leave attribute scopes for all apps intact in this option screen. Make your selection and hit Next to continue.
    12wizard7
  14. As we selected to use “Azure AD app and attribute filtering” previously, we now get the chance to filter out specific attributes (the previous options screen for apps let us filter out sets of attributes based on specific apps/services). To demonstrate the attribute filtering capability, I am here filtering out the ipPhone, homePhone and extensionAttribute9 attributes from synchronization because we don’t want them to be visible in the Exchange Online Global Address List. I make the selection by first checking the “I want to further limit…” check box and then clearing the attributes from the list. Make your selection and hit Next to continue.
    13wizard8
  15. Next is a summary of your AADSync configuration. Check to see that everything looks OK and hit Configure to continue.
    14wizard9
  16. When the configuration is completed, you have the option to start the first Synchronization immediately, or to finish the wizard without starting the synchronization so that you can configure filtering before starting (if your would like to filter out specific OUs, child-domains or set an attribute based filtering). Filtering with AADSync works and is configured the same way as it always have with DirSync. Instructions on how to enable and configure filtering can be found here. In this example, we want to synchronize the complete scope of both forests, so we let the “Synchronize now” option stay selected and hit Finish to complete the wizard and start the synchronization.
    15wizard10
  17. Now, all we need to do is wait for the synchronization to complete. You can monitor the synchronization progress by opening the Synchronization Service Manager (the miisclient interface) from the Start menu. You can track the different stages of the synchronization in the Operations tab.
    16SyncServiceManager
  18. There is also another tool available with AAD Connect called the Synchronization Rules Editor (you will find it in the Start menu). This tool can be used to see and edit the attribute flows and scoping filters. You can use the tool to create transformation rules for certain attributes etc. In this example, we will not make any such changes, but we open it to have a look while we are waiting for the synchronization to complete.
    17SyncRuleEditor
  19. When the synchronization is completed, it is time to see the result. Sign in to the Office 365 admin portal and navigate to Users. Now, you will see users from both forests provisioned as synchronized identities “Status is Synchronized with Active Directory”. Success!
    18Syncedusers
  20. When opening a user from each forest, you see that both users are synchronized (get’s the banner stating they can only be edited in the local Active Directory) and that the user name matches the UPN-name in the local AD.
    19ForestAuser20ForestBuser
  21. The users can now be licensed and start using Office 365, or other AAD-integrated, services. You may also set up federated identities using ADFS and provide Single Sign-on to the users from both forests using a shared ADFS STS service with proper configuration.

SUMMARY AND DISCLAIMER

In this article we have seen how powerful and yet easy to use the new AAD Connect Service is. Multi-forest is a common and challenging reality for many enterprise customers, and with AAD Connect there is finally a robust, simple and supported way to get Active Directory synchronization working in that scenario. So thank you DirSync, AADSync, FIM AAD Connector and stand-alone AADSync for the great time together, it have been great – but now it’s time for AAD Connect to take it from here.

ADFS 3.0 and Hardware Load Balancing – the Lost Documentation

Article updated October 2014 to include http based health check probe as a workaround, made available with August 2014 Update Rollup for Windows Server 2012 R2.

BACKGROUND AND PURPOSE

ADFS and Federated Identities are common components for Enterprise Office 365 customers necessary to allow Single Sign-on, use of Claim Rules and immediate account lock-outs etc. As the availability the ADFS service decides the availability of Office 365 (if you can’t authenticate you can’t use the service), load balancing is a must-have. In most cases, Hardware Load Balancing (HLB) is used, and for ADFS 2.0 (Windows Server 2008/2008R2) and ADFS 2.1 (Windows Server 2012) this have never been a problem. You deployed your ADFS STS and/or ADFS Proxy, and published them with your Hardware Load Balancer like “any other SSL site” and it just worked.

Today, ADFS have with Windows Server 2012R2 reached version ADFS 3.0 – and the full “out-of-the-box-support” for using “any Hardware Load Balancer” is not as obvious any more. Making it  work is a bit more tricky, depending on what HLB you are using. The purpose of this article is to present my lessons learned from deploying ADFS 3.0 with HLB – and to save you from hours of trouble shooting when getting your own ADFS 3.0 HLB up and running with Office 365.

ADFS 3.0 AND HARDWARE LOAD BALANCING – WHAT COULD POSSIBLY GO WRONG?

ADFS 3.0 and Web Application Proxy (WAP) in Windows Server 2012R2 uses an extension to the TLS SSL protocol called Server Name Indication – SNI (RFC 4366). This extension allows web servers to present host names when handshaking SSL, so that multiple SSL sites can be hosted on a shared IP-address and port (443) – just like the concept of host headers in good old http have always allowed us to do. This is great because it allows preservation of IP-addresses which also can reduce a total cost of ownership for a service (public IP-addresses does not come for free these days).

What is not so great is that the SNI extension is not yet supported by “everything else in the world” – such as very old web browsers – and Hardware Load Balancers. Using a HLB that does not have a clue about SNI will not work, and that is the topic of this blog post.

If you are interested to read more about SNI in Windows Server 2012R2 – and how to solve issues that can occur, I can recommend Ian Parramore’s two excellent blog post on TechNet, which also have been a great inspiration and source of content to this post, found here, and here.

HOW DO I KNOW THAT MY HLB DOES NOT SUPPORT SNI?

If your HLB does not support SNI, you will notice it eventually when attempting to configure a load balancing and you don’t get any response on port 443 from any of the server IP-addresses. (that’s usually when you spend a day or two troubleshooting firewall ACL’s and routing without any luck). My best advice is to look for SNI-related settings in the HLB administrative interface and read through the release notes for the software version you are running on the appliance(s).

Examples of observed behaviour when attempting to configure HLB with a non-SNI compliant device is a “Http/1.1 Service Unavailable” message from a Citrix NetScaler device and a “Network Error (tcp_error) A communication error occured: Connection refused” message from a BlueCoat device.

Big-IP/F5 customers may turn to a technical article written by Greg Coward for assistance in configuring the Big-IP to work with ADFS 3.0/WAP, found here.

MY HLB DOES NOT SUPPORT SNI – WHAT CAN I DO?

CHECK FOR UPDATES: Before attempting to fix the issue on the Windows Server side – you should always see if there is an available software/firmware update for your HLB device that includes SNI support. There are two workarounds available (see below), but having native support is usually preferred as it reduces the overall complexity of your solution.

WORKAROUND #1 : ADD A HTTPS (PORT 80) BASED HEALTH CHECK PROBE

NOTE: This functionality was made available with the August 2014 Update Rollup for Windows Server 2012R2, found here. Running at least this update rollup level on your ADFS/WAP servers is required for the following workaround to work.

By adding a http-binding on the ADFS/WAP server, your HLB can do the health check probing using the http protocol and thus bypassing SSL and SNI completely. The http endpoint will respond with HTTP 200 OK if available if queried to http://servername-or-ip-address/adfs/probe, and will not automatically allow your ADFS traffic to use HTTP, they will function just as health check probes. Follow these steps to create such binding:

  1. Make sure you have installed all available Windows Updates on the ADFS/WAP machine – at least August 2014 Rollup.
  2. Launch the Windows Firewall with Advanced Security MMC on the first WAP server
  3. Go to Inbound Rules
  4. Create a new Inbound Rule (New Rule in Action Pane). Suggested name: “ADFS HTTP Health Check Probe”
  5. Configure the rule for TCP protocol, local port 80 (specific port) and Allow traffic (All ports as Remote port). See overview of expected result in this picture from Ian Parramore’s blog.
  6. Repeat steps on other ADFS/WAP machines.
  7. Configure HLB to do health check probe using the http protocol and this specific endpoint: http://servername-or-ip-address/adfs/probe

WORKAROUND #2 (RECOMMENDED): ADD A FALLBACK BINDING TO 0.0.0.0:443

It is possible to create a binding to make ADFS 3.0 and/or WAP to respond to SSL requests made out to ip-adresses. This is the recommended workaround as you can’t fully disable the SNI functionality completely. The process of adding this fallback binding consist of finding out the certificate thumbprint of your desired SSL certificate (added with private key to the Local Computer\Personal store) and then binding that thumbprint to all ip-adresses and for the ADFS or WAP application.

Follow these steps on all your ADFS 3.0 servers to add the fallback binding (and make your non-SNI compliant HLB be able to see your ADFS servers):

  1. Make sure that you have installed all available updates for Windows Server 2012R2 after adding and configured the ADFS STS or WAP Proxy role.
  2. Open a Command Prompt as administrator
  3. Run the following command:
    netsh http show sslcert
  4. You will see a list of SSL Certificate bindings.
  5. Mark and copy the ‘Certificate Hash’ value. Paste it to a temporary place (i.e Notepad)
  6. Mark and copy the ‘Application ID’ value. Paste it to the temporary place. The Application ID is what will associate the binding with ADFS 3.0 (for the internal STS servers) and WAP (for the ADFS Proxy).
  7. Now run the following commmand, where you insert the noted ‘Certificate Hash’ and ‘Application ID’ values from above (keep the { } characters):
    netsh http add sslcert ipport=0.0.0.0:443 certhash=Insert_Certificate_Hash_Here appid={Insert_Application_ID_here}
  8. Restart machine and repeat steps for remaining ADFS 3.0 machines.

After adding the fallback binding, your HLB should be able to reach your ADFS servers normally, and you can continue to configure and fine tune your load balancing. Be aware that if you replace your certificate in the future (when it expires), you must perform these steps again (a new certificate means a new certificate hash) – worth mentioning in your system documentation.

SUMMARY AND DISCLAIMER

Adding a http health check probe or a fallback binding can help us fix our load balancing, but my hope is that SNI support in HLB devices will become more of a standard than it is today. Like stated in the article, looking for native support with a software/firmware update and proper documentation from your HLB vendor is always recommended before applying the fallback binding workaround. If you are aware of SNI-related knowledge base articles and software updates from HLB vendors, please share them with me in the comments field below or on Twitter (@JesperStahle) and I will add them to this article.

Internet Explorer 8 Only Loads Outlook Web App Light in Exchange Online/Office 365

BACKGROUND

Consider the following scenario:

You are using Exchange Online/Office 365. When opening Outlook Web App (OWA), Internet Explorer only loads the Light version of OWA (OWA Light). The same user on the same client could earlier load the rich OWA experience even on Internet Explorer 8.

If the same user logs on to Internet Explorer 9 or later, or the latest version of Firefox, Chrome or Safari, rich OWA is loaded instead. OWA Light is only enforced on Internet Explorer 8.

CAUSE

This behavior is by design. Rich OWA have earlier been allowed for Internet Explorer 8 users, but with limited performance (see this article). Starting May 2014, OWA Light is being enforced for Internet Explorer 8 users. This is stated in the Office 365 Service Description, see this article.

Quote from the Service Description:

“The user experience sending and receiving email with Outlook Web App and Internet Explorer 8 might be substantially diminished, especially when used on Windows XP or with low memory devices. Office 365 does not offer code fixes to resolve problems you encounter when using the service with Internet Explorer 8, and new Office 365 experiences might not work at all. You should also expect the quality of the user experience with Internet Explorer 8 to diminish further in the near future. Beginning in May 2014, Internet Explorer 8 will only display Outlook Web App Light.”

RESOLUTION

Upgrade Internet Explorer to the latest version, or use the latest version of an alternative browser. If you have legacy application dependencies to Internet Explorer 8, consider upgrading to Internet Explorer 11 and use IE Enterprise Mode to emulate IE8 rendering for those legacy web sites/applications.

And remember – Office 365 is an “evergreen” service, meaning that back-end updates will be released constantly. As a customer, you should keep your client applications on the latest version/build to stay fully compatible and supported. This includes Windows, Office applications and Internet Explorer.

Hands on with Office 365 Message Encryption (OME) using One Time Passcode

ARTICLE UPDATED OCTOBER 2014 AFTER LAUNCH OF OTP CAPABILITIES IN OME.

INTRODUCTION

At the beginning of 2014, Microsoft released new capabilities for email encryption, called Office 365 Message Encryption (OME). The functionality was first announced in november 2013 in this article. In October 2014, OME was improved drastically as the receiver of encrypted emails now can use a One Time Passcode (OTP) to access the encrypted message (documented here). At launch of OME, all receivers had to authenticate with either an Organizational Account (Azure AD) or a Microsoft Account (formerly LiveID) to access the email, which often led to confusion for external receivers. Now, the receiver can instead request a One Time Passcode to the same email address as to which the encrypted message was sent, and use that (within 15 minutes) to access the encrypted email. This post was updated in October 2014 to include this new OTP-functionality.

In this post, I will demonstrate the user experience of Office 365 Message Encryption, both for the end-user (using OTP) and the administrator (setting up IRM Licensing and all necessary Transport Rules etc).

SCENARIO

We will create a transport rule that will enable Office 365 Message Encryption on messages with a Sensitivity level set to Confidential.

STEP 1 – ENABLE IRM LICENSING

If you attempt to use Office 365 Message Encryption before first enabling IRM licensing, the operation will fail and give you this message:

You can’t create a rule containing the ApplyOME or RemoveOME action because IRM licensing is disabled.

To remediate this, we need to enable IRM licensing using the Admin portal and PowerShell. Follow these steps:

  1. First, enable RMS in your tenant by logging on to your Office 365 Admin Portal, navigate to Service settings (left pane). select Rights management (top bar), click Manage and finally hit the button Activate. A message should appear stating that RMS is activated for the tenant.
  2. The remaining steps will be done in PowerShell. Open Windows Azure Active Directory Module for Windows PowerShell, found here:
    http://technet.microsoft.com/library/jj151815.aspx
  3. Connect your PowerShell session to your Office 365 tenant an Exchange Online by entering the following:
    $msolcred = Get-Credential (Answer the credential prompt with your Office 365 tenant administrator credentials) 
    Connect-MsolService -Credential $msolcred

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $msolcred -Authentication Basic -AllowRedirection
    Import-PSSession $Session
  4. When connected to Exchange Online, you can enable IRM licensing with just a few steps. The first step is to set the RMS Online key sharing location. You will use different configurations depending on where your tenant is located (North America, European Union or the Asia-Pacific area).Enter the command that matches your tenant location (choose one):
    North America: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc
    European Union: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.eu.aadrm.com/TenantManagement/ServicePartner.svc
    The Asia-Pacific Area: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.ap.aadrm.com/TenantManagement/ServicePartner.svc
  5. After setting the key sharing location, the next step is to import the Trusted Publishing Domain (TPD). Do so by entering the following:
    Import-RMSTrustedPublishingDomain -RMSOnline -name “RMS Online”
  6. The final step is to activate the internal IRM licensing. Do so by entering the following:
    Set-IRMConfiguration -InternalLicensingEnabled $True
  7. After enabling IRM licensing, verify the functionality by entering:
    Test-IRMConfiguration -RMSOnline

The test should pass with the result OVERALL RESULT: PASS.

NOTE: Enabling IRM licensing might need several hours for the change to take effect. If possible, allow 8 hours to pass before proceeding with STEP 2.

STEP 2 – CREATE THE OME TRANSPORT RULE

We will create a transport rule that enables Office 365 Message Encryption if the message is sent to a recipient outside the organization and the Sensitivity header have been set to Confidential.

Follow these steps:

  1. Log in to your Office 365 Admin Portal and navigate to Exchange Control Panel (Admin\Exchange).
  2. Navigate to Mail Flow, click the + icon and select Create a new rule…
    Newrule
  3. Give the rule a suiting name and click More options…
    moreoptions
  4. From here you can set your condition as it fits your needs, but for this example we will inspect the Sensitivity header and apply Message Encryption based on that. To do so, select the following conditions:
    Apply this rule if… A message header includes any of these words
    amessageheader
  5. Complete the Apply this rule if-condition by clicking the properties Enter text and Enter word so that the condition makes ‘Sensitivity’ header includes ‘Confidential’
    sensincl
  6. Click Add condition and select The recipient… Is external/internal. Click Select one… and select Outside the organization and hit OK
    outside
  7. Proceed with clicking Do the following… and select Modify the message security… and select Apply Office 365 Message Encryption
    applyo365m
  8. Hit Save at the bottom of the New rule editor. (If you get the message that IRM licensing is not enabled and have completed STEP 1 – please allow more time for the change to take effect, as stated in the Note after STEP 1).

STEP 3 – SEND A CONFIDENTIAL MESSAGE WITH OME

We will create a message with the sensitivity level set to Confidential and send this to a recipient outside our organization. Our transport rule will apply Office 365 Message Encryption to the message.

Follow these steps:

  1. Open Outlook or Outlook Web App. Both clients have the native functionality to set the sensitivity header. In the example, I will use OWA, but the procedure is the same in Outlook.
  2. Compose a new message. Enter an external recipients, give the message a subject and some content, then click  and Show message options…
    messageopt
  3. Set the message Sensitivity level to Confidential and hit OK
    confidential
    NOTE: In the rich Outlook client, Sensitivity options are found under Message Options\More options\Sensitivity.
  4. Send the message.

STEP 4 – RECEIVE AND OPEN THE ENCRYPTED MESSAGE

  1. Open the inbox of the external mailbox and find the encrypted message
    protectedmessage
  2. As you can see, the message includes an attached HTML-document. Open the attachment.
  3. To be able to read the encrypted message, you can choose to sign in with a Microsoft Account or Corporate Credentials (AAD/Office 365 account) that has a username that matches the e-mail address to which the encrypted message was sent – or (new October 2014) you can choose to open the message with a One Time Passcode that is sent to the same email address that received the encrypted message (html file). I recommend using Organizational Accounts when sending to other Office 365 users, as they can then open the message with their corporate credentials or even an existing session cookie (Single Sign-on experience) – but for external users, which we are demonstrating in this case, One Time Passcode would be prefered. I am selecting the OTP choise by following the link at the bottom (“Don’t want to sign in? Get a one-time passcode…”).
    Select "Get a one-time passcode..."
  4. Now, go back to your inbox (recipient) to find the One Time Passcode and a reference code (handy if you have received multiple encrypted messages at once to differentiate the OTPs for different messages). Make a note of the OTP and go back to the browser.
    Find the OTP in your inbox
  5. Enter the Passcode from the email in the Passcode field, then click Continue.
    step2
  6. The message will now load and be displayed in the browser.
    voila

CONCLUSION

The Office 365 Message Encryption is a very good feature that allows Office 365/Exchange Online customers to send encrypted messages both inside and outside their organization. The new OTP functionality makes it even better and more complete. This post demonstrated the basic capabilities of OME, and you can make even more advanced Mail Rules, such as applying RMS templates to the message if it is sent to an internal recipient, and use Office 365 Message Encryption only to external recipients – just configure the rule to fit your needs.

You can also customize/brand the message that includes the HTML-file by using the
Set-OMEConfiguration cmdlets. The cmdlets allow you to set custom e-mail text, disclaimer, portal text and even include your company logo for branding.

 

Can’t login to Lync Online on Domain Joined Machine in a Single Labeled Domain (SLD)

BACKGROUND

  1. You are using Lync Online together with Lync or Lync Basic client.
  2. You’r  client is joined to an Active Directory domain with Single Label Name (SLD). FQDN Name is, as an example, “domain” and not “domain.local”
  3. You can logon to Lync using mobile clients or from other clients than are not domain joined to your Single Labeled Domain.
  4. When logging on with the Single Labeled Domain joined machine, the Lync Client gives the following error:
    The Server is temporarily unavailable. If the problem continues, please contact your support team.

CAUSE

Single Labeled Domains are not supported with Lync Server, but there is no documentation regarding Lync Online instead of an on-premise Lync installation in combination with a client running from a Single Labeled Domain.

The fact is that this combination does not work wihtout additional configuration (see Resolution). Allthough the Lync Online infrastructure is not running in a Single Labeled Domain, the client can’t login from a machine joined to a Single Labeled Domain.

RESOLUTION

To solve this, all users that are running Lync Online must have a proper UPN-suffix in Active Directory. There is NO NEED to login with the UPN-name, but the attribute itself must be populated.

Follow these steps to verify the solution with a few users, before applying to all users:

  1. In you Active Directory forest, add an additional UPN Suffix. As suggestions to what to add, you can add the same as your SMTP domain(s), or just use the current SLD and add “.com”. Instructions on how to add UPN Suffix can be found here: http://support.microsoft.com/kb/243629
  2. On your own (an/or other) user account(s), change the UPN Suffix to the newly added “domain.com-like” using Active Directory Users and Computers. You find the UPN suffix on the Account tab, the right drop-down box under “User logon name”
  3. Wait for AD Replication to complete (15 minutes give or take, depending on number of AD sites etc.)
  4. Log off and on to your workstation
  5. Attempt to log in to Lync again
  6. Repeat for remaining users

With a correct UPN Suffix, Lync Online will allow you to log on from the domain joined machine, regardless if you logged in with your samAccountName or the full UPN-name.

Shared Accounts (POS/Kiosk) and Single Sign-On in the Same Environment

BACKGROUND

You have successfully configured Single Sign-on in Office 365 with the following conditions:

  1. ADFS is deployed with one internal pair (STS) and one external pair (Proxy), both pairs are load balanced. ADFS is running at least version 2.0 with the latest Update Rollup installed.
  2. Clients that resides on the internal network have the ADFS URL (in this example sts.Company.com) pointing to the ADFS STS server pair (the LB VIP).
  3. Clients that resides on the external network have the ADFS URL (sts.Company.com) pointing to the ADFS Proxy pair (the LB VIP).
  4. On all Active Directory-domain joined clients, the ADFS URL (sts.Company.com) is added to the Local Intranet Zone using a Site-to-Zone Assignment List GPO.
  5. You have not configured ADFS to allow Single Sign-on for non-IE browsers (Disable Extended Protection).
  6. You have verified that Single Sign-on works as expected by navigating to http://outlook.com/OWA/company.com (where Company.com is a custom domain that is configured as a Federated Domain in your Office 365 tenant). When navigating to the URL, you are redirected to Outlook Web App without being prompted for credentials.

This scenario is exactly what we want for our users that are logging on to Windows everyday using their personal Active Directory account. It is a seamless solution that allow the user to consume Office 365 services without entering credentials multiple times through-out the working day.

The problem is if parts of the organization is using common/shared Active Directory accounts for logging on to Windows. A few examples of when common Active Directory accounts are used for logging on to Windows are at: Point of Sale terminals (POS), front desk/receptions, and at heavy industry operation sites (factory users are restricted by gloves/outfit).

These users will not be able to access their personal Office 365 services as they are logged in to Windows with the shared account, and when attempting to access, for example, Outlook Web App, they either get a message that the current account does not have a valid license (if the shared account is not licensed), or they will be logged in to the wrong mailbox (if a licensed user is logged on to Windows when the other user is taking over the session). The user have no chance to login as themselves to reach their personal mailbox etc, as we have configured Single Sign-on to Office 365, without any credential prompts allowed.

In summary, we have a situation where users logging on with personal Active Director accounts to their personal computers have a perfect experience with Single Sign-on, but our users without personal computes that are logging on to Windows with shared accounts, are simply not able to reach their mailbox and other data without first logging in to Windows with their personal account – which is not feasible for the business operation.

CAUSE

This bevaviour is fully expected. It is not ideal for users to share Active Directory accounts for loggin on to Windows, both from the security perspective (complicance and auditing) and from the functional perspective (single sign-on and personal data access). To remediate it, the general recommendation is of course to have all users logging on to Windows with personal Active Directory accounts, but in reality, this is not always possible. The reasons are many, and they are not described on TechNet or in any text book examples, but they are usually related to the time it actually takes to log off and log back on. At a POS, every lost second can be a lost sale, and at the factory floor, every lost second can be a compromise of a persons safety.

Technically, our Single Sign-on configuration is doing exactly what it is supposed to do. A user attempts to reach Outlook Web App, get’s redirected to ADFS STS and authenticates using the Kerberos TGT-ticket issued for the shared account when logging on to Windows. ADFS grants a Token, including claims for the shared account. The Token is then presented to Office 365, who translates the claims to either a non-licensed user (giving the No license error), or if it exist, to the mailbox for the shared account (loading the wrong mailbox for the user).

RESOLUTION

To remediate this problem, without affecting the Single Sign-on experience for our Office workers with personal computers, we must break the Single Sign-on configuration only for the shared accounts.

To accomplish this, we will configure the Site to Zone Assignment List GPO.

As stated in the Background above, the ADFS URL sts.Company.com is added to the Local Intranet Zone to allow Single Sign-on. If we remove it from there, the user will not be able to present the Kerberos TGT-ticket when logging on, and we will prompted for credentials again. This is a bad user experience and should never be the routine for Office users with personal computer and personal accounts, but such credential prompt is what can allow a user that has logged on with a shared user account to actually login to Outlook Web App (or other Office 365 Service) with a personal account and reach the personal mailbox.

High-level description of the solution:

  1. Depending on how Group Policy is used in your organization today, first decide if this setting should be computer based or user based. Both can be applied for this.
  2. Configure separate Site to Zone Assignment List GPO’s for personal Active Directory accounts and for common/shared Active Directory accounts. (Or for personal computers or shared computers, depending of outcome in #1).
  3. For the personal account/computer GPO, place sts.Company.com in the Local Intranet Zone – this will give them Single Sign-on
  4. For the shared accounts/computers, Place sts.Company.com in the Trusted Sites zone – this will break Single Sign-on and give the user a credential prompt on access to the services. The user can respond to the credential prompt with personal credentials and by that accessing the personal mailbox/data.

Here is a good overview of the Site to Zone Assignment List GPO: http://blogs.msdn.com/b/askie/archive/2012/06/05/how-to-configure-internet-explorer-security-zone-sites-using-group-polices.aspx (Scroll down a bit).

COMMENT: Some organizations solves this issue by letting all clients redirect sts.company.com to the ADFS Proxy even internally. This methdo will also present the credential prompt, but it will affect all users – including those that are using personal accounts on personal computers – which is a bad user experience for them. Using GPO and Site to Zone assignment is  a better way to go.

PST Capture Tool 2.0 Only Imports Deleted Items Folder

BACKGROUND

You are attempting to import data to Exchange Online mailboxes using the PST Capture Tool 2.0 (http://www.microsoft.com/en-us/download/details.aspx?id=36789). The following works:

1. You can import PST files to the tool
2. You can map the PST files to mailboxes in Exchange Online (x64 bit version of Outlook is required to see the mailboxes)
3. If you open the PST file in Outlook on the machine, you can see all the content

When starting the Import, the stage called “Transferring” completes 100%. Then, when the Import stage begins, you can see that it only finds 2 folders. The progress shows Importing Folder 0/2, 1/2 and then 2/2.

After the import is done, you can see in the Exchange Online mailbox that the only content that have been imported is the Deleted Items folder.

CAUSE

This occurs if the PST file that is imported is in an incompatible format. Without going into, or knowing, the details of it all, PST files can be created in different structures. The version of Outlook together with how PST Capture Tool 2.0 works decide if all content in the PST files root folder (IPM_SUBTREE) will be visible to the operation or not. Read more here: http://msdn.microsoft.com/en-us/library/ff387699(v=office.12).aspx

The error can occur when the PST file have been exported from Exchange Server 2010 SP3 using New-MailboxExportRequest.

RESOLUTION

Run SCANPST.EXE from the Program Files\Microsoft Office\(VersionNumber) folder on the machine. Use SCANPST.EXE to scan and repair the PST files you want to import. After repairing the file, PST Capture 2.0 will import all folders and objects.

This process takes a while, and if you are to do 100+ mailboxes, it might have a severe impact to your planning. Depending on the PST file, it might help to change Outlook version on the machine where you run PST Capture 2.0 – just make sure that it is always x64 bit.

Free/Busy not working from Office 365/Exchange Online to On-Premise Exchange / Hybrid Configuration – “The external recipient’s server could not be determined” “No information” (You forgot to iisreset)

BACKGROUND

You have successfully deployed a Hybrid Configuration between your on-premises Exchange 2010 SP3 Organization and Exchange Online. Everything works as it should, except for Free/busy look-ups made from Exchange Online mailboxes to a mailbox that still resides on-premise.

You have verified that the following is OK:

  1. You have run ExRCA diagnostics using https://www.testexchangeconnectivity.com/ , selected the Office 365 tab and then Free/busy tests. You simulate Free/busy lookup from Online to On-premise and it works with all green lights.
  2. You have also followed all the troubleshooting steps presented in this Microsoft Knowledge Base article: http://support.microsoft.com/kb/2555008 – all with successfull results.

Still, when attempting to do Free/busy lookups from Online to On-premise, you get the message in Outlook or OWA saying “No information” with the reason “The external recipient’s server could not be determined”.

CAUSE

Settings made during your Hybrid Configuration and/or extended troubleshooting of this error have not been fully commited to Internet Information Server (IIS). Allthough the diagnostics (ExRCA etc) say that your configuration is right, vital configuration is not yet effective.

RESOLUTION

First step in resolving Free/busy errors is to follow the two steps mentioned in the Introduction to this post (ExRCA diagnostics and following KB2555008 – see above). If that does not work:

Doing iisreset on your CAS server publishing EWS/Hybrid could fix this issue.

Plan for a very short outage in Exchange services (OWA/EWS etc) and open the command prompt on your Hybrid CAS server. Then run the command iisreset

After doing IISReset, Free/busy lookups from Online to On-prem should start working within minutes.

I have seen this in the field where we spent days troubleshooting this issue on Exchange 2010SP3 hybrid configurations after finally solving it with this basic, but classic, method – restarting the services. There could of course be other reasons behind the error (i.e related to how Autodiscover is published to the internet), iisreset should not be considered as a “general cure”, but a necessary troubleshooting step if your configuration is done by the book and it still does not work.