Feed aggregator

Upcoming changes to Exchange Web Services (EWS) API for Office 365

Exchange Team Blog - Tue, 07/03/2018 - 14:28

Over the last few years, we have been investing in services that help developers access information in Office 365 in a simple and intuitive way, specifically through Microsoft Graph.  Microsoft Graph and the use of OAuth 2.0 provide increased security and seamless integration with other Microsoft cloud services and is rapidly expanding developer access to the rich data sets behind Microsoft applications.  

As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Today we are sharing our plans to move away from Basic Authentication access for EWS over the next two years, with support ending Oct. 13, 2020.   

These plans apply only to the cloud-based Office 365/Exchange Online products; there are no changes to EWS capabilities of on-premises Exchange products

Exchange Web Services will not receive feature updates 

Starting today, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. 

While we are no longer actively investing in it, EWS will still be available and supported for use in production environments.  However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality. For more information and details on how to make the transition, please refer to the following articles: 

While EWS and Graph have mostly overlapping functionality, there are some differences. If you rely on an EWS API that does not have a Graph counterpart, please let us know via UserVoice of features needed for your app scenarios.   

Basic Authentication for EWS will be decommissioned 

Exchange Web Services (EWS) was launched with support for Basic Authentication. Over time, we've introduced OAuth 2.0 for authentication and authorization, which is a more secure and reliable way than Basic Authentication to access data. Please refer to the following article for more information: 

Getting started with OAuth2 for Microsoft Graph 

Today, we are announcing that on October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online. This means that new or existing apps will not be able to use Basic Authentication when connecting to Exchange using EWS.  

Next Steps 

The deprecation of these APIs follows our service deprecation policies. We understand changes like this may cause some inconvenience, but we are confident it will ensure more secure, reliable, and performant experiences for our customers. 

We're here to help if you need it. If you have questions, please let us know in Stack Overflow with the [MicrosoftGraph] tag. 

Thank you in advance for updating and opening your apps to a wider range of useful and intelligent features on Microsoft Graph. We are extremely excited about the growing opportunities that Microsoft Graph offers to our customers, and we remain fully committed to continue our journey to empower developers to access Office 365 data with the most modern features and tools. 

Frequently Asked Questions  

Q: Will my application stop working when you make this change? 

A: It might, yes, it depends on the app itself and how it was coded. If it’s using EWS, and if it’s using Basic authentication then yes, on October 13th 2020 it will fail to connect. However, if the app is using Modern Auth/OAuth, then no, it will keep working as it did before.  

Q: Why October 13th 2020? Why that date? 

A: Starting October 13, 2020, Office 365 ProPlus or Office perpetual in mainstream support will be required to connect to Office 365 services. This announcement is posted here Office 365 ProPlus Updates.  

This change requires that Office 2013/Office 2016 are also required to use Modern Auth. Please see this.

Q: Our in-house team created an app for meeting room scheduling, how do we go about changing that over to Graph and OAuth2.0?  

A: Don’t forget you can keep using EWS if you want to, so then really, it’s just the question of authentication. To get a better understanding of how to use OAuth 2.0 take a look here.

Q: How does this impact my On-Premises Exchange deployment? 

A: It does not. This change only affects Exchange Online.  

Q: We require Modern Authentication + Multi Factor Auth for all our Outlook users connecting to O365, how do apps work when I have that set as a requirement? 

A: Applications can be written so they are treated as ‘trusted applications’. That way they can bypass the MFA requirement, more details are here.

Q: How do I know which of my apps use Basic authentication to EWS? 

A: If you only Outlook to connect to Exchange Online then you don’t need to worry, as long as you are using Office 2019 or Office 2019 Pro Plus you’ll be fine come October 2020. However, if you also have integrated apps into your Office 365 tenant you’ll need to check with the application developers to verify how it authenticates to Exchange Online if you aren’t’ sure. We are investigating how we can share this information with tenant admins, but have nothing available at the time of writing this blog.  

Q: What features does EWS have that Graph can’t provide? 

A: Graph is constantly evolving and adding features and functionality to provide the richest set of experiences we can. To see the latest features we’ve added to Graph, go here Overview of Outlook mail API on Microsoft Graph 

Q: Will this affect my Exchange Hybrid configuration? Exchange On-Premises calls into Exchange Online using EWS doesn’t it? 

A: Yes, it does. But it doesn’t use Basic Authentication, it uses token-based authentication, and it’s described in this blog post. How Hybrid Authentication Really Works.  

The Exchange Team

XG-7100 Desktop Available for Pre-order

pfSense Blog - Mon, 07/02/2018 - 19:00

You might have heard about our new XG-7100 Desktop pfSense® Security Gateway Appliance. It was mentioned in our May and June Newsletters. For a quick synopsis, read on…

Resource Based Throttling and Prioritization in Exchange Online Migrations

Exchange Team Blog - Mon, 06/25/2018 - 10:33

We often get questions about throttling in Mailbox Replication Service (MRS) based migrations in Exchange online. When migrating, you may see messages such as StalledDueTo_TargetDiskLatency for some periods of time. These messages come from our resource-based throttling infrastructure in Exchange Online.

This is how this would look like in the output of Get-MoveRequestStatistics:

