Important news about Shared Mailboxes in Exchange Online

Friday, June 22, 2018
Microsoft is announcing some technical changes and enforcements to Shared Mailboxes in Exchange Online. See, "Correcting Shared Mailbox provisioning and sizing" on the Exchange Team blog.

tldr; "Do as I say, not as I do."

For a long time the documentation has stated that Shared Mailboxes over 50GB in size require an Exchange Online license, but in reality customers have been able to create Shared Mailboxes up to 100GB. The 50GB limit has not been enforced until now. In order to reduce issues associated with this technical change, existing Shared Mailboxes in EXO are grandfathered in, but will come under these new limits if they are reconfigured. The blog does a good job of explaining when and
how the enforce limit will apply in several scenarios. I encourage you to read it.

The bottom line is that Shared Mailboxes under 50GB still do not require a license. Shared Mailboxes over 50GB require an Exchange Online P2 license.

All this highlights an important point - you should always design and support your IT policies and infrastructure based on the documentation, not what the actual behavior is. Microsoft can choose to implement limits and technical blocks at any time to match the written documentation. You should never be out of compliance.

Read more ...

AAD Connect 1.1.819.0 now includes new Device Options and PingFederate Integration

Thursday, May 24, 2018
Microsoft released AAD Connect version 1.1.819.0 which includes several notable changes and improvements.
  • This release includes the public preview of the integration of PingFederate in Azure AD Connect. With this release customers can easily and reliably configure their Azure Active Directory environment to leverage PingFederate as their federation provider.
  • Updated the Azure AD Connect Wizard Troubleshooting Utility, where we now analyze more error scenario's, such as Linked Mailboxes and AD Dynamic Groups.
  • Device Writeback configuration is now managed solely within the Azure AD Connect Wizard.
  • A new PowerShell Module called ADSyncTools.psm1 is added that can be used to troubleshoot SQL Connectivity issues and various other troubleshooting utilities.
  • A new additional task "Configure device options" has been added. You can use the task to configure the following two operations:
    • Hybrid Azure AD join: If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both joined to your on-premises Active Directory and your Azure Active Directory.
    • Device writeback: Device writeback is used to enable conditional access based on devices to AD FS (2012 R2 or higher) protected devices.

To begin using PingFederate as your IDP, select "Change user sign-in" from the AAD Connect main menu and then select "Federation with PingFederate".

The wizard will walk you through connecting Active Directory and will produce a text document with instructions on how to configure PingFederate server with Office 365. Once done that's done, it converts the O365 tenant to federation-managed. Finally, it will validate the federated sign-in.

To configure the new Device Options for AAD-joined devices, click "Configure device options" on the main menu. After you authentication to Azure AD you'll see this summary:

When configuring Hybrid Azure AD join, AAD Connect will offer to create the service connection point (SCP) in Active Directory which is used by your devices to discover your AAD tenant information. It also offers to create a PowerShell script that will create the SCP, in case the account used to run AAD Connect does not have the rights to create the SCP itself.

Next, you select the operating systems in your environment (Windows 10 and/or supported Windows downlevel domain-joined devices). Supported downlevel devices include Windows 8 and earlier.

Once completed, you will need to perform some post configuration tasks for Hybrid Azure AD join, which includes controlling rollout, GPO entries for device registration, and other tasks outside the AAD Connect configuration.

As usual, this build also includes numerous fixes which can be read in the AAD Connect version release history. Most notably, this release updates the SQL Server Express installation to SQL Server 2012 SP4, which, among others, provides fixes for several security vulnerabilities.

Most customers will receive this upgrade automatically as long as Auto Upgrade is enabled. Others can download the latest version of Azure AD Connect here.

Read more ...

Exchange and SPF, DKIM, and DMARC. Oh my!

Wednesday, May 2, 2018

Email security should be top-of-mind for any organization. Being that the SMTP protocol does not provide much (any) security or authentication natively, we rely on frameworks and extensions to provide these capabilities. Here's a quick primer on what they are, how they work, and how you can protect your organization.

  • Sender Protection Framework (SPF) - SPF provides a way for you to list permitted IP addresses that send email for your SMTP domain. An SPF (TXT) record is created in the public DNS zone for the SMTP domain. The statement includes all the IPs that are allowed to send emails for that domain and a recommendation on how the recipient server should treat emails from other sources.

  • DomainKeys Identified Mail (DKIM) - DKIM digitally signs all outbound emails and provides an easy way for receiving SMTP servers to verify that the incoming message comes from a legitimate server. Signing is typically done using a transport agent as the email exits the sending organization.

