Friday, October 10, 2014

Multi Organization O365 migrations - SMTP routing and Criteria Based Routing


When migrating three disparate email organizations into a single Office 365 tenant, one of the major hurdles in this was ensuring that once we have the first organization (CompanyA.com) migrated, the tenant is essentially in production, and while we are planning on turning up and licensing users for the next organization (CompanyB.com), we realized the problems this would cause.

The second organization is large.  Very large.  So we need to pre-stage data into mailboxes that could take days or even weeks.

The SMTP routing issue presented
If users from CompanyA.com were to attempt to email CompanyB.com, the messages would deliver to their mailbox in the tenant.   The same will be true when CompanyA.com and CompanyB.com are in production and CompanyC.com is pre-staging

We considered blanking out the mail attribute in AD to avoid this and just pre-stage to their tenant email address (companyABC.onmicrosoft.com) but too many other AD integrated applications relied on that field so that was not an option.

We began looking around in DirSync filtering for ways to blank the mail attribute by pairing it to an unused AD attribute in Active Directory.  This is NOT AT ALL recommended.

Microsoft does not support modification or operation of the Directory Sync tool outside of those actions formally documented.  The actions documented below in this article are supported. 
Unsupported actions include:
    • Opening the underlying FIM Sync Engine to modify Connector configuration  
    • Manually controlling the frequency and/or ordering of Synchronization Run Profiles or changing the attributes that are synchronized to the cloud. 
Any of these actions may result in an inconsistent or unsupported state of the Directory Sync tool and as a result, Microsoft cannot provide technical support for such deployments / usage of the tool.
Filtering configurations applied to your directory synchronization instance aren’t saved when you install or upgrade to a newer version. If you are upgrading to a newer version of directory synchronization, you must re-apply filtering configurations after you upgrade, but before you run the first synchronization cycle.

That seems like very clear and strong language.  It's not supported, and if you change anything it might also break if and when you patch DirSync.

So without putting the customer in an unsupported space, how can we address the presenting mail routing issue? 

Enter Criteria Based Routing!

Two basic steps here:

  1. Create an Outbound Connector for the CompanyB.com domain
    1. On the Delivery section, specify "Route mail through smart hosts" and manually enter the existing MX records for the CompanyB.com domain
    2. On the "Scope" section, select "Use for Criteria Based Routing (CBR)"
  2. Create a Transport Rule
    1. Apply this rule if: The recipient is.. located inside the organization
    2. And: A recipient's domain is.. companyb.com
    3. Use the following outbound connector.. Select the connector created in Step 1

That's it.  Now you can license mailboxes with their correct SMTP addresses, pre-stage data, and they will NOT receive any SMTP traffic until you disable or remove the connector and the rule.  Which in addition is a much easier cutover day task than to be changing users or DirSync configurations en masse.

Hope this helps you, please post if it does!



Tuesday, September 30, 2014

Exchange Online Shared Mailboxes - Licensing, quota and compliance


Like all things cloud, things change.  This was based on September 2014 data and findings.

Writing today about shared mailboxes as a customer recently had several requirements and in reviewing the service description, I have found some inconsistent information.


And here's the current text of the footnote:
A user must have an Exchange Online license in order to access a shared mailbox. Shared mailboxes don’t require a separate license. However, if you want to enable In-Place Archive for a shared mailbox, you must assign an Exchange Online Plan 1 or Exchange Online Plan 2 license to the mailbox. If you want to enable In-Place Hold for a shared mailbox, you must assign an Exchange Online Plan 2 license to the mailbox. After a license is assigned to a shared mailbox, the mailbox size will increase to that of the licensed plan.

So for the purpose of this blog, I am going to focus on three issues:
  1. How large can a shared mailbox (no license) be?
  2. Can you put shared mailboxes into litigation hold or in-place hold?
  3. If you needed >10GB mailboxes or in place hold, how would you assign a license? 
How large can a shared mailbox (no license) be?
I created a shared mailbox and did a get-mailbox and see the prohibit send and receive is at 50GB



So, either the service description is incorrect, or PowerShell's quota reporting of space is incorrect.