PS C:\> Get-MoveRequestStatistics <user> | fl Status,StatusDetail
Status : InProgress
StatusDetail : StalledDueTo_TargetDiskLatency

Or in a move report, you may see:

The job has been paused temporarily due to unfavorable server health, with request throttling state: 'StalledDueToTarget_DiskLatency'.

We throttle and prioritize work in the Exchange Online service based on priority and resource load. The highest priority is the end-user experience, so some workloads like OWA access, Outlook access, and email delivery are the highest priority. Other things, like select mailbox assistants and customer migrations, are in the second tier but with lower priority than client access and mail flow. There are also some even lower-priority workloads such as load-balancing mailbox moves, maintenance, and other discretionary tasks. We throttle lower priority workloads at the point where they could degrade the end-user experience or the performance of higher priority workloads. For instance, we throttle migrations when they might negatively impact OWA access or email delivery.

Take this example: As a customer, you migrate your data to Exchange online. Imagine one day you receive a notification stating: “Your email delivery will be delayed by 1-2 hours today to allow another customer to migrate to Exchange Online more quickly.” You would not accept this scenario and we don’t either. We absolutely understand migration is important, but it is not the highest priority workload in Exchange Online.

In summary, there are some things you should understand to make your migration experience go smoothly.

  1. The throttling you see is not per-user or per-tenant. We throttle only based on resource load in MRS-based migrations. So, when you see a message indicating a stall, it is simply happening to preserve the overall health of the Exchange Online service. We do not have any ability to lift MRS migration throttling for a particular tenant or user. Additionally, you may get better migration throughput during off-peak hours since the resources consumed during these times will probably be lower.
  2. Seeing a “StalledDueTo” or throttling message does not mean that Office 365 has a problem. You should expect some amount of throttling in any migration you perform. This throttling may occur at unpredictable or inconvenient times; you should plan your migrations accordingly. There is no action you need to take; the migration will resume automatically when resources become available.
  3. Do not set very short timelines for migrations of individual user mailboxes, because you are unable to predict migration resource availability in Office 365. Instead make sure you complete the initial sync well ahead of time and complete the migrations at a later time.

Note: Some migration stalls can originate from the on-premises environment. It’s important to take note of the directionality of the stall. If the message says “Source” and you are moving mailboxes to Exchange Online, it means the stall is from the on-premises environment. Likewise, if the message says “Target” and you are moving mailboxes from Exchange Online (back to on-premises), the stall is also originating from the on-premises environment.

Brad Hughes

Update on mail flow insights

Exchange Team Blog - Fri, 06/22/2018 - 11:58

Last month, we announced the release of mail flow insights in the Office 365 Security & Compliance Center in this blog post. We're making changes to the mail flow insights dashboard to make it more intuitive. These changes are currently in deployment, and will be available in the week of June 25, 2018.

We've changed some widgets in the mail flow dashboard, as shown in the following screenshot:

We've combined the TLS report for inbound and outbound email traffic and the connector report into one widget. Clicking View details will give you all the TLS status for your organization, and the connector report link will lead you to the detailed connector report. We will retire the TLS report in the near future since it's no longer needed.

We've changed the "Forwarding overview report" widget to "Auto-forward messages" to give you a quick summary of the auto-forwarding status for your organization:

Click the message number in the "Auto-forwarded messages" widget and the flyout will show the auto-forwarded message status. You can see the details by clicking "Forwarding Report" link, as shown below:

We encourage you to take advantage of mail flow insights in the Office 365 Security & Compliance Center. We will continue to improve the current insights as well as add new insights, and we're looking forward for your valuable feedback.

Carolyn Liu

Correcting Shared Mailbox provisioning and sizing

Exchange Team Blog - Thu, 06/21/2018 - 12:00

We are correcting how shared (and resource) mailboxes are created in Exchange Online.

As per our documentation (here and here), shared and resource mailboxes in Exchange Online should be created with the size of 50GB and if a larger size is desired, a license should be assigned to the mailbox. For some time now, though, while our documentation has (correctly) stated this, the Exchange Online system would, for many of our customers, create both new shared and resource mailboxes with a default size of 100GB even if a license was not assigned. We knew that this was happening, and we were working to address this in our mailbox provisioning system.

This is what is now being corrected to the documented behavior.

The new shared or resource mailbox creation behavior (starting end of July) will by default be 50GB, as per our documentation – and if you require a shared mailbox that is larger than 50GB, an Exchange Online Plan 2 license will need to be assigned to it. Once a license is assigned, the mailbox size should quickly increase to 100GB (equivalent size for an Exchange Online Plan 2 licensed user mailbox).

To help you with understanding how this change might impact your existing shared mailboxes and what the behavior is going forward, we have prepared the following Q&A:

When the 50GB shared mailbox creation correction goes into effect, will all the already created unlicensed shared mailboxes with a default size of 100GB be automatically switched to 50GB?

No, not automatically; but they could revert to 50GB under certain situations, read on to understand these scenarios.

When would a currently unlicensed shared mailbox lose its existing 100GB status?

Changing the state of the license on the mailbox will apply the corrected 50GB default state. If license on the mailbox is changed, the 100GB status for that mailbox will be irreversibly lost and to increase the mailbox size back to 100GB, an appropriate license will be required.

