An Overview of Tenant to Tenant Migrations in Office 365

Wednesday, September 18, 2019

Recently I wrote a chapter for the eBook, "Everything you need to know about Tenant to Tenant Migrations" for Practical 365. You can download the eBook for free here.

You can read a quick teaser for that chapter here on the Practical 365 site.

Read more ...

Syncing Email Signatures Across Devices is soon to become a reality!!

Tuesday, September 10, 2019
Will wonders never cease. Just when I was convinced that Outlook UserVoice was the place where all good ideas go to die, I received the following update:

"Thank you to everyone who voted. We’re happy to report that we’re working on sync’ing signatures across devices. More details to come as we have them.


Ricardo, Duncan, Sunder and David on behalf of the Outlook team"

After I posted the article, "Storing email signatures in the Exchange mailbox" on this blog, this UserVoice request became the top voted request on the Outlook UserVoice website by a wide margin, with over 7,915 votes. It has more than twice the number of votes than the #2 most voted item. Thank you to all of you who voted!

This new feature will undoubtedly come to Office 365 ProPlus customers first, so if you're hot on seeing it, make sure you're using the latest and greatest version of Outlook. I'll let you know when the new feature lands.

Read more ...

Video Tutorial on Hybrid Azure AD Join

Thursday, August 22, 2019

Microsoft produced this short (7:21) video which shows how to configure Hybrid Azure Active Directory Join in your on-premises environment. Hybrid AAD join is an important step in using Intune to manage your corporate devices and information. With device management in Azure Active Directory (Azure AD), you can ensure that users are accessing your resources from devices that meet your standards for security and compliance.

This video will be included in future hybrid AAD join documentation to be published in the next few days and weeks. You can view it at

Read more ...

Managing SSL certificates may be getting that much more difficult

Wednesday, August 14, 2019
Remember when you used to be able to get an SSL certificate that lasted 3-5 years? Now you can only get one that lasts 2 years, and a change proposed by Google would reduce the maximum validity period to just 13 months beginning March 2020. This would be a global change to the industry, impacting all certificate authorities.

Read this important update from Digicert:

Dear Security Professional,

We are reaching out to you regarding an important proposal raised recently at the CA/Browser Forum that could impact the products you are using.

What’s happening?
Google proposed a change that, if the ballot passes, will reduce the validity period of certificates from the current maximum of two years to 13 months. The proposed ballot was endorsed by Apple and another CA, making the ballot eligible for voting. If the ballot passes at the CA/Browser Forum, the change in requirements will go into effect in March 2020. Any certificates issued after the effective date would need to comply with the shortened validity period requirements. Even if the ballot fails, the browsers sponsoring the ballot could unilaterally implement this requirement in their root program and make compliance required for certificates issued by trusted CAs in their root stores.

This change is a follow up on Google’s previous initiative to reduce lifetimes from three to two years in 2018.

Who is impacted?
The changes proposed by Google would impact all publicly trusted TLS certificate users, regardless of which certificate authority issues the certificate. If the ballot passes, all publicly trusted certificates issued or re-issued after March 2020 would have a maximum validity of 13 months. Customers using certificates with validity periods longer than 13 months are encouraged to review their systems and evaluate how the proposed changes might impact their deployment and use of certificates.

Please note that all TLS certificates issued prior to March 2020 with a validity period longer than 13 months will remain functional. This ballot does not affect non-TLS certificates, including code signing, private TLS, client certificates, etc. There will be no need to revoke any certificates as a result of this ballot.

This would be a global change to the industry, impacting all certificate authorities.

DigiCert’s position
DigiCert believes industry-wide changes should be made only after measuring whether the changes in security are sufficiently balanced with the impact on end users. In this case, we feel that further shortening certificate lifetimes, especially absent reasonable timelines for companies to prepare, would have the opposite effect in causing significant pain to customers and possibly leading to some human-caused errors as they scramble to adjust.

We believe the goal of improving certificate security is better served by allowing more time for companies to continue their growing use of automation and to prepare for these changes. DigiCert would like to continue the conversation and gather customer input before this issue is brought to a ballot. We think this discussion should include a timeline that allows for companies to properly plan for shorter lifetimes.

Regardless of the outcome of this ballot, we stand ready to help our customers. DigiCert’s focus and deployment of discovery and automation tools make sure our systems are fully capable of helping our customers meet changes that may arise in industry standards, including shortening lifecycles. In fact, DigiCert currently offers certificate lifetimes as short as eight hours for customers who want that option. Having said that, our ability to help our customers with these changes doesn’t mitigate all the potential impact that a rushed implementation would have on the industry.

What to do
The CA/Browser Forum makes changes to standards as security issues evolve. To remain compliant with these changes, organizations with large amounts of certificates should consider sophisticated automation tools to help manage certificate inventories and ease certificate deployment. At DigiCert, we are focused on simplifying the certificate management process and developing new tools for automating certificate use. Customers worldwide use DigiCert to automate their process using our Lemur plug-ins, REST APIs, SCEP and EST services, and ACME service. Combining ACME with the automated scanning service in CertCentral allows TLS customers to easily scan their entire environment, find certificates that require replacement, and deploy up-to-date technology.