Both SPF and DKIM go a long way to confirm that an email is coming from a legitimate source, but both have their shortcomings. When SPF was originally announced, there wasn't much good documentation and a lot of customers implemented it incorrectly. This caused email deliveries to fail and organizations sometimes couldn't trust it. DKIM works great for confirming that a message is indeed legitimate, but doesn't specify what to do when messages are not DKIM signed. If a message comes without a signature, there's no easy way for a receiver to know that it should have been signed, and in that case it's most likely not authentic. That's where DMARC comes in.

  • Domain Message Authentication Reporting & Conformance (DMARC) - DMARC is simply an enforcement statement in DNS that defines that SPF and/or DKIM are used by the SMTP domain and what the receiving server MUST do with emails that do not align with SPF or DKIM. It also provides a way for recipients to report invalid emails.

This combination of mechanisms are used to attest that emails sent by your organization are really from you. They don't prevent inbound spoofing or spam emails from other domains, but if everyone implemented SPF, DKIM, and DMARC it would help enormously. More and more organizations are requiring SPF, DKIM, and DMARC for sent emails, otherwise they're more likely to treat them as spam. It behooves you to get these setup for your organization as soon as possible.

On March 15, 2018 Office 365 implemented some stringent email security changes to the service which caused a tremendous amount of email to go into customer's Junk Email folders. This was because the changes "Junked" emails from senders without SPF, DKIM, and DMARC. The changes had to be rolled back quickly, but were reimplemented a week later with different logic. Read, Anti-spoofing protection in Office 365, to understand some of those changes and how EOP protects you from inbound spoofing and phishing attacks.

SPF, DKIM, and DMARC for Exchange Online

If your organization is using Office 365 you can use SPF, DKIM, and DMARC to protect your email and SMTP namespace. Office 365 provides a DKIM mechanism that is configurable from the Exchange Admin Center. When this is enabled for each SMTP domain, DKIM signs all outbound messages from your tenant. Even if your hybrid organization uses Exchange Server on-prem, but uses Exchange Online Protection (EOP) for outgoing email, all outbound emails can be signed by Office 365's DKIM.

SPF, DKIM, and DMARC for Exchange Server On-prem

If your organization uses Exchange on-premises there are a few options, but none of them are native to the product itself. Usually the best option is to employ an SMTP gateway that provides DKIM signing. This gateway can be a physical or virtual on-prem appliance, such as a Barracuda or IronPort, or it can be a cloud service, like EOP.

Another option is to use the DKIM Signing Agent for Microsoft Exchange on GitHub. This is an Exchange transport agent that signs all outbound emails with a DKIM signature. You start by defining your sending domains, create a public/private key pair, and installing the DKIM signing transport agent. See fellow MVP Jaap Wesselius' article on this for details. After configuring the agent and updating DNS, your Exchange Server will use DKIM signing. Note that you'll need to install and configure this agent on all your Exchange Hub Transport/Mailbox or Edge Transport servers to ensure all your outgoing emails are DKIM signed. You may also need to upgrade the DKIM signing agent after each Exchange cumulative update since the transport stack is subject to change.

Testing SPF, DKIM, and DMARC

There are several SPF/DKIM/DMARC testing sites I use to ensure these mechanisms are set up properly. I particularly like the AppMailDev DKIM test. You just go to the website to get a testing email address, send an email to that address from the system you want to test, and it tells you if your message passes SPF, DKIM, and DMARC in real-time.

SPF, DKIM, and DMARC protected email from Exchange 2016

Talk with the experts at EXPTA Consulting to discuss your messaging and security needs. Improve email delivery and stop email bounces, spam, and phishing attempts. We can help you with your SPF, DKIM, and DMARC implementations. Contact us today!
Read more ...

Azure AD Connect version 1.1.751.0 released for download only

Wednesday, April 18, 2018
Microsoft just published Azure Active Directory Connect version 1.1.751.0. This is a big fix version that resolves two specific issues:

  • Corrected an issue where automatic Azure instance discovery for China (21Vianet) tenants was occasionally failing.
  • For AD FS there was a problem in the configuration retry logic that would result in an ArgumentException stating "an item with the same key has already been added." This would cause all retry operations to fail.
Since these issues only affect a small number of users this build will not be deployed via Auto Upgrade. Affected users will need to download this version directly from the AAD Connect download site.

Read more ...

Cross-Premises Mailbox Delegation in Hybrid Office 365