I currently have an unlicensed 100GB shared mailbox with 80GB of data and I need archiving for it. What will happen if I assign the Exchange Online Archiving license?

Any change to the licensing state of the shared mailbox will make the shared mailbox lose its 100GB status. In other words – even assigning the Archiving license only to a currently unlicensed shared mailbox will change the mailbox quota to 50GB and an Exchange Online Plan 2 license (or equivalent) will be needed to increase the mailbox size to 100GB. In this scenario, if you wanted to assign an Archiving license, you would also need to assign at least an Exchange Plan 2 license.

When this change goes into effect, let’s say I have an 80GB user mailbox and want to convert it to a shared mailbox. What will happen?

When mailbox conversion happens, the currently assigned license will stay assigned on the mailbox (by default) and shared mailbox will keep sending/receiving email. If you then remove the license from this converted shared mailbox, the 50GB mailbox quota will get enforced. The mailbox size will still be 80GB, but because the mailbox will be over quota, sending and receiving of email will not work (incoming email will error with “Mailbox is full” error, code 5.2.2). Assigning the required license to the mailbox again will resolve this problem (this change might take a little bit of time). If you intend to use a shared mailbox larger than 50GB actively, we recommend that you keep the license assigned after conversion so there are no work disruptions. You are also able to leverage Inactive Mailboxes if you just need to keep mailbox data around in inactive state.

If I have a user mailbox that is under 50GB in size and convert it to a shared mailbox – what will happen?

When mailbox conversion happens, the license will stay assigned on the mailbox (by default). If you remove the license, the mailbox will still be available for sending and receiving email because the size of the converted shared mailbox is under 50GB and shared mailboxes under 50GB do not require a license. If the size of this shared mailbox goes over 50GB, you will need to add a license to it (to increase its size to 100GB) or remove some email from it (to stay under the 50GB).

If I have a shared mailbox that is approaching 50GB and need it to be larger, what should I do?

Simply assign it an Exchange Online Plan 2 license; you do not need to do anything else. Shared mailbox size will be increased to 100GB automatically within 15 minutes.

Licensing change already went into effect. I just converted a 50GB unlicensed shared mailbox into a user mailbox and now I have a 50GB user mailbox. What’s going on?

When you convert an unlicensed mailbox from shared to user (using Exchange Admin Center, for example), the resultant mailbox will be an unlicensed user mailbox (because the starting shared mailbox did not have a license). This mailbox is not ‘attached’ to an account as there is no license assigned. When the license is assigned to the user, the mailbox will be re-attached to the account and its size will be set according to the license that was assigned to it. So, if you assign a license that gives the user a 100GB mailbox, the mailbox size will be increased to 100GB. Reminder: without a license, such an ‘unattached’ mailbox will be deleted after 30 days (as it does today).

I have an 80GB shared mailbox on-premises and I need to migrate it to Exchange Online. What should I do?

Because the target Exchange Online shared mailbox needs to be larger than the default (unlicensed) 50GB size, the shared mailbox cloud MailUser object needs to be licensed before migration is attempted. Otherwise, the migration attempt will immediately fail with the “Mailbox size exceeds target quota” error. Once the Exchange Online Plan 2 license is assigned, migration can be started.

How can I find out what is the true size of my shared mailboxes?

The easiest way to accomplish this might be to download this script. There are two things to keep in mind:

  • This will not show you sizes of mailboxes that are currently soft deleted
  • If you have shared mailboxes that were not yet logged into, you might get an error during script execution for that particular mailbox; this is just cosmetic

Nino Bilic

Announcing the support for modern public folder migrations without dumpster data

Exchange Team Blog - Wed, 06/20/2018 - 09:49

Long time Exchange administrators will remember that Exchange Server had a feature that was for a while unceremoniously referred to as the “dumpster”. We have since renamed the feature to a more descriptive Recoverable Items Folder. This blog post also contains a bit of history of this feature for those interested.

Up to now, during public folder migration, all the public folder data including dumpsters was migrated from on-premises servers to the cloud. Administrators did not have an option to exclude this data at migration.

We are introducing the ability to migrate public folders to cloud without migrating the dumpster data. To do this, administrators need to pass the ExcludeDumpsters parameter while creating the migration batch. This option can be used when source server version is Exchange 2013 or 2016. Here is an example of how to use this parameter:

New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint $PfEndpoint.Identity -ExcludeDumpsters

Why would you want to do this?

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller.

To check the dumpster folders size, you can run the following:

Get-PublicFolder \NON_IPM_SUBTREE\DUMPSTER_ROOT -Recurse -ResultSize:unlimited | ?{$_.FolderClass -ne "$null"} | ft name,foldersize

In addition to size consideration, we have seen some organizations where dumpster data got corrupted (for various reasons) and administrators did not want that corrupted data migrated to cloud. If you find yourself in that situation, this feature will enable you to leave that data behind.

The obvious drawback to doing this is that users will lose the ability to recover items that were previous deleted from public folders (pre-migration).

