Hybrid Configuration with Multiple SMTP Domains

A colleague of mine at Catapult Systems, Michael Rinner, recently sent out the below information to our team. This is a great new feature that prevents the need for many Autodiscover Certs and configurations.

I would like to share something I learned. I am currently doing a Hybrid configuration between Exchange 2010 SP3 and Exchange Online with approximately 50 SMTP domains. Previously, the hybrid configuration required an autodiscover record for each domain and a SAN certificate with autodiscover for each domain. Exchange 2013 and Exchange 2010 SP3 RU1 or later introduced an autodiscover domain feature. The autodiscover domain feature tells Exchange to use the autodiscover settings of the primary smtp domain for all domains.   http://technet.microsoft.com/en-us/magazine/dn249970.aspx

To make it work with the hybrid configuration wizard (HCW) do the following:

  1. Run the HCW with just the primary smtp domain and make sure it completes without any issues.
  2. Open the Exchange Management Shell from the hybrid server and run the following command.
    1. Set-hybridconfiguration –domains contoso.com, fabrikam.com, domaina.com, domainb.com autod:primarydomain.com (NOTE the autod) (Do not use quotes)
  3. Run the HCW again with all the domains populated.
  4. Then do a get-hybridconfiguration | fl and you should all the domains populated with the autod also.
Advertisements

Office 365 Verify a Domain Quickly

I have had several people ask me about verifying a domain in Office 365.  About 6-8 months ago Microsoft changed the way a domain is verified, if an admin wanted to add a domain for Exchange Online and selected that as the domain intend, well they needed to change several DNS records to conform to what Microsoft expected and advised.  While this can be good for some, most don’t want or can’t change some DNS records just to get a domain verified in Office 365, specifically the DNS MX record associated with the domain.  When you want to add and verify a domain for testing purposes or more importantly to use as a UPN domain for authentication here is the trick:  Don’t declare a domain intent!  If you leave the below checkmarks blank, Microsoft will still allow the domain to be verified using the DNS TXT record method.  The DNS TXT Record method simply requires that you create an external DNS TXT Record containing MS=MSXXXXXXXXX (X’s being replaced by specific numbers given during the domain add wizard).

SeanAddDomain

ADFS vs DirSync with Password Sync: The User Experience

I promised to do a comparison and pro/con around using ADFS with Single SignOn (SSO) and at the time the newly released Password Sync with the new DirSync tool. Well finally here it is, and with thanks to a fellow co-worker, JC Warner for developing the below table based on research and his experience using both. JC also used the following Microsoft white paper “Office365-Single Sign-On-with-AD-FS2.0-v1.0a

So here is the Table that compares the end user experience using ADFS and DirSync with Password Sync enabled:

Access Method ADFS DirSync w/ Password Verdict
Outlook 2010/2013 Prompted for credentials on first connection (and at each password change) with checkbox to remember them. Prompted for credentials on first connection (and at each password change) with checkbox to remember them. Draw, both have the same experience
ActiveSync, POP, IMAP Prompted for credentials on first connection (and at each password change) with checkbox to remember them. Prompted for credentials on first connection (and at each password change) with checkbox to remember them. Draw, both have the same experience
MS Online Portal, SharePoint Online, Office Web Apps Internal: Pop up offers click to sign in with no credentials required (External Forms Based Prompted) Prompted for credentials on first connection (and at each password change) with checkbox to remember them Better experience for ADFS while internal to company network, draw when external
OWA Internal: Seamless (External Forms Based Prompted) Prompted for credentials on first connection (and at each password change) with checkbox to remember them Better experience for ADFS while internal to company network, draw when external
Lync 2010/2013 Seamless (with Sign on Assistance installed for Lync 2010) Prompted for credentials on first connection (and at each password change) with checkbox to remember them. Better experience for ADFS

As you can see above, overall for an end user experience when the user is internal to the company network ADFS offers a better experience. But when you take into account the additional administrative and server overhead needed to implement ADFS and SSO, I still would recommend Password Sync to a company. This is especially relevant to small companies who are moving to Office 365 to remove on-premises servers and resources from their environment. The caveat to this would be if a company already has ADFS deployed for another reason, federation with a partner or other SaaS provider, then using ADFS for Office 365 makes sense.

I will always lead with Password Sync versus ADFS and SSO. I just think with the cloud movement removing reliance on on-premises infrastructure for authentication is the right move. Now with Password Sync companies can reduce the sever footprint on-premises and fully ensure that if on-premises infrastructure goes dark that user can still access and authenticate to Office 365 resources.

PowerShell Profile Function to Connect to Office 365 PowerShell

To make it easy to connect to Office 365 remote PowerShell you can edit your PowerShell Profile to include a function.

First thing to do is check to see if you have a Profile created, to do this launch PowerShell and type “Test-Path $profile”, if True is returned you have a profile created, if False is returned you need to create it using this command “New-Item -path $profile -type file -force”

Now to edit your profile simply type “Notepad $profile”  A blank Text document in Notepad will appear (unless you have already configured a profile, if this is the case your existing profile will open in Notepad)

Here is the function for connecting to Office 365 Remote PowerShell:

Function Connect-O365
{
$Creds = Get-credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Creds -Authentication Basic -AllowRedirection
Import-PSSession $Session
Import-Module Msonline
Connect-MSOLService -credential $creds
}

Copy and paste the above into the Notepad window.  If you want you can add a reminder to yourself on how to use the Function.  Insert a line at the top of the profile and enter the below text

Write-Host “To connect to Office 365 with Remote Powershell type ‘Connect-O365′”

One additional note, if you do not have the Windows Azure Active Directory Module installed you will get an error as the Function calls the Module and connects to it as well.  Install the Windows Azure AD Module from here, http://technet.microsoft.com/en-us/library/jj151815.aspx#bkmk_installmodule

Now all you need to do is save the Profile, close and then re-launch PowerShell.  Simply type ‘Connect-O365’ and you will be prompted for your Office 365 credentials and connected to Office 365 Remote PowerShell and the Windows Azure AD cmdlets.