Tuesday, April 3, 2018
Exchange hybrid organizations commonly ask about delegating mailbox permissions between on-premises and cloud users. I'm happy to say that this is finally becoming a reality. This is being rolled out to all Office 365 tenants by the end of April 2018.

Gone are the days when you had to migrate users with delegated permissions at the same time to keep delegation working when migrating to Exchange Online. To enable cross premises delegation you first need to configure it in Exchange on-prem with the following cmdlet:
Set-OrganizationConfig -ACLableSyncedObjectEnabled $true
This is all you need to allow an on-prem user to become a delegate of a cloud user's mailbox.

If you want to allow a cloud user to become a delegate of an on-prem user, you need to reconfigure the msExchRecipientDisplayType attribute for the remote mailbox in on-prem AD. This will allow the cloud user mailbox to become ACLable. The default value for a mailbox that has been migrated from on-prem to Exchange Online is -2147483642. This value must be changed to -1073741818.

The following on-prem cmdlet will change the value for a particular mailbox:
Get-ADUser -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}
And this cmdlet will change the value for all migrated mailboxes:
Get-ADUser -Filter * -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}
Once this is done, the cloud users can become delegates for on-prem users. Note that there is no need to force directory replication using AAD Connect. It just works.

Here's how this looks in Outlook. First, I'll show how it looks before I run the cmdlets.

Begin by clicking File in Outlook and then Account Settings > Delegate Access. This will open the Delegates dialog box.

Remote user is not ACLable

Click Add to open the Add Users window. Notice that my Jeff Guillet account has a red circle with a line through it. That means my mailbox is not ACLable. If I try to delegate to that mailbox I get the error, "The user cannot be added. Non-local users cannot be given rights on this server."

After I run the cmdlets above, I follow the same steps. Now my Jeff Guillet user account can be added for delegation.

Remote user is now ACLable.

I can now configure the level of delegation and optionally send the delegate an email summarizing these permissions.

For details on Full Access, Send-As, and Send-On-Behalf-Of permissions in a hybrid environment, please read Overview of delegation in an Office 365 hybrid environment.

Read more ...

Join me at the Microsoft Tech Summit in San Francisco March 19-20!

Friday, March 16, 2018

Please join me for the Microsoft Tech Summit San Francisco March 19-20, 2018 at the Marriott Marquis in downtown San Francisco. Register here.

On Monday, March 19, I'll be at the "Ask The Experts Networking Hour" at 5:45PM PDT. This will be an opportunity for attendees to interact and learn from industry peers and representatives from Microsoft.

Then on Tuesday, March 20th, I'll be presenting, "Running Exchange hybrid over the long term" at 10:45AM PDT.
When you connect on-premises Microsoft Exchange Server to Exchange Online through a hybrid environment, are you creating a short-lived bridge to migrate to the cloud? Or will this hybrid live on indefinitely, waiting for internal and external policy to support a cloud-only reality? Either way, make sure you catch this session to learn best practices of running a hybrid Exchange environment. Topics addressed include: maintaining hybrid across patching cycles and upgrades; accommodating changes to network models; adapting during acquisitions and mergers; and more.
While I'm there, you can reach out to me to see how EXPTA Consulting can help you with your IT projects. Please join me and I look forward to seeing you in San Francisco!
Read more ...

Storing email signatures in the Exchange mailbox

Thursday, March 15, 2018

A common complaint is that users must configure their email signatures every time they configure their mailbox on a new Outlook client or in OWA for the first time.

The current email signature behavior in Exchange and Exchange Online is that users must create new signatures every time they add a new mailbox in Outlook and in each of the Outlook apps. OWA already stores a text and HTML signature in the mailbox, but Outlook doesn't use it. OWA also does not provide for different signatures or a different reply signature like Outlook does. That's very inconsistent behavior.

In a recent discussion with the Exchange and Outlook product groups, the MVPs discussed a long-standing request - to store email signatures in the user's mailbox. Doing so will provide a centralized place to store and retrieve the signatures and provide consistency for the email clients that consume them (Outlook for desktop, Outlook on the web (OWA), and the Outlook apps (iOS and Android)). We are also requesting that signatures can be managed via PowerShell.

The product groups challenged us to show that customers want this by vote count on UserVoice. Please vote for the "Store Signatures in the mailbox" idea on UserVoice website to make your voice heard. I've written a spec for this feature, which I will be submitting to the PGs once the vote count gets higher. Our expectation is that this will work for both Exchange Server and Exchange Online.

Please up-vote this feature request and let's see if we can get this one done!

Read more ...