Note: The ExcludeDumpsters parameter is optional and if not passed to migration batch, all dumpsters will migrate to cloud. Once you choose to exclude dumpsters and the migration is finalized, there is no way to go back and re-include the dumpsters into cloud public folders. If, during the migration in which you used the ExcludeDumpsters parameter, you decide that you do want to migrate the dumpsters data to the cloud, remove the current migration batch and create another without the ExcludeDumpsters parameter.

This option can be added at point 4 of Step 7 in below TechNet articles for public folder migration (we will work to change the documentation next):

Keep checking this blog for further updates on the subject!

In case of any questions, please do reach out to us via the comments section below.

Public folder team

Released: June 2018 Quarterly Exchange Updates

Exchange Team Blog - Tue, 06/19/2018 - 10:15

The latest cumulative updates for Exchange Server 2016 and Exchange Server 2013 are now available on the download center. An update rollup for Exchange Server 2010 is also available. The updates released today include important changes to the pre-requisites required to install Exchange Server. The installation packages include fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements .NET Framework 4.7.1

As announced previously, Exchange Server 2016 Cumulative Update 10 and Exchange Server 2013 Cumulative Update 21 require .NET Framework 4.7.1. Exchange Setup will enforce this requirement during cumulative update installation. Customers who are running an older version of .NET Framework will need to update their server to .NET Framework 4.7.1 then install the latest cumulative update.

VC++ 2013 runtime library is required

The Exchange Server updates released today require the VC++ 2013 runtime library installed on the server. The VC++ runtime library is required to provide current and future security updates for a third party component shipped with Exchange Server. The component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016. Setup will enforce the installation of the pre-requisite on Exchange Server 2013 and 2016 when a cumulative update is applied. Exchange Server 2010 Update Rollup 22 and later will force the installation of the VC++ runtime before the update can be applied. Future security updates for all versions of Exchange Server will force installation of the runtime package if not already installed. Customers who use Windows Update to patch or update their servers, will need to ensure that the VC++ 2013 runtime package is applied before running Windows Update. Update Rollup 22 and future security updates for all versions of Exchange server will fail to install manually or via Windows Update if the runtime library is not installed.

The packages released today include an updated version of the third party component to resolve the issues identified in Microsoft Advisory ADV180010. Customers are encouraged to apply the updates released today as soon as possible. The Exchange team has previously stated they will not ship security fixes in a cumulative update not previously released separate from a cumulative update. That goal and official plan of record are unchanged. Shipping the updated third party components in a cumulative update was necessary to integrate a new version of the components and a new product dependency not previously required by Exchange in a manner customers are accustomed to with minimal disruption to the Windows Update process.

Important Updates for Exchange Server 2010 Support for Windows Server 2016 Domain Controllers

Exchange Server 2010 Service Pack 3 Update Rollup 22 and later add support for Windows Server 2016 domain controllers. There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

Fix for Exchange Web Services Impersonation in Co-existent Environments

The issue identified in KB4295751 is now resolved in Update Rollup 22. Customers who have Exchange Server 2010 deployed in the same forest as Exchange Server 2016 are encouraged to deploy Update Rollup 22 to ensure that unauthorized access to mailboxes on Exchange Server 2010 does not occur.

Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through May 2018.

Exchange Server 2013 Extended Support

Exchange Server 2013 entered extended support in April 2018. Cumulative Update 21 is the last planned quarterly update for Exchange Server 2013. Customers must upgrade to Cumulative Update 21 to continue to receive future security updates.

Release Details

KB articles that describe the fixes in each release are available as follows:

The updates released today do not include new updates to Active Directory Schema. If upgrading from an older Exchange version or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if the logged on user has the required permissions. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin must execute SETUP /PrepareSchema prior to the first Exchange Server installation or upgrade. The Exchange Administrator should execute SETUP /PrepareAD to ensure RBAC roles are current before applying either of the cumulative updates released today.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., 2013 CU21, 2016 CU10) or the prior (e.g., 2013 CU20, 2016 CU9) Cumulative Update release.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

Hybrid Organization Configuration Transfer

Exchange Team Blog - Mon, 06/18/2018 - 09:29

We are very happy to announce a new feature that will help you the admin reduce the amount of time needed to configure config objects once hybrid setup is complete.

What does this feature do?

This feature enables a one-time transfer of key organization policy objects during the onboarding process from Exchange on-premises to Exchange Online. This feature is tightly integrated into the existing Hybrid Configuration Wizard. The administrator running the HCW can choose to migrate either all the detected objects while onboarding from Exchange on-premises to Exchange Online or choose not to transfer any. This is only a one-time transfer though, to avoid the need to have you set them up manually. Once the one-time transfer is complete, you will need to manually update values in either On-prem or Online to keep them in sync if you change anything.

We’re supporting this config transfer whether you are migrating from Exchange Server 2010, Exchange Server 2013 or Exchange Server 2016, and we’re delivering this feature in phases. Phase 1 will be launched at the end of June 2018. Which is… kind of… pretty much now, really.

What kind of Policy objects are in scope?

The objects we’re including in phase 1 are:

  • Retention Policy
  • Retention Policy Tags
  • OWA Mailbox Policy
  • Mobile Device Mailbox Policy
  • Active Sync Mailbox Policy

However, in phase 1 only new objects/policies will be copied over from on-premises to cloud. Any existing objects/policies in Exchange Online will not be modified.