So, I started stuffing the shared mailbox.  I have a pretty nice home PC.  SSD, 32GB RAM, etc.  I'd say around 5GB, using Outlook 2013 with all current patches, a shared mailbox became pretty slow and difficult to work with, even in OWA and Outlook 2013.
Can you put shared mailboxes into litigation hold or in-place hold? 
Based on the service description, you need a license for both litigation hold or in-place hold.  
Here's the GUI versus powershell of my in place hold.  You can see that in shell it shows there are no sourcemailboxes but the GUI shows I have an in place hold.  Confusing and very misleading.
According to the shared mailbox screen, it is under in-place hold



And my test eDiscovery with in place hold seems to be capturing data:


 And the preview shows my data!














What about litigation hold?   Well, that allows me to set it:




But can we trust it?  Is it really holding data?  The answer is yes.  Here's a trimmed screenshot of a prior test (not the same as the in-place hold) that captured data.  Even better, this mailbox was deleted, so this also proves that it is in litigation hold since the mailbox is no longer enabled, we know we are not searching an active mailbox.

If you needed >10GB mailboxes or in place hold, how would you assign a license? 

According to the Service Description, if you need in place hold or larger than 10GB shared mailboxes, you need to assign an Exchange Online Plan 1 or Plan 2 license to the mailbox.

However, since the mailbox is shared, you cannot assign a license to it.

So I opened a quick case asking "how do I apply a license to a shared mailbox?"

Their answer was simple - you need to convert the mailbox to a user mailbox.