DigiCert will continue to keep you apprised of CA/B Forum activities. Please read our position to the industry in this new blog:

Be heard
The CA/Browser Forum accepts comments from outside participants; however, all discussions are public. You have two choices: you can submit your comments to DigiCert through this survey, which we plan to summarize and provide to the CA/B Forum or you can join the CA/B Forum as an Interested Party, which will allow posting of your comments directly to the Forum mailing list. See (bottom of page).

We are eager to share information with the browsers about the impact these changes may have on customers. We look forward to providing this information and representing your interests in the Forum and security world.

Read more ...

How to Create a Hub Transport Rule Based on Any Attachment

Tuesday, August 13, 2019
Transport rules are cool. Except when they don't work the way you expect.

I wanted to create a transport rule that blocks outgoing email to external recipients that contains an attachment, except for members of the "Allow Outbound Attachments" group. So, I created the following rule:

The trouble is, that it blocks any email that is not sent as plain-text, even though there is no attachment. Not good.

I examined the headers on emails with and without attachments and found the X-MS-Has-Attach X-header has a yes value when there's an attachment and is <blank> when there isn't.
...Message-ID: <>References: <>In-Reply-To: <>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator:Authentication-Results-Original: spf=none (sender IP is )...
I modified the rule as below and it now works perfectly.

It's worth noting that the header values are not cAsE sensitive.

Read more ...

Authoritative vs Internal Relay Domains in Exchange

Thursday, July 25, 2019
tl;dr: Ensure the accepted domain(s) in Exchange Online are configured as Authoritative, not Internal Relay, even if you're in hybrid, to take advantage of Directory Based Edge Blocking.
Those of you who have worked with Exchange Server for a long time and those familiar with cross forest migrations will probably know about Authoritative vs. Internal Relay domains. When a domain is set to Authoritative, email is delivered only to valid recipients in the Exchange organization. With Internal Relay domains, email is delivered to recipients that exist in the Exchange organization and other emails are relayed to another email server in a different location.

I've seen a number of customers (especially Exchange hybrid customers) configure their domains on-premises or in Exchange Online Protection as Internal Relay, thinking that this is required in order to relay emails on-premises or to their tenant. This isn't necessary because emails will still relay between on-prem and EXO using the targetAddress (aka external routing address) value, which always happens even if the domain is set to Authoritative.

Why is this a big deal? Well, Exchange Online online has a feature called Directory Based Edge Blocking (DBEB), which rejects messages for invalid recipients at the service network perimeter. Exchange Edge Transport servers will do the same thing for on-prem. DBEB prevents Exchange from accepting invalid emails, scanning them for malware and spam, perform rules processing, etc. when they have no hope of being delivered to a bad email address.

If a domain is set to Internal Relay, DBEB can't work since it would block unknown emails from being relayed to another server. With DBEB, Exchange performs a directory lookup before it even accepts the email. If the recipient address doesn't exist, Exchange rejects the email with a 550 5.4.1 Recipient address rejected: Access denied error. RFC states it's up to the sending server to generate the NDR back to the sender.

Read more ...

Keep your Exchange Federation Trust up-to-date

Monday, July 8, 2019
From time to time, Microsoft refreshes the certificate used by the Microsoft Federation Gateway service in Office 365. They just did this again on July 5, 2019. The MFG is the trust broker used by hybrid organizations and by other on-premises orgs that share free/busy information between them. Most Exchange configurations will update the federation trust metadata automatically, but if your on-premises org is running Exchange 2010 or Exchange 2013 on Windows Server 2008 you will need to update this manually.

Begin by testing to see if the metadata is up-to-date in your org by running the Test-FederationTrust cmdlet in EMS from one of your Exchange servers. The cmdlet normally does not require any switches to run.

Exchange will check AD to confirm that the Federation Trust configuration object exists and is valid, the Token Issuer certificate is valid, and then request a delegation token from the MFG. Here's what a good test looks like in Exchange 2010:

Test-FederationTrust from Exchange 2010
Exchange 2013+ performs a few more detailed tests using a built-in test account:

Test-FederationTrust from Exchange 2013
If you see any validation errors, such as the following error, you will need to update your MFG refresh token manually:
Id : TokenValidationType : ErrorMessage : Failed to validate delegation token.
You can update AD with the latest Microsoft Federation Gateway certificate one time by running the following cmdlet from EMS on any Exchange server in your org:
Get-FederationTrust | Set-FederationTrust –RefreshMetadata 
Once updated, run the Test-FederationTrust cmdlet again to confirm the validation and delegation token is valid.

If you want to automate this process, you can create a scheduled task on one of your Exchange servers to update the federation trust once per day. Nothing will actually update in your environment unless Microsoft updates their MFG certificate. Run the following from an elevated CMD prompt or EMS window to create the scheduled task:
Schtasks /create /sc Daily /tn FedRefresh /tr "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata" /ru System
Remember, you will only need to do this if your organization runs Exchange 2010 or Exchange 2013 on Windows Server 2008. Later versions of Windows allows Exchange to update the federation trust certificate automatically.

Read more ...