How do I use this cool new feature?

This feature is completely integrated into the existing Hybrid Configuration Wizard. Just downloading the latest HCW is all you need to do. As you can see from the screenshot, we’ve added a checkbox at the bottom of the Hybrid Features page to allow you to enable this feature and to copy over objects from your Exchange on-premises organization to Exchange Online.

What’s next?

In phase 2, in addition to copying several new objects (Organization Config, DLP Policy, Active Sync Device Access Rule and Active Sync Organization Settings) from on-premises to cloud, the admin will be given a choice to update existing objects in the cloud if the attribute values are different from those on-premises.

We hope you enjoy this new feature and look forward to hearing any feedback or comments, either here on the blog or directly in HCW – we’ve built an awesome feedback system into the HCW and we love to hear what our customers have to say.

Kavya Chandra
Program Manager, Office 365 Enterprise Cloud

Sender Rewriting Scheme (SRS) coming to Office 365

Exchange Team Blog - Fri, 06/15/2018 - 10:02

The introduction of email authentication mechanisms like SPF, DKIM, and DMARC have improved email security and spoofing prevention. However, some scenarios have been disrupted by these authentication mechanisms, namely auto-forwarding and relaying. Here in Office 365, we are committed to ensuring the security of our customers and the general integrity of the email ecosystem that we are a part of.

From July 16th, we will begin rolling out Sender Rewriting Scheme (SRS) functionality to solve the problem of auto-forwarding being incompatible with SPF. The SRS feature will rewrite the P1 From address (also known as the Envelope From address) for all applicable messages being sent externally from Office 365. The From header (also known as Display From address or P2 From address) which is displayed by email clients will remain unchanged. This change will improve deliverability of applicable messages since SPF checks that were failing in the past for such messages will now pass.

Regarding ‘applicable’ messages, we anticipate the following scenarios will be affected and result in SRS rewriting the P1 From address:

  1. Messages that are auto-forwarded (or redirected) from hosted mailboxes using one of the supported methods – SMTP forwarding, Mailbox Rule (or Inbox rule) redirection, Transport Rule redirection.
  2. Messages that are auto-forwarded (or redirected) from our customer’s on-premise environments and relayed through Office 365.

Note: SRS rewriting would also rewrite the P1 From address of messages that are relayed from our customer’s on-premise environment, where the P1 From domain is NOT a verified domain. Customers should only be sending messages from domains in their Accepted Domains list. Find out more about Accepted Domains in Office 365 here.

This change results in Non-Delivery Reports (NDRs) returning to Office 365 instead of the original sender as it occurs today without SRS. Part of the SRS implementation, therefore, is to reroute returning NDRs to the original sender in the case where a message could not be delivered.

Details Auto-forwarding emails for an Office 365 hosted mailbox

A message auto-forwarded for a hosted mailbox by mechanisms such as SMTP forwarding or Mailbox Rule redirection or Transport Rule redirection will have the P1 From rewritten before it leaves Office 365 using the following pattern:

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>


A message is sent from Bob (bob@fabrikam.com) to John's mailbox in Office 365 (john.work@contoso.com). John has set up auto-forwarding to his home email address (john.home@example.com).

Original message Auto-forwarded message Recipient john.work@contoso.com john.home@example.com P1 From bob@fabrikam.com john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com From header bob@fabrikam.com bob@fabrikam.com Relaying from a customer's on-premises server

A message relayed from a customer's on-premises server or application through Office 365 from a non-verified domain will have the P1 From address rewritten before leaving Office 365 using the following pattern:

bounces+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Customer's Default Accepted Domain>

Important: In order to receive NDRs for relayed messages that are rewritten by SRS, a mailbox (either hosted or on-premises) needs to be created with the username 'bounces' and the domain being the default Accepted Domain of the customer.


A message is sent from Bob (bob@fabrikam.com) to John's mailbox (john.onprem@contoso.com) on his company's own Exchange server. John has set up auto-forwarding to his home email address (john.home@example.com).

Original message Relayed message received by Office 365 Relayed message sent from Office 365 Recipient john.onprem@contoso.com john.home@example.com john.home@example.com P1 From bob@fabrikam.com bob@fabrikam.com bounces+SRS=44ldt=IX=fabrikam.com=
bob@contoso.com From header bob@fabrikam.com bob@fabrikam.com bob@fabrikam.com

Find out more about the draft SRS standard that this change is took design ideas from here: http://www.openspf.org/SRS

Sean Stevenson

Data Center Maintenance Scheduled Sunday, June 17, 2018

pfSense Blog - Thu, 06/14/2018 - 19:00

Netgate engineers will be performing planned maintenance within our data center on Sunday, June 17, 2018. The maintenance window will be from 10:00 AM - 10:00 PM CDT. Customers may see interrupted connectivity to services such as the Netgate forum, all Netgate and pfSense web sites, online stores, telephone connectivity, and other resources. Our goal is to successfully complete the task and restore service within the stated time frame.

The Behemoth Router is Here

pfSense Blog - Wed, 06/13/2018 - 19:00

A little over a year ago, I wrote a blog that explained the coming world of high-performance, flexible software-based routers. Seriously disruptive packet processing performance that could change the landscape of networking applications across data centers, the enterprise WAN, service provider networks, and customer premises deployments. No need to recount that here, the principles of the post haven’t changed.