Once converted, you can assign a license.   However, one may argue or be concerned on the points this brings up:
  • This is no longer a shared mailbox, but is a user mailbox that is shared, it now has a username and password (and the password assigned is not very complex if a cloud only account (@tenant.onmicrosoft.com) 
  • This is now a cloud only account, if you run DirSync or had a security requirement that all accounts be sourced in AD, this would not be within that policy, or subject to any policies your authentication solution might enforce.  If you had a Hybrid environment, you could convert and move the shared user mailbox to on premise, or just create your shared mailboxes on premise
  • Licensing does not appear to be required to have in-place or litigation hold enabled 
UPDATE 10/1/2014: Thanks to Nino Bilic for pointing out, you ABSOLUTELY can license a shared mailbox.  In O365 Users, search for it, and add a country and license.  He also advises that while quota and hold status may be working without a license, you should license them, in case Microsoft decides to enforce licensing, it could put you in a state of non compliance or over the size limit shared mailboxes!

UPDATE 10/8/2014: Another nod to Nino - In this article, Microsoft addresses Exchange Online licensing required and explicitly mentions Litigation Hold as WELL as in place hold require an Exchange plan 2 license!
Manage inactive mailboxes in Exchange Online






In closing..
  1. Quota, litigation and in-place hold all function as expected on shared mailboxes without a license, however this could change and be enforced at any given time, so obviously recommend using licensing if the functionality is needed.
  2. Litigation and in-place hold are completely enabled for shared mailboxes, regardless of the licensing section of the Service Description
  3. Licensing a shared mailbox can be performed by converting them to a user mailbox or by assigning a license to the shared mailbox MSOLUser as documented above

Automation of Azure Active Directory Federation settings using PingFederate for SSO

OK, I am guessing this will not be a very popular article, but if it helps even one person...  PLEASE COMMENT and tell me!

I had a customer using PingFederate for Authentication in Office 365, and they have a test bed environment and a production environment, and during our planning and testing phase we had to switch back and forth a few times, and there was an expectation that they might need to repeat this process later when they patch the PingFederate, or if they are testing new/extended functionality.

So I wrote this script to help you swap out the setting in Azure Active Directory PowerShell (aka MSOLshell)

You will need to edit:
  1. The $cert value
  2. The array of domains
  3. The array of PingFederate strings
  4. The $ssoURLroot
  5. Anything else specific to your environment
  6. Edit the actual set cmdlet to execute instead of write-host once you are comfortable with the script building the commands needed
 Hope this helps someone!


$cert = "reallylongstringofcharactershere"
$domain = @("companyABC.com", "companyDEF.com", "companyGHI.com", "companyJKL.com")
$string = @("randomcharactersfromping1", "randomcharactersfromping2", "randomcharactersfromping3","randomcharactersfromping4")
$ssoURLroot = "https://sso.companyABC.com/"

$ssomid1 = "idp/"
$ssomid2 = "pf/"

$logonURIend = "/sts.wst"
$logoffURIend = "/prp.wsf"
$metadataend = "/sts_mex.ping?PartnerSpId=urn:federation:MicrosoftOnline"

for ($i=0; $i -lt $domain.length; $i++)
    {
    $logonURI = $ssoURLroot + $ssomid1 + $string[$i] + $logonURIend
    $LogOffUri = $ssoURLroot + $ssomid1 + $string[$i] + $logoffURIend
    $MexchUri = $ssoURLroot + $ssomid2 + $string[$i] + $metadataend
    $PassLogOnUri = $ssoURLroot + $ssomid1 + $string[$i] + $logoffURIend
    write-host set-msoldomainfederationsettings -signingcertificate $cert -activelogonuri $logonURI -logoffuri $logoffuri -metadataExchangeUri $mexchuri -passivelogonUri $passlogonUri -domainname $domain[$i]
    sleep 2
Get-MsolDomainFederationSettings -domainname $domain[$i]
    # Change above line from write-host to execute!
    }






Wednesday, September 24, 2014

Exchange Online and a Connection Filter limitation

Ran into a situation the other day where I was inputting Whitelisted IP's from a customer's current mail hygiene solution, and EOP would not let me input a /20 network into the dialog.  I double checked the IP/subnet was correct, the periods were really periods, and no whitespace characters in my input.  No go.   Turns out I hit a fun limitation of the connection filter.  Not sure why they would have this limitation, but here is the documented limit and a workaround (if you use Exchange Online - if you are an EOP only customer, I am not currently aware of a workaround)

From here: http://technet.microsoft.com/en-us/library/jj200718%28v=exchg.150%29.aspx
"You can specify a maximum of 1273 entries, where an entry is either a single IP address or a CIDR range of IP addresses from /24 to /32."

So that's the limitation.  Luckily, this customer is using Exchange Online, which allows you to also use Transport Rules that can then cover a larger subnet and bypass spam filtering for connections from that IP:

http://technet.microsoft.com/en-us/library/jj200718%28v=exchg.150%29.aspx#bkmk_addtionalconsiderationswhenconfiguringipallowlists

Tuesday, September 09, 2014

Lync Key Health Indicators (KHI) summarization

"Necessity is the mother of all invention."

Lync Call Quality Methodology is a great way to inspect your environment and find areas in need of improvement and troubleshoot end user reported problems better.  However the first portion of the methodology is collecting KHI's or Key Health Indicator reports from performance monitor.  I've found this article at Flinchbot to be pretty helpful in deploying the KHI's as well as triggering the stop and start of log collection.  But then the very manual process of collecting average and maximum values from multiple servers and days.

So I wrote this little thing in Excel.  If you find errors, let me know, I won't claim to be a programmer, so this is free and completely at your own risk.  I tried to make it simple.

  1. Name your CSV's something like "Server - Date.csv"  Each file will be a new tab.
  2. Edit the xlsm document with the folder where your CSV's are stored (E14)
  3. Click "Summarize KHI CSVs"
  4. Wait a bit.   Some of these files are large and the operation may make Excel hang or seem unresponsive for a bit.  I promise, I couldn't code a virus to save my life.
  5. The output provides each counter with the Average and Max value, one sheet in the workbook per CSV provided.
Sample of interface:

Sample of Output





Download from Technet Here

Demonstration Video
Excuse the interface, I prettied it up before posting it!

Thursday, August 21, 2014

How to view your "Cloud Only" users in Azure AD Powershell

I ran into an issue recently with a customer who had populated their cloud with users manually, and then ran DirSync to synchronize 1000s of user accounts.   We then had a need to audit the cloud only accounts and come up with a plan to remove them.   I found this to be a very effective way to address this.

Get-MsolUser -All | where { $_.ImmutableId -eq $null }

The ImmutableId field is created when users are synchronized from an external directory, so users without a ImmutableId are not from Active Directory.