Update Send Connector SSL Certificate for Hybrid Configuration

​Recently had a customer with an Exchange 2013 Hybrid config require updating an expired SSL certificate.  When they imported the new certificate and assigned it SMTP services, mail flow from on-premises to Office 365 stopped.

This was because the on-premises send connector to Office 365 was still configured to look for that expired certificate (which had also been deleted already).

The fix was to perform the following:

  1. Open Exchange Management Shell on the on-premises Exchange server
  2. Run Get-ExchangeCertificate, and note the Thumbprint of the correct certificate to be used. 
  3. Run $cert = Get-ExchangeCertificate -Thumbprint <thumbprint>
  4. Set a new variable and assign it the concatenated values of the Issuer and Subject values of the certificate (must also include <I> and <S> before each field):
    $TLSCert = (‘<I>’+$cert.issuer+'<S>’+$cert.subject)
  5. Update the send connector with the new values
    Set-SendConnector -Identity “Send Connector Name” -TLSCertificateName $TLSCert

After completing this, any queued mail destined for the Office 365 tenant should begin flowing

Determine Office 365 Public Folder Hierarchy Limit

​Last month, in June 2014, the Exchange Team announced that Office 365 would soon have the public folder hierarchy folder count limit raised from 10,000 folders to 100,000 folders.  This limit increase would begin to take effect in July, 2014.

But how can you tell what your tenant’s current folder count limit is?

  1. Open a remote PowerShell session to your Office 365 tenant
  2. Run the following command:
    Get-Mailbox -PublicFolder | Get-MailboxStatistics | fl FolderHierarchy*

The command will return the following results:

FolderHierarchyChildrenCountWarningQuota : 9000
FolderHierarchyChildrenCountReceiveQuota : 10000

FolderHierarchyDepthWarningQuota         : 250
FolderHierarchyDepthReceiveQuota         : 300

Once the FolderHierarchyChildrenCountReceiveQuota is raised to 100000, you’ll know your tenant has been updated.

If your tenant does not have a public folder mailbox created yet, you can run the command without the -PublicFolder parameter and replace it with any mailbox identity.

Deploying Multi-Factor Authentication for Office 365

Multi-Factor Authentication (MFA) is now included in all O365 SKUs (except Small Business & Dedicated).

MFA enables you to require 2 or more of the following factors for users in your enterprise to authenticate to O365 services:

  • Something you know – a password or PIN
  • Something you have – a phone, smart card, or other token (like an SSL certificate)
  • Something you are – biometric – like fingerprint or retinal scan

Office 365 uses Windows Azure MFA (powered by PhoneFactor, acquired by msft in 2012). (http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/)

In this post, I’ll explain how to enable MFA for use with a smart phone. This gives you 3 options for verification:

  • Mobile Apps
  • Phone Calls
  • Text messages (OTP – one-time passcode)

You can enable MFA for single users or you can enable them for multiple users at a time via a CSV file import. You can also enable via PowerShell.

To enable MFA for O365 for a single user

  1. Log into the portal and navigate to admin center
  2. Select users and groups
  3. Click Set up next to Set Multi-factor authentication requirements
  4. Find the user and check the box next to their name
  5. Clicking enable brings up a pop-up

 
 

After enabling, you’ll need to send each user to this link to register for MFA: http://aka.ms/MFASetup

User must sign-in and then presented with this prompt:

The user should select the contact method they prefer:

  1. Mobile phone: This method allows for either text message verification (a 6-digit code is sent via standard SMS messaging) or phone call (pressing # confirms you are the one logging in)
  2. Office phone: This method only allows for a phone call confirmation, similar to Mobile phone. However, Lync phone numbers are not supported.
  3. Mobile app: This method utilizes a mobile application on your smart phone. The mobile app receives a 6-digit code that is used as the second authentication method – similar to text messages. If selected, click the Configure button and follow the instructions for configuring the app for your mobile device.
    iOS: https://itunes.apple.com/us/app/multi-factor-authentication/id475844606?mt=8
    Android: https://play.google.com/store/apps/details?id=com.phonefactor.phonefactor
    Windows Phone: http://www.windowsphone.com/en-us/store/app/multi-factor-auth/0a9691de-c0a1-44ee-ab96-6807f8322bd1
  4. Once you verify the app it will prompt you to verify each time you log in:

Apple iOS

Google Android

Windows Phone

 

 

 

  1. Once you choose a verification method and complete the verification steps, you’ll need to generate an App password. Office apps and mobile apps (like mail) must use this password instead of your normal password and it’s recommended you generate an app password for each device you intend to use.
  2. Once completed, you can always come back to this URL to make changes to your profile, change your password, or add additional authentication methods. You can also use this portal to access applications like SharePoint Online and Exchange Online (OWA).

 
 

To Enable MFA for users in bulk

After clicking Set-up for Multi-factor authentication from the Users and Groups page, click the Bulk Update button.


This will prompt you to provide a CSV file that contains two column headings: Username & MFA Status. A sample CSV file is displayed below:

Username, MFA Status

chris@contoso.com, Enabled

ben@contoso.com, Disabled

kyle@contoso.com, Disabled

kenny@contoso.com, Enabled

eric@contoso.com, Enabled

After you import the CSV file and complete the update process, you’ll need to notify each user to go to the http://aka.ms/MFASetup web page to configure their multi-authentication verification methods.

To Enable MFA via Remote PowerShell

You can use the following PowerShell commands to enable or enforce multi-factor authentication for a single user, all users, or a bulk list of users via CSV. You must use the Windows Azure Active Directory Module for Windows PowerShell. You can find instructions on downloading and installing this module here.

The commands:

#Establish the StrongAuthenticatonRequirement object with the required RelayingParty settings for Office 365

$mfobject = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

$mfobject.RelyingParty = "*"

$mfobject.State = "Enabled"

$mfauthenabled = @($mfobject)

$mfauthdisabled = @()

 

 

#Enable MFA for a single user

Set-MsolUser -UserPrincipalName username@contoso.com -StrongAuthenticationRequirements $mfauthenabled

 

 

#Enable MFA for all users (please use with CAUTION!)

Get-MsolUser -All | Set-MsolUser -StrongAuthenticationRequirements $mfauthenabled

 

 

#Enable MFA for bulk list of users in a CSV file

$userlist = Import-Csv .Contoso-MFA.csv

foreach ($user in $userlist) {

    switch ($user."MFA Status") {

        "Enabled"  {Set-MsolUser -UserPrincipalName $user.username -StrongAuthenticationRequirements $mfauthenabled}

        "Disabled" {Set-MsolUser -UserPrincipalName $user.username -StrongAuthenticationRequirements $mfauthdisabled}

    }

}

 

 

#Disable MFA for a single user

Set-MsolUser -UserPrincipalName username@contoso.com -StrongAuthenticationRequirements $mfauthdisabled 


			

 

Office 365 Deployment: Phase 2

Active Directory Preparation

Before you can begin synchronizing your Active Directory with Office 365 using DirSync, you must first ensure that directory objects meet specific formatting criteria.  This ensures that attribute values are unique and that invalid characters and formatting of such attributes as sAMAccountName, displayName, proxyaddresses, etc are formatted correctly for synchronization into Azure Active Directory for your Office 365 tenant.

You must also ensure that each user’s UserPrincipalName value and proxyAddresses values contains a domain that is publicly routable (i.e. user@contoso.com and not user@contoso.local).  I recommend setting each user’s UPN to match their default SMTP address for simplicity.

To do this, I recommend using the IDFix tool provided by Microsoft.  You can down load it at http://aka.ms/Tqmbxm

 

The IDFix tool queries your Active Directory and returns all user, contact and group objects and lists their property values for

  • sAMAccountName
  • givenName
  • sn (surname)
  • displayName
  • Mail
  • mailNickname
  • proxyAddresses
  • targetAddress
  • userPrincipalName

If any of these values contains data that will not synchronize (such as a space in the mailNickname or non-routable UPN) it will attempt a best-effort to suggest an updated value.  You can also manually input the updated value you require for your migration.  Then, you can use the IDFix tool to not only apply those updates individually or in bulk, you can also revert those changes if necessary.

You can also export the data to a csv file that you can massage inside Excel, reimport into the tool, and then apply changes.

Next up, Phase 3 – Identity and Single Sign-On

Office 365 Deployment: Phase 1

I recently presented a session on the Phases of Messaging Deployment for Office 365 at an Ignite training event at Microsoft’s offices in Dallas. I want to share the information I presented in a series of blog posts covering what I see as the four distinct phases of a migration project from on-premises Exchange to Office 365 and Exchange Online.

These four phases are:

 

This post will cover the topics surrounding Phase 1: Initial Assessment of your on-premises environment.

During this phase you must perform discovery around 4 specific areas:

 

Using Office 365 can significantly increase your organization’s internet traffic. To prepare for this, you must be sure you have the bandwidth to support all of the following activities:

  • Client Network Traffic
  • Mailbox Migration
  • Desktop Setup
  • NAT & Port Exhaustion

Client Network Traffic

Microsoft provides a useful Java-based tool hosted in Windows Azure (note the cloudapp.net URLs below) called the Fast Track Network Analysis tool. This tool performs a number of tests on your internet connection between you and your Office 365 tenant (you must provide the tenant name to begin the tests) including port availability, route summary and performance, speed, consistency of service and VoIP quality readiness among others.

You should run this tool from each distinct office location where users will access your Office 365 tenant.

This tool is available for three distinct regions

North America:
http://na1-fasttrack.cloudapp.net

EMEA:
http://em1-fasttrack.cloudapp.net

APAC:
http://ap1-fasttrack.cloudapp.net

 

Another useful tool you’ll want to employ is the Exchange Client network Bandwidth Calculator. This Excel spreadsheet allows you to input known data about number and types of clients (Outlook versions, OWA, ActiveSync, etc) and the time zones each of these clients are located. It also uses the familiar User Profile definitions seen in the Exchange Server Role Requirements Calculator that defines usage patterns of your users. The results are a graphical prediction of the amount of bandwidth you’ll need during each hour of the day in order to support all of your users accessing their Office 365 content.

 

 
 

Desktop Setup Bandwidth Impact

If you plan on deploying Office 365 Pro Plus (aka Office 2013) to your users – and even if you’re planning on keeping Office 2007/2010 – there may be bandwidth implications to consider here as well.

Office 2010 (and to a diminishing extent, Office 2007) fully support connectivity with Office 365 resources but require some additional patches and software to do so. You can find a list of required patches in the Office 365 Community web site here and here. In addition to the patches, you must also install the Microsoft Online Services Sign-In Assistant. This tool provides an improved sign-in experience for end users accessing Office 365 services, especially if ADFS is used for Single Sign-In.

If your users have local admin rights on their computers, they can install these patches themselves by logging into the Office 365 portal (https://portal.microsoftonline.com) and navigating to the software section to run Desktop Setup. This tool will analyze the computer to determine which patches need to be installed and perform that installation automatically.

Office 365 Pro Plus (Office 2013) supports connectivity to Office 365 “out of the box”. So once you have installed this version of Office, you’re ready to connect to Office 365.

However, if you plan on deploying Office 365 Pro Plus Click-To-Run, there may still be network bandwidth impact. Again, if your users have local admin rights on their computers, you can allow them to use the self-service portal to install Office Pro Plus. Because this installation method is based on the App-V model, it will stream down the bits of the software and allow users to begin using the application within minutes. Too many users installing all at once can have a significant impact on your internet bandwidth availability.

To mitigate this, or in cases where your users have no local admin rights to their computers, you can use the Office Deployment Tool. This tool allows you to stage the installation bits onto an on-premises file server for instance and use a software deployment tool such as System Center or other third-party deployment tool to install the software on users’ computers.

 
 

Mailbox Migration Velocity

Many factors can influence how fast you can migrate a mailbox to Office 365. Among them are:

  • MRSProxy Throttling – Your throughput for a single mailbox move will be in the 0.3-1.0 GB/hour range. Maximum average throughput per hour is 10-15GB (100 concurrency). Microsoft will not remote these throttling policies since they’re intended to protect service availability from being impacted by large amounts of users moving to the service. More info: http://technet.microsoft.com/en-us/library/jj204570.aspx
  • Available On-Premises Bandwidth: – If your mailbox migrations must compete with other user internet traffic for bandwidth, your own connection may become a bottleneck. In these instances, you can setup multiple endpoints to multiple source datacenters (if you have them) to spread the migration load.
  • Packet Loss – Severe packet loss between your on-premises Exchange server and the Office 365 endpoints can cause migrations to experience Transient Exception Errors, causing move requests to pause and/or completely restart.

     
     

NAT & Port Exhaustion

Finally, consider how many users you have behind a single public IP address NAT. Outlook clients can use 8 or more connections to Office 365 – more if you consider 3rd-party add-ins (like the social connector that links to LinkedIn and Facebook). With 64,000 available ports behind a single NAT – that means a maximum of 8,000 Outlook users can utilize that NAT – and that’s assuming there aren’t any firewall or proxy servers reserving ports for other uses.

 
 

My next post will take up the topic of assessing your on-premises Active Directory and Exchange environments.

Solution: Unable to update Active Directory information for the source mailbox at the end of the move

This scenario applies to hybrid configurations when moving mailboxes from on-premises to Office 365.

Whenever you see the error in the migration log that says “Unable to update Active Directory information for the source mailbox at the end of the move” it means that when the mailbox move completed, MRS could not disable the mailbox on the on-premises Exchange server and then RemoteMailbox-enable the user account as a cloud mailbox.

This results in two mailboxes – the original one on-premises and the new one in the cloud. However, the on-premises mailbox is inaccessible and autodiscover gets invalid information to setup the outlook profile.

To resolve this, perform these steps manually on the on-premises Exchange server in the Exchange Management Shell:

  1. Disable-Mailbox <alias>
  2. Enable-RemoteMailbox –Identity <alias> -PrimarySmtpAddress alias@contoso.com –RemoteRoutingAddress alias@TenantName.mail.onmicrosoft.com
  3. Wait for (or force) AD replication, then manually force a DirSync