Learn popular pfSense packages with Netgate

pfSense Blog - Mon, 06/11/2018 - 19:00

Netgate® is the only authorized provider of official pfSense® training courses. We have conducted numerous pfSense training sessions online and around the world. We teach network professionals to use and master pfSense software and its powerful packages.

pfSense Now Available To All QNAP Virtualization Station Users

pfSense Blog - Thu, 06/07/2018 - 19:00

A few months back, QNAP approached Netgate® with a request. A growing number of Virtualization Station users wanted more security for their “data center in a box” deployments. QNAP wanted a proven firewall and IDS/IPS solution for their customers and specifically wanted pfSense®. Today, it’s available directly from within the QNAP Virtualization Station store.

Moving the pfSense® Documentation to GitHub

pfSense Blog - Sun, 06/03/2018 - 19:00

We are moving the source for the contents of the old pfSense Wiki to GitHub. This is not a light decision, and has been in the works for some time.

Best practices for using assigned Office 365 DNS records

Exchange Team Blog - Tue, 05/29/2018 - 11:17

As someone who reads through hundreds of support cases each month, nothing pains me more than seeing customers struggling with seemingly complex issues, only to discover that the root cause is quite simple. Never is this truer than it is with DNS. Some of the most complicated security and lost mail issues boil down to a few simple records. In fact, we get well over a thousand tickets per month that could be easily avoided by addressing DNS issues. This blog post could save you time, frustration, even money! Please note that I’m focusing on Office 365 email DNS records here, especially those involved in routing & security decisions – but this advice may be applicable more broadly.

Best Practices List Don’t use legacy DNS records anymore

For several years, we have been doing campaigns to let you know that we’re not going to forever support the use of records like mail.outlook.com, mail.messaging.microsoft.com, mail.global.frontbridge.com, mail.global.bigfish.com, etc. in your MX (mail exchanger) record. However, as of the time of this publishing, we still see over 2000 customer domains that still point to one of these. And that’s just the ones we can easily check in public DNS. There are easily an equal number of on-premises or cloud applications/firewalls/devices which still also appear to be using these records.

Why? Not updating and removing these records means that you’re not getting all the benefits available to you (some of our EOP features simply don’t work). This also increases your risk considerably, as we don’t constantly monitor to make sure all of these records still work like we do with the newer, supported records.

Remove all stale DNS records

It is critical that once you commit to using Office 365, you don’t keep one record pointing to your older routing path. Two variants of this pop up all the time:

  • You move your mail to Office 365, but leave the old MX record (priority irrelevant). This is a terrible idea, because it means that any network glitch anywhere, even on the sending side, can send your mail into a black hole, never to return. Your old provider probably still accepts email for your domain (might not be a bad idea to tell them to stop). Why? This causes mail to go missing. If the other host chooses to reject the mail, senders will get bounce messages (NDRs) from time to time. What’s annoying is that these issues can be very intermittent, or so rare that you may barely notice them and if you do – it can be very difficult to track down.
  • You move your entire domain to a new DNS provider, but forget to remove the zone at the old provider. I see this one with even the most experienced administrators. Why? In short, intermittent missing mails. Most Internet traffic will get the proper, new records because they’ll be using the SOA (start of authority) and NS (name server) records to determine where to resolve the records for your domain. But any customer who is using your old provider for their DNS will still get the old, orphaned information. This is called a DNS split, as multiple servers think they are the authority. More experienced providers will eventually expire the zone files, but some smaller providers might not have a procedure for deleting zones when customers stop paying the bills. And issues with a smaller provider might take weeks, or years to notice. Note that while domain registrars (the ones who list your domain with root servers) usually provide DNS zone hosting, the registrar may not be where the DNS zone (and actual DNS records) is hosted.
Don’t use multiple MX records, especially if they don’t point to the same provider

Aren’t multiple MX records more reliable? In some cases, yes; but most certainly not in this case. Office 365 assigns you a single record per domain, and if that domain is registered with us, we will accept mail for you. It is covered by our money-backed guarantee. We constantly monitor, and we have engineered multiple layers of redundancy already: at the A (host) record level, at the IP level, and more. At the IP level alone, there are thousands of severs sitting behind just a single virtual IP.

Why? More MX records – whether pointing to a 3rd party scanning service, on-premises, or even a “continuity” provider means more complexity and possible message delays because your mail is taking an extra hop, which is not covered in any of our guarantees. It also means that when mail fails over to another route, unexpected things can happen with junk filtering and spoof detection. For example, a good bit of our EOP filtering stack does not trigger when we detect this configuration. This leaves you open to phishing attacks and more. It also makes it a pain to troubleshoot, because you’ll occasionally be troubleshooting messages that didn’t even pass through in the order you’d expect. SPF most likely will fail for those messages which take an extra hop, and that could trigger false positives. This is so important that I’ll say it one more time – EOP is NOT as effective if you have multiple MX records or mail doesn’t route to EOP first. It’s the first thing I ask support engineers to check when troubleshooting missed junk or false positives. I see countless issues where people are complaining about the effectiveness of EOP, only to discover that all MX records did not point to EOP.

Now, if you have opted not to use EOP and rely on a third party or on-premises filtering infrastructure instead, that is fine, but only use the records appropriate for that single configuration. Don’t mix and match a few of theirs with a few of ours, at least for a single domain.

As for other DNS records, it ultimately depends on how the client behaves – but if you’re not sure, don’t assume that more DNS records are always better.

Use only the MX records provided to your specific tenant

Sometimes, you’ll setup a domain inside of a test Office 365 tenant, and then move it to a production tenant. Sometimes, a company merges or divests, and you must move a domain to a new tenant. You absolutely must update DNS records when doing so. You cannot assume that we’ll let you keep using the old DNS records indefinitely, just because they work for a little while. I saw a case recently where a reseller was using a single DNS record for every tenant they were responsible for. Not only does this increase risk, but it is not supported, and mail will eventually break.

While it is technically true that you could use a single assigned A (host) record for every domain in your tenant, this is not advised, because it also increases risks. What if that domain expires or moves to another tenant, while the others stay where they are?

Don’t let your domain expire

It is sage advice to know when your DNS records are set to expire. Set yourself a reminder a few months in advance, just as you might do with certificates or anything else. Set yourself another reminder for a few days before. Even if you have it set to auto-renew, payment issues happen all the time. Don’t rely exclusively on email notifications.

Check your records occasionally

I know there’s a (mostly true) saying that goes something like, “if it isn’t broken, don’t fix it.” But that doesn’t mean you shouldn’t know what your DNS records are and know that they are setup correctly. Just because something appears to work fine, doesn’t mean that it is setup correctly. I would strongly advise doing a complete and exhaustive check of DNS at least once per year. There are tools all over the Internet to help you. Yes, when you identify that a change needs to happen, proceed with caution. But put together a plan now to get it fixed during the next possible window.

Where do I go to check all of this?

If you login with an Office 365 Admin account, the Domains page under Setup has everything you need for each domain you’ve registered with us. If you’ve purchased the domain through Microsoft and let us manage it for you, there should be nothing more required. If the domain is one that you manage yourself, the experience looks something like this (if GoDaddy is your registrar and DNS provider, we’ll actually walk you through the setup):

From this page, you can click into each domain to see what the value should be, for example:

Then, you can use nslookup to validate what the world sees. As an example:

> server
Default Server:  b.resolvers.Level3.net
> set q=mx
> contoso.com
Server:  b.resolvers.Level3.net
contoso.com     MX preference = 10, mail exchanger = mail.global.frontbridge.com
> set q=txt
> contoso.com
Server:  b.resolvers.Level3.net
contoso.com     text =

As you can see from this example, contoso.com does NOT have the proper MX record, and they have no SPF record. Alternately, you can use any number of 3rd party DNS checking tools available on the web.

While you’re at it, check all your Office 365 DNS records as well. And odds are, if you’re still using those old records, you might not have setup DKIM and DMARC. Take this opportunity and stop procrastinating – your brand, your users’ safety, even the financial future of your company could depend on it. For more information, see the Office 365 Domains FAQ.

I hope you find these best practices helpful, and if you’re stuck, our support is able to assist you with any of this.

Scott Landry

Introducing the Netgate Forum

pfSense Blog - Thu, 05/24/2018 - 19:00

The pfSense forum has been migrated to a combined forum for all Netgate products at https://forum.netgate.com. This forum is powered by NodeBB.

Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1

Exchange Team Blog - Wed, 05/23/2018 - 09:55

In part 3 of our Exchange Server TLS Guidance series, we introduce how to turn off TLS 1.0 and 1.1 in your Exchange Server deployment. Turning off TLS 1.0 and 1.1 can be a highly disruptive event if not planned and executed properly. The Exchange team believes that it is time for the ecosystem to fully embrace TLS 1.2, but urges you to proceed with caution when disabling TLS 1.0 and 1.1. This includes understanding how and being prepared to reverse the configuration steps if necessary.


Before disabling TLS 1.0 and 1.1, it is important that you have completed the steps outlined in Part 1: Getting Ready for TLS 1.2 and Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It. Do not proceed until you have completed these steps on all Exchange servers, have read all of Part 3 (this post) and understand the implications of disabling TLS 1.0 and 1.1.

Disabling TLS 1.0 and 1.1

We have attempted to simplify adopting newer versions of TLS by aligning Exchange configuration to the operating system capabilities. In Exchange Server 2016 and later, Exchange fully inherits the capabilities of the operating system on the platform where Exchange is installed. Exchange Server 2013 behaves the same as Exchange 2016 with the exception of POP and IMAP. Exchange 2010 has a similar restriction for POP and IMAP but behaves differently than Exchange 2013 (see the About POP and IMAP section below). The steps used to disable TLS 1.0 and 1.1 outlined below will apply to the following Exchange functionality:

  • Simple Mail Transport Protocol
  • Outlook Client Connectivity
  • Exchange Active Sync
  • Outlook on the Web (and Outlook Web App / Outlook Web Access in earlier versions of Exchange)
  • Exchange Admin Center and Exchange Control Panel
  • Autodiscover
  • Exchange Web Services (and Representational State Transfer “REST” where implemented)
  • Use of PowerShell by Exchange over HTTPS
  • POP and IMAP (Exchange Server 2013 and later only)
Disable TLS 1.0 and 1.1 in SChannel All Windows Server Versions

In Part 2, we introduced how to enable TLS 1.2 in Windows SChannel using the Windows Registry. To disable TLS 1.0 and 1.1 you make use of the same Enabled and DisabledByDefault DWORD entries, but with different values. An admin must modify the TLS 1.0 and TLS 1.1 portions of the SChannel registry section and turn the protocols off instead of turning them on.

To disable TLS 1.0 for both Server (inbound) and Client (outbound) connections on an Exchange Server perform the following:

1. From Notepad.exe, create a text file named TLS10-Disable.reg.

2. Copy and paste the following text into the file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

3. Save TLS10-Disable.reg.

4. Double click the TLS10-Disable.reg file.

5. Click Yes to update your Windows Registry with these changes.

6. Restart the machine for the changes to take effect.

To disable TLS 1.1 for both Server (inbound) and Client (outbound) connections on an Exchange Server please perform the following:

1. From Notepad.exe, create a text file named TLS11-Disable.reg.

2. Copy and paste the following text into the file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]

3. Save TLS11-Disable.reg.

4. Double click the TLS11-Disable.reg file.

5. Click Yes to update your Windows Registry with these changes.

6. Restart the machine for the changes to take effect.

About POP/IMAP Exchange Server 2010

The Exchange product updates which allow POP/IMAP to dynamically consume the operating system SChannel configuration settings for POP/IMAP connections are not available in Exchange Server 2010. POP/IMAP are still dependent upon SChannel configuration, but are hard coded to allow TLS 1.0 or SSL 3.0 negotiation only in Exchange Server 2010. As of the posting date for this entry, if TLS 1.0 is disabled in SChannel, clients will fallback and attempt to negotiate SSL 3.0. If SSL 3.0 is disabled, client negotiation will fail. There are no current plans to change this product behavior. Microsoft’s implementation of TLS 1.0 has no known vulnerabilities but SSL 3.0 use is strongly discouraged. Customers who need to ensure that TLS 1.2 is used for SMTP / HTTPS traffic may need to add servers specifically configured to support TLS 1.0 only for POP/IMAP if needed in their environment.

Note: We assume that most customers have disabled SSL 3.0 already. If not, the process used to disable SSL 3.0 can be found at support.microsoft.com.

Exchange Server 2013

Similar to Exchange Server 2010, POP/IMAP on Exchange Server 2013 does not dynamically inherit the operating system SChannel settings. POP/IMAP protocols are hard coded to negotiate TLS 1.2 in Exchange Server 2013. This means customers can proceed with disabling TLS 1.0 and 1.1 on Exchange Server 2013. It is unlikely, but if TLS 1.3 (or later) support is added on the operating systems supported by Exchange Server 2013, customers will need to determine how to proceed with publishing endpoints which meet their requirements.

.NET considerations and other applications on an Exchange Server

The steps outlined in this series address the Exchange product code running on an Exchange server. The guidance provided represents the actions and steps to allow Exchange to successfully negotiate TLS 1.2. Other articles specific to .NET may reference additional actions, e.g. the use of SchUseStrongCrypto. Exchange only requires the use of SystemDefaultTlsVersions introduced in Part 2 of this series. We have worked with the .NET team to ensure that use of other .NET settings does not conflict with how Exchange has been developed and our approach to dynamically inherit the operating system capabilities. It is entirely possible that other applications developed on the .NET Framework which are deployed on an Exchange Server may require additional configuration. Customers should work with the ISV’s for any applications installed on an Exchange server to understand an application’s specific requirements.


This concludes our series on how to enable TLS 1.2 on Exchange Server and disable older TLS versions. With proper planning and execution, customers should be able to successfully transition to TLS 1.2. We encourage you to complete this across all of your Exchange servers as soon as reasonably possible.

We introduced the topic of ciphers as a part of the discussion on TLS encryption when we started this series. It is our intention in the near future to provide additional guidance to customers on the cipher and hashing algorithms that we recommend be used to best secure Exchange Server communications. For now, enjoy the improvements that TLS 1.2 can provide and check this off your list of things to do with your Exchange servers.

A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher, Arindam Thokder and others for combining numerous efforts of work into this series of postings.

The Exchange Team

Updates to our Privacy Policy

pfSense Blog - Mon, 05/21/2018 - 19:00

Netgate has always believed everyone should have access to reasonable security. Our beliefs are no different with respect to privacy. We are doing our best to make sure you know what data we collect from you, how we use it, and that you have meaningful visibility to, and control over, both.

15% off VMware Learning Zone

IT Coupons - Fri, 05/18/2018 - 04:56

15% off VMware Learning Zone

15% off VMware Learning Zone
15% off VMware Learning Zone Offer Expires: 2018-06-30

Coupon Code: no code needed

15% off VMware Learning Zone

IT Coupons - Fri, 05/18/2018 - 04:56

15% off VMware Learning Zone

15% off VMware Learning Zone
15% off VMware Learning Zone Offer Expires: 2018-06-30

Coupon Code: no code needed


Subscribe to Fix the Exchange! aggregator