Exchange (Anglais)

Help us test Cloud Attachments in Outlook 2016 with SharePoint Server 2016

Exchange Team Blog -

My name is Steven Lepofsky, and I’m an engineer on the Outlook for Windows team. We have released (to Insiders) support for Outlook 2016’s Cloud Attachment experience with SharePoint Server 2016. We need your help to test this out and give us your feedback!

So, what do I mean by “cloud attachments?” Let’s start there.

The Cloud Attachment Experience Today

Back when we shipped Outlook 2016, we included a refreshed experience for how you can add attachments in Outlook. To recap, here are a few of the new ways Outlook helped you to share your files and collaborate with others:

We added a gallery that shows your most recently used documents and files. Files in this list could come from Microsoft services such as OneDrive, OneDrive for Business, SharePoint hosted in Office 365 or your local computer. When you attach these files, you have the option of sharing a link to the file rather than a copy. With the co-authoring power of Microsoft Office, you can collaborate in real time on these documents without having to send multiple copies back and forth.

Is the file you’re looking for not showing up in the in the recent items list? Outlook includes handy shortcuts to Web Locations where your file might be stored:

And in a recent update, we gave you the ability to upload files directly to the cloud when you attach a file that is stored locally:

Adding Support for SharePoint Server 2016

Until now, Cloud Attachments were only available from Office 365 services or the consumer version of OneDrive. We are now adding the ability to connect to SharePoint Server 2016, so you can find and share files from your on-premises SharePoint server in a single click. We’d love your help testing this out before we roll it out to everyone!

The new experience will match what we have today, just with an additional set of locations. Once setup, you’ll have new entries under Attach File -> Browse Web Locations. These will show up as “OneDrive for Business” for a user’s personal documents folder, and “Sites” for team folders.

Note: If you also happen to be signed in to any Office365 SharePoint or OneDrive for Business sites under File -> Office Account, both sites may show up. The difference will be that the Office 365 versions will have branding for your company. For example, it may say “OneDrive – Contoso” rather than “OneDrive for Business”, or “Sites – Contoso” rather than “Sites.”

You’ll be able to upload locally attached files to the OneDrive for Business folder located on your SharePoint Server.

And, of course, you’ll see recently used files from your SharePoint server start to show up in your recently used files list.

How to get setup

Here are the necessary steps and requirements to start testing this feature out:

  1. This scenario is only supported if you are also using Exchange Server 2016. You’ll need to configure your Exchange server to point to your SharePoint Server 2016 Internal and/or External URLs. See this blog post for details: Configure rich document collaboration using Exchange Server 2016, Office Online Server (OOS) and SharePoint Server 2016
  2. You’ll need Outlook for Windows build 16.0.7825.1000 or above.
  3. Ensure that your SharePoint site is in included in the Intranet zone.
  4. Optional: Ensure that crawling is enabled so that your documents can show up in the recent items gallery. Other features such as uploading a local attachment to your site will work even if crawling is not enabled. See this page for more details: Manage crawling in SharePoint Server 2013

Once enrolled, any mailbox that boots up Outlook and is configured with your SharePoint Server’s information per step #1 above will start to see the new entry points for the server.

We hope you enjoy this sneak peek, and please let us know how this is working for you in the comments below!

Steven Lepofsky

Exchange Server Edge Support on Windows Server 2016 Update

Exchange Team Blog -

Today we are announcing an update to our support policy for Windows Server 2016 and Exchange Server 2016. At this time we do not recommend customers install the Exchange Edge role on Windows Server 2016. We also do not recommend customers enable antispam agents on the Exchange Mailbox role on Windows Server 2016 as outlined in Enable antispam functionality on Mailbox servers.

Why are we making this change?

In our post Deprecating support for SmartScreen in Outlook and Exchange, Microsoft announced we will no longer publish content filter updates for Exchange Server. We believe that Exchange customers will receive a better experience using Exchange Online Protection (EOP) for content filtering. We are also making this recommendation due to a conflict with the SmartScreen Filters shipped for Windows, Microsoft Edge and Internet Explorer browsers. Customers running Exchange Server 2016 on Windows Server 2016 without KB4013429 installed will encounter an Exchange uninstall failure when decommissioning a server. The failure is caused by a collision between the content filters shipped by Exchange and Windows which have conflicting configuration information in the Windows registry. This collision also impacts customers who install KB4013429 on a functional Exchange Server. After the KB is applied, the Exchange Transport Service will crash on startup if the content filter agent is enabled on the Exchange Server. The Edge role enables the filter by default and does not have a supported method to permanently remove the content filter agent. The new behavior introduced by KB4013429, combined with our product direction to discontinue filter updates, is causing us to deprecate this functionality in Exchange Server 2016 more quickly if Windows Server 2016 is in use.

What about other operating systems supported by Exchange Server 2016?

Due to the discontinuance of SmartScreen Filter updates for Exchange server, we encourage all customers to stop relying upon this capability on all supported operating systems. Installing the Exchange Edge role on supported operating systems other than Windows Server 2016 is not changed by today’s announcement. The Edge role will continue to be supported on non-Windows Server 2016 operating systems subject to the operating system lifecycle outlined at https://support.microsoft.com/lifecycle.

Help! My services are already crashing or I want to proactively avoid this

If you used the Install-AntiSpamAgents.ps1 to install content filtering on the Mailbox role:

  1. Find a suitable replacement for your email hygiene needs such as EOP or other 3rd party solution
  2. Run the Uninstall-AntiSpamAgents.ps1 from the \Scripts folder created by Setup during Exchange installation

If you are running the Edge role on Windows Server 2016:

  1. Delay deploying KB4013429 to your Edge role or uninstall the update if required to restore service
  2. Deploy the Edge role on Windows Server 2012 or Windows Servers 2012R2 (Preferred)

Support services is available for customers who may need further assistance.

The Exchange Team

Released: March 2017 Quarterly Exchange Updates

Exchange Team Blog -

With this month’s quarterly release, we bid a fond farewell to Exchange Server 2007. Support for Exchange Server 2007 expires on 4/11/2017. Update Rollup 23 for Service Pack 3 will be the last update rollup released for the Exchange Server 2007 product. Today we are also releasing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. These releases include fixes to customer reported issues and updated functionality. Exchange Server 2016 Cumulative Update 5 and Exchange Server 2013 Cumulative Update 16 are available on the Microsoft Download Center. Update Rollup 17 for Exchange Server 2010 Service Pack 3 is also now available.

Exchange Server 2013 and 2016 require .Net 4.6.2

As previously announced, Exchange Server 2013 and Exchange Server 2016 now require .Net 4.6.2 on all supported operating systems. Customers who previously updated their Exchange servers to .Net 4.6.1 can proceed with the upgrade to 4.6.2 before or after installing the updates released today. Customers who are still running .Net 4.5.2 should deploy Cumulative Update 4 or Cumulative Update 15, upgrade the server to .Net 4.6.2 and then deploy either Cumulative Update 5 or Cumulative Update 16.

Arbitration Mailbox Migration

Recently there have been reports of problems with customers migrating mailboxes to Exchange Server 2016. We wanted to take this opportunity to remind everyone that when multiple versions of Exchange co-exist within the organization, we require that all Arbitration Mailboxes be moved to a database mounted on a server running the latest version of Exchange. For more information, please consult the Exchange Server Deployment Assistance on TechNet.

Update on S/MIME Control

One year ago, we released an updated S/MIME Control for OWA. We have received questions from customers requesting clarification on what this release included. As stated previously, the control itself did not change. This was a packaging change necessary to prevent IE from throwing a certificate warning during installation due to SHA-1 deprecation. The Authenticode algorithm used to code sign the control uses a SHA-1 algorithm. SHA-1 ensures compatibility with Vista/Windows Server 2008 and Windows 7/Windows Server 2008R2 code signing. The Authenticode file hash and delivery package are signed with a SHA-2 certificate. Signing the package with a SHA-2 certificate prevents IE from throwing a certificate warning when the package is installed and provides the necessary protection for the entire package.

Latest time zone updates

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

TLS 1.2 Exchange Support Update coming in Cumulative Update 6

We would like to raise awareness of changes planned for the next quarterly update release. We are working to provide updated guidance and capabilities related to Exchange Server’s use of TLS protocols. The June 2017 release will include improved support for TLS in general and TLS 1.2 specifically. These changes will apply to Exchange Server 2016 Cumulative Update 6 and Exchange Server 2013 Cumulative Update 17.

Late Breaking Issues not resolved in Cumulative Update 5

Cumulative Update 5 includes a couple of issues that could not be resolved prior to the product release. The unresolved items we are aware of include the following:

  • When attempting to enable Birthday Calendars in Outlook for the Web, an error occurs and Birthday Calendars are not enabled.
  • When failing over a public folder mailbox to a different server, public folder hierarchy replication may stop until the Microsoft Exchange Service Host is recycled on the new target server.

Fixes for both issues are planned for Cumulative Update 6.

Release Details

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

Exchange Server 2016 Cumulative Update 5 does 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.

Exchange Server 2013 Cumulative Update 16 does not include updates to Active Directory, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to Cumulative Update 16. PrepareAD will run automatically during the first server upgrade if Exchange Setup detects this is required and the logged on user has sufficient permission.

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 CU16, 2016 CU5) or the prior (e.g., 2013 CU15, 2016 CU4) 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

Announcing the availability of modern public folder migration to Exchange Online

Exchange Team Blog -

We are happy to announce the availability of public folder migration from Exchange Server 2013/2016 on-premises to Exchange Online! Many of our customers asked us for this, and the full documentation is now here. To ensure that any version-specific instructions are addressed appropriately, we have two articles to point you to:

While all of the information is located in the documentation, the key requirements are:

  • Exchange Server 2013 CU15 (or later), Exchange Server 2016 CU4 (or later)
  • Exchange on-premises hybrid configured with Exchange Online

If you have any additional questions, let us know in comments below. Enjoy!

Public Folder Migration Team

Multi-Factor Authentication for the Hybrid Configuration Wizard and Remote PowerShell

Exchange Team Blog -

You can now use an Administrator account that is enabled for Multi-Factor Authentication to sign in to Exchange Online PowerShell and the Office 365 Hybrid Configuration Wizard (HCW).

In case you are not aware, the Azure multi-factor authentication is a method of verifying who you are that requires the use of more than just a username and password. Using MFA for Office 365, users are required to acknowledge a phone call, text message, or app notification on their smart phones after correctly entering their passwords. They can sign in only after this second authentication factor has been satisfied. You can read more about the Office 365 Multi Factor Authentication option here.

Many Exchange Online customers wanted the extra level of security that is offered with Multi-Factor Authentication, which allows you to force the administrator account to use Multi-Factor Authentication. However, because of a limitation in Remote PowerShell, Exchange Online administrators could not connect with a Multi-Factor enabled account. In addition, as the Office 365 Hybrid Wizard also requires Remote PowerShell connections to Exchange Online, prior to now, the account you used to run the HCW could not be enabled for Multi-Factor Authentication.

The Exchange Online PowerShell Module

There is a new module that was created that can be downloaded to allow you to connect with an account that is enabled for Multi-Factor Authentication. You can download the module from the Exchange Online Administration Center (the steps are outlined in this article).

Note: We do not plan to discontinue traditional methods of connecting to Remote PowerShell; if you are not using Multi-Factor Authentication you can continue to connect using the methods you already have in place.

The Hybrid Wizard Update

The Hybrid Wizard has also been updated to allow for Multi-Factor Authentication enabled administrators to authenticate.

Note: There is an issue with this new Authentication method in the 21 Vianet Greater China tenants. For customers with Tenants in that region you cannot use the MFA module or Hybrid integration mentioned in this article and should instead use the Hybrid Wizard located here: http://aka.ms/HCWCN

In order to keep the sign in experience consistent for all customer whether they have MFA enabled or are using traditional credentials, we have updated our credentials page in the wizard.

On the Credential page of the wizard you will see that the “next” button is not available. You are required to pick your credential for on-premises (which by default will be the currently signed in credentials) and “sign in” to Office 365.

Once you select “sign in” you will be prompted for credentials in a familiar looking screen.

If you have Multi-Factor Authentication enabled for the administrator, you would then be prompted for the second factor of authentication.

Once verified, you would see the credential card for both the on-premises and Exchange Online administrators. You will also notice that the “next” button is now activated.

Conclusion

Your feedback about not being able to use MFA enabled account for Exchange Online administration was loud and clear! Please keep providing us feedback so we can continue to identify and address your needs.

The Exchange Team

Exchange 2007 reaches end of life on April 11th. What’s your plan to move?

Exchange Team Blog -

On April 11, 2017, Exchange Server 2007 will reach End of Life. If you haven’t already begun your migration from Exchange 2007 to Office 365 or Exchange 2016, you need to start planning now.

End of life means that Microsoft will no longer provide the following for Exchange 2007:

  • Free or paid assisted support (including custom support agreements)
  • Bug fixes for issues that are discovered and that may impact the stability and usability of the server
  • Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
  • Time zone updates

Your installation of Exchange 2007 will continue to run after this date. However, because of the changes listed above, we strongly recommend that you migrate from Exchange 2007 as soon as possible.

To learn about your options for migrating from Exchange 2007 to Office 365 or a newer version of Exchange Server, check out Exchange 2007 End of Life Roadmap.

If you have other Office 2007 servers or clients, such as SharePoint Server 2007, PerformancePoint Server 2007, Office Communications Server, Project Server 2007, or Office 2007 client applications, check out Resources to help you upgrade from Office 2007 servers and clients for information about their end of life dates and upgrade options.

Exchange Team

Analyzing Exchange Transaction Log Generation Statistics – Revisited

Exchange Team Blog -

Almost 4 years ago, I wrote a script called GetTransactionLogStats.ps1, and originally blogged about it here. At the original time of writing, the primary purpose of the script was to collect transaction log generation data, and use that to determine the percentage of transaction logs generated per hour in an environment. This could in turn be used to populate the related fields in the Exchange Server Role Requirements Calculator.

Since originally writing this script, I’ve made some significant updates to how the script functions, and also added a handful of new features along the way, which were significant enough that I wanted to have a new post about it. Of note, the script now:

  • Uses PowerShell Remoting to collect data from many remote servers in Parallel. This significantly speeds up collection speeds.
  • Generates a database heat map, that compares the number of logs generated for each database to the number of logs generated for all databases. This can be used to identify databases that may be overloaded or underloaded.
  • Uses only log generation information from active database copies to determine log generation statistics.
  • Accepts the target servers via a script parameter instead of via a text file.
Requirements

The script has the following requirements;

  • Target Exchange Servers must be running Exchange 2010, 2013, or 2016
  • PowerShell Remoting must be enabled on the target Exchange Servers, and configured to allow connections from the machine where the script is being executed.
Parameters

The script has the following parameters:

  • Gather: Switch specifying we want to capture current log generations. If this switch is omitted, the -Analyze switch must be used.
  • Analyze: Switch specifying we want to analyze already captured data. If this switch is omitted, the -Gather switch must be used.
  • ResetStats: Switch indicating that the output file, LogStats.csv, should be cleared and reset. Only works if combined with –Gather.
  • WorkingDirectory: The directory containing LogStats.csv. If omitted, the working directory will be the current working directory of PowerShell (not necessarily the directory the script is in).
  • LogDirectoryOut: The directory to send the output log files from running in Analyze mode to. If omitted, logs will be sent to WorkingDirectory.
Usage

Runs the script in Gather mode, taking a single snapshot of the current log generation of all databases on servers server1 and server2:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2”

Runs the script in Gather mode, specifies an alternate directory to output LogStats.csv to, and resets the stats in LogStats.csv if it exists:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2” -WorkingDirectory “C:\GetTransactionLogStats” -ResetStats

Runs the script in Analyze mode:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze

Runs the script in Analyze mode, and specifies an alternate directory to send the output files to:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut “C:\GetTransactionLogStats\LogsOut”

Output File After Running in Gather Mode LogStats.csv

When run in Gather mode, the log generation snapshots that are taken are sent to LogStats.csv. The following shows what this file looks like:

Output Files After Running in Analyze Mode LogGenByHour.csv

This is the primary output file for the script, and is what is used to populate the hourly generation rates in the Exchange Server Role Requirements Calculator. It consists of the following columns:

  • Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
  • LogsGenerated: The total number of logs created during that hour for all days present in LogStats.csv.
  • HourToDailyLogGenRatio: The ratio of all logs that that particular hour accounts for. The sum of values for this column in all 24 hours in the table should be 1, and can be copied directly into the Exchange Server Role Requirements Calculator.
  • NumberOfHourlySamples: The number of hourly samples that were used to calculate each hour value.
  • AvgLogGenPerHour: The average number of logs generated per database per hour.

LogGenByDB.csv

This file contains a heat map showing how many logs were generated for each database during the duration of the collection. This information can be used to figure out if databases, servers, or entire Database Availability Groups, are over or underutilized compared to their peers. It consists of the following columns:

  • DatabaseName: The name of the database being measured.
  • LogsGenerated: The total number of logs created by primary copies of that database during the duration of the collection.
  • LogGenToTotalRatio: The ratio of logs generated for this database compared to logs generated for all databases.
  • NumberOfHours: The number of hourly samples that were taken for this database.
  • LogsGeneratedPerHour: The average number of logs generated per hour for this database.

LogGenByDBByHour.csv

This file is similar to LogGenByDB.csv, but shows the log generation rates per hour for each database. It consists of the following columns:

  • DatabaseName: The name of the database being measured.
  • Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
  • LogsGenerated: The total number of logs created by primary copies of that database during that hour.
  • HourToDailyLogGenRatioForDB: The ratio of logs generated for this hour and this database compared to the total logs generated for this database.

Running As a Scheduled Task

Since the script is designed to be run an hourly basis, the easiest way to accomplish that is to run the script via a Scheduled Task. The way I like to do that is to create a batch file which calls Powershell.exe and launches the script, and then create a Scheduled Task which runs the batch file. The following is an example of the command that should go in the batch file:

powershell.exe -noninteractive -noprofile -command “& {C:\LogStats\GetTransactionLogStats.ps1 -Gather -TargetServers “server1”,”server2” -WorkingDirectory C:\LogStats}”

In this example, the script is located in C:\LogStats. Note that I specified a WorkingDirectory of C:\LogStats so that if the Scheduled Task runs in an alternate location (by default C:\Windows\System32), the script knows where to find and where to write LogStats.csv. Also note that the command does not load any Exchange snapin, as the script doesn’t use any Exchange specific commands.

Mike Hendrickson

An update to "Important notice for Office 365 email customers who have configured connectors"

Exchange Team Blog -

Since we posted this blog post, we have received positive responses from many of our customers, who have proceeded with changing their connectors (as per instructions in the post), thereby protecting their email/domain reputation. However, we are also aware of customers who are either in the midst of making this change or need some additional time to complete their changes. We understand a change like this can take some time, so we have decided to move our deadline from Feb 1st, 2017 to July 5th, 2017.

We have also added more details in the original post. If you are an Office 365 email customer and your organization is hybrid (you have an on-premise environment), please take some time to read it!

Carolyn Liu

Send-as and Send-on-behalf of for groups in Outlook

Exchange Team Blog -

Today, we are excited to announce the ‘Send-as’ and Send-on-behalf of feature for groups in Outlook, which brings you one step closer to turning your email into a great customer support solution.

With the new ‘Send as’ and ‘Send on behalf of’ feature, members of the group can respond to conversations using the shared identity of the Group instead of their individual personal identity – without losing the personal, individual touch. Because sometimes, that’s just what you need.

Like other groups in Outlook, members can read all messages sent to the group. But with this feature turned on, responses look like they come from the group rather than the individual.

Here’s what Send on Behalf and Send As look like from the recipient’s perspective:

Send on Behalf Send As

If your business is looking for a lightweight, email-centric customer support solution, you’re in luck. This feature might be what you need. The consistent use of a single email address will help your customers develop recognition and trust—ensuring that your email messages are seen.

This feature is particularly helpful in scenarios where you want to set up a group to connect with external customers. Collective knowledge of group helps resolve those customer inquiries faster and everyone on the team benefits from shared knowledge of the Group.

Here are some example scenarios:

1. Support@Contoso.com can be set as group to receive all customer support inquiries. When your customers send email to this group, any member of the group could respond to inquiry in a timely fashion without disclosing their individual identity. Subsequent responses from the customer also go back to the group, keeping all information in one place and making it faster for support representatives to respond to new inquiries. Additionally, because all of the group conversation history is available, other team members will be able to see that specific customer emails have already been answered to.

The support team member would see the following:

The recipient (customer) would see the following:

2. Some organizations may also want to use ‘Send as’ or ‘Send on behalf of’ for an internal group. For example, if you want all expense reports sent to a Billing department alias rather than bombarding a specific person.

Billing@contoso.com can be set up as a group to receive all your organization’s billing inquiries. Individuals who work in the billing department and are a part of this group can respond back as the Billing department identity.

Sound like what your business needs? Learn how to turn it on.

Allow members to send as or send on behalf of an Office 365 Group – Admin help
Allow members to send email as an Office 365 Group

The Groups Team

Released: Exchange Server Role Requirements Calculator 8.4

Exchange Team Blog -

Today, we released an updated version of the Exchange Server Role Requirements Calculator.

This release focuses on bug fixes with the DAG auto-calculation functionality that was introduced in 8.3, as well as, support for ReplayLagMaxDelay.

In addition to allowing you to configure the ReplayLagMaxDelay value (default is 24 hours), the calculator has also been updated to ensure that the SafetyNetThreshold is configured to a value that is equal to or greater than the sum of ReplayLagTime+ReplayLagMaxDelay.

For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Released: Exchange Generate Message Profile Script v2.0.

Exchange Team Blog -

Greetings Exchange Community!

Today, I am pleased to announce the release of a major update to the Exchange Generate Message Profile script. This release primarily focuses on two enhancements.

The first enhancement is the script will now use multiple “threads” (currently in the form of PowerShell jobs with Runspaces under consideration for a future version) to collect data from multiple servers simultaneously. This should significantly speed up data collection in environments with a large number of servers in a site. A few notes on this:

  1. Each thread creates its own fully RBAC compliant connection to a local Exchange server (defaulting to itself). Because each session is using the RBAC compliant IIS based PowerShell proxy, the CPU utilization of the server running the script is not only increased by the multiple threads that are spawned, but also by the IIS service that they are each are connected to.
  2. When run on a full Exchange Server, the script defaults to using the number of threads equal to approximately ¼ of the CPU cores on the server. This helps ensure that by default the script does not use more than ~50% CPU resources on the server running the script, as it accounts for the CPU load of the threads (1/4 = 25%) and the load they place (another 25%) on the IIS service.
  3. When run on an system with just the Exchange Management tools loaded, the script default to using the number of threads equal to approximately ½ of the CPU cores of the system.
  4. The script will gracefully shut down any background jobs still running if CTRL-C is used to stop the script.

The second enhancement is regarding the script’s behavior of skipping the creation of a message profile for a site when a single server in it is unavailable or has data collection issues. This is still the default behavior of the script, but this behavior can now be overridden by specifying the minimum percentage of servers in a site that must be online and return data for a message profile to still be generated for that site. It is highly recommended to leave this at the default setting, but this requested feature will allow the script to provide even a slightly skewed message profile versus nothing when a small percentage of servers were unresponsive or have data collection issues.

For a complete list of all enhancements and bug fixes please review the Version History on the TechNet Gallery posting.

As always I welcome feedback through the TechNet Gallery posting.

Dan Sheehan
Senior Premier Field Engineer

Microsoft Graph Preview for Exchange 2016 customers

Exchange Team Blog -

We are interested in working with Exchange 2016 customers or partners to help us validate Exchange hybrid scenarios using Microsoft Graph. This will be a self-paced development project where your developers will scope and get technical help to unblock Graph API issues from the product team. In order to participate, you will need to join the Exchange TAP program. Here is a mini FAQ about this program:

What are the technical requirements?
To develop and validate an Exchange hybrid solution, you will need to have Exchange 2016 CU3 or later deployed with your on-premises Active Directory synced with Azure AD. To learn more about the hybrid deployment: https://channel9.msdn.com/Events/Ignite/2016/BRK3045

How many developers will I need?
Expect to have 1 maybe 2 developers to scope and develop a Microsoft Graph solution.

Do I need to have an existing Exchange Web Services solution?
It would be a nice-to-have but we do not require it. We’re more interested in finding customers who want to support hybrid Exchange 2016 deployments and validating the benefits that the Microsoft Graph provides.

What is the timeframe for this?
We are planning to start this project in January 2017 and look to finish before the summer of 2017.

Do we have to travel to Redmond?
No. The tech is already in Preview and available to use from any dev laptop with internet access.

Why are you offering this?
We find collaborating directly with our customers and partners help us to make improvements to the Microsoft Graph to support deeper and broader customer needs. We hope to add what we learn to our product roadmap.

If you are interested in applying for this program, then please send an email to exchangehybridgraph@service.microsoft.com and include the following information:

  1. Who will be the primary lead for this project?
    • Company:
    • First, Last Name:
    • Business Title:
    • Work e-mail:
    • Work phone:
  2. Is your company enrolled in the Exchange TAP?
  3. What hybrid scenario do you envision working on?
  4. Describe how you would like to technically solve it?
  5. Have you or your team tried to solve this hybrid scenario using Exchange Web Services? How did it go?
  6. Have you or your team programmatically used the Microsoft Graph? Please describe a project if you have built one.
  7. Please tell us about your development team that will work on this project.

Cheers!

Microsoft Outlook Team

Certificate-Based Authentication (CBA) for Exchange Online is Generally Available

Exchange Team Blog -

Many organizations have been using certificate based authentication for Exchange Online while the feature was in preview. Today, we are excited to announce that the feature is generally available in Office 365 Enterprise, Business, Education, and Government plans. For more details, please reference our preview post which has been modified to reflect this announcement. As always, we look forward to hearing your suggestions and feedback!

Tyler Lenig
Program Manager
Office 365

Released: December 2016 Quarterly Exchange Updates

Exchange Team Blog -

Today we are announcing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. These releases include fixes to customer reported issues and updated functionality. Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 are available on the Microsoft Download Center. Update Rollup 22 for Exchange Server 2007 Service Pack 3 and Update Rollup 16 for Exchange Server 2010 Service Pack 3 are also available.
A new Outlook on the web compose experience

Exchange Server 2016 Cumulative Update 4 includes a refresh to the compose experience. The body of the message is now “framed” and formatting controls have been moved to the bottom of the view. This mirrors the current experience in Office 365.


Support for .Net 4.6.2

Exchange Server 2013 and Exchange Server 2016 now fully support .Net 4.6.2. Customers who have already updated their Exchange servers to .Net 4.6.1 can proceed with the upgrade to 4.6.2 before or after installing the cumulative updates released today. Customers who are still running .Net 4.5.2 are advised to deploy Cumulative Update 4 or Cumulative Update 15 prior to upgrading to .Net 4.6.2.

The upgrade to .Net 4.6.2, while strongly encouraged, is optional with these releases. As previously disclosed, the cumulative updates released in our March 2017 quarterly updates will require .Net 4.6.2.
Change to Pre-Requisites installed by Setup

Since Exchange Server 2013, the Windows feature Media Foundation has appeared as a pre-requisite in our setup checks on Windows Server 2012 and later. However, if you chose to allow Exchange setup to install the required OS Components, Desktop Experience has been installed on all supported operating systems. Desktop Experience is required on Windows Server 2008R2. The Desktop Experience feature includes additional components which are not necessary for Exchange Server and require frequent patching. Windows Server 2012 and later modified feature definitions to include Media Foundation. Exchange Setup in Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 has been updated to install Media Foundation instead of Desktop Experience on Windows Server 2012 and later. This change will only apply to newly installed servers. Applying either cumulative update will not change the existing configuration of the server. If desired, an administrator can add Media Foundation and remove Desktop Experience from the list of installed Windows features on Windows Server 2012 and later.
Update on Windows Server 2016 support

The Windows team has released KB3206632. This update addresses the issue where IIS would crash after a DAG is formed and the server is subsequently restarted. This update is now required on all servers running Exchange Server 2016 on Windows Server 2016. Setup will not proceed unless the KB is installed.
Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through October 2016.
Important Public Folder fix included in these releases

Exchange Server 2013 Cumulative Update 14 and Exchange Server Cumulative Update 3 introduced an issue where new posts to a public folder may not have been indexed if there was an active public folder migration (KB3202691). This issue is now resolved. To ensure all public folders are indexed appropriately, all public folder mailboxes should be moved to a new database after applying the appropriate cumulative update released today.
Release Details

KB articles which contain greater depth on what each release includes are available as follows:

Exchange Server 2016 Cumulative Update 4 does not include new updates to Active Directory Schema. If upgrading from an older Cumulative Update or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if user permissions and AD requirements are met. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin needs to execute SETUP /PrepareSchema prior to the first Exchange server installation or upgrade. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.

Exchange Server 2013 Cumulative Update 15 does not include updates to Active Directory, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to Cumulative Update 15. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.
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 CU15, 2016 CU4) or the prior (e.g., 2013 CU14, 2016 CU3) 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 was published.

The Exchange Team

Modern public folder deployment best practices

Exchange Team Blog -

Introduction

Since the release of Microsoft Exchange Server 2013, we have heard questions regarding the sizing and deployment of modern public folders. It is important to plan migrations for public folders so the client experience with their use is good. In this blog post, we will discuss some of best practices and recommendations regarding modern public folder deployment as well as discuss various related concepts. We will assume that you are already familiar with basic modern public folders concepts so we will not go there (but might link to relevant articles).

There is a lot here as we are going through several examples. Use it as a reference!
How clients connect to the public folder hierarchy mailbox

When the user launches the Outlook desktop client on Windows or Mac, client contacts the Autodiscover service to determine connection settings for the user’s primary mailbox and their archive mailbox if they have one. During the initial response, the Autodiscover service may indicate there are public folders available in the environment by including an XML element named <PublicFolderInformation>. This element will contain the SMTP address of a public folder mailbox within the environment. An additional Autodiscover request will be made to request connection settings for the SMTP address of the public folder mailbox.

To provide a value for this element during the initial request/response interaction, the Autodiscover service calls a function named GetPublicFolderRecipient. This function gathers information for the available public folder mailboxes in the environment available for serving hierarchy connections.

In most cases the GetPublicFolderRecipient function will (randomly) pick a public folder mailbox from the available list to be handed over to the Autodiscover Service, which in turn gets returned to the client.

Another possibility is that the user’s mailbox has a static DefaultPublicFolderMailbox assigned. When a mailbox has a default public folder mailbox assigned, the client will always attempt to connect to this public folder mailbox for hierarchy connections. If that public folder mailbox is not available for some reason, the client will fall to reach the public folder infrastructure and will not fall back to a random public folder mailbox. Something to keep in mind!

Note: In the case of Outlook on the web (we’ll call it OWA for short) clients accessing public folders, public folder mailbox access does not rely on the Autodiscover service even though the same selection process logic is used. In other words, OWA uses similar functionality that the Get-Mailbox cmdlet uses to get list of available public folder mailboxes the user can utilize. Even if Autodiscover is offline for some reason in the environment, you may see users successfully accessing public folders via OWA, but not Outlook clients.

When are new mailboxes eligible for this process?

By default, all public folder mailboxes deployed in the environment can serve hierarchy connections to the clients. However, immediately after creation a new public folder mailbox will not be used by Autodiscover. This is due to the newly created public folder mailbox has not yet completed an initial full hierarchy sync from the primary hierarchy public folder mailbox. This logic is automatically calculated and is reflected in the parameter IsHierarchyReady. By default, the value will be set to $False. If this value remains $False, the GetPublicFolderRecipient function will not return that public folder mailbox to the Autodiscover Service as it is assumed to contain an incomplete copy of the hierarchy (a user connecting to it would not have a complete view of the public folder infrastructure). Once the value of the newly created public folder mailbox’s IsHierarchyReady has changed to $True, the Autodiscover service will be able to hand it out to clients.

Under normal conditions this initial full hierarchy sync should start automatically within 24 hours of the public folder mailbox being created. You may also invoke the hierarchy sync manually if you so choose by using the below command:

Update-PublicFolderMailbox -Identity “Public folder mailbox name” -SuppressStatus -Fullsync -InvokeSynchronizer

The time it takes for the fully hierarchy replication to complete depends on several factors such as (but not limited to) network speed, number of public folders, geographical location of PF mailboxes, and connection load on the primary hierarchy mailbox.

The initial hierarchy sync happens using a pull operation model. The secondary public folder mailboxes will poll the primary hierarchy public folder mailbox to fetch the hierarchy information. Once the initial FullSync is complete, the value of IsHierarchyReady will change to True automatically and the public folder mailbox will be available to serve the hierarchy information to requesting clients.

To confirm, the following command can be run:

Get-Mailbox -PublicFolder | fl name,ishierarchyready

Note: While IsHierarchyReady value can be manually forced to True using PowerShell, this is not supported. Doing this can cause the public folder mailboxes to serve incomplete hierarchy to clients. The recommendation is wait for the initial sync to complete or manually invoke the hierarchy sync to get the hierarchy replicated to the new public folder mailboxes.

Once the initial hierarchy sync is complete for the public folder mailbox, the next hierarchy sync hereon will happen using the push model, where the primary hierarchy mailbox will push the changes to the secondary hierarchy public folder mailbox every 10 minutes.

Another setting an administrator has at their disposal is the attribute IsExcludedFromServingHierarchy. This attribute can be set to $False (default) or $True using the Set-Mailbox cmdlet and will prevent this mailbox from being used by Autodiscover or OWA to serve hierarchy connections to clients. Even after IsHierarchyReady becomes automatically set to $True the public folder mailbox will be excluded from Autodiscover and OWA hierarchy usage if IsExcludedFromServingHierarchy is set to $True. This option is useful when you want a public folder mailbox utilized only for content of public folders and can be set immediately after the public folder mailbox is created.

Note: If DefaultPublicFolderMailbox is populated on a user mailbox it will override the $True value of IsExcludedFromServingHierarchy (on the mailbox they are connecting) and will allow that user to connect to the public folder mailbox specified in DefaultPublicFolderMailbox for hierarchy. We will discuss this later in the post.

Scenario 1: What happens when default public folder mailbox value has not been set on the user mailbox?

Let’s say we have 50 public folder mailboxes in their default state, all of which have sync’d hierarchy, and there are 20,000 users who try to access public folders. The Autodiscover service will provide a random public folder mailbox to each user to service hierarchy requests.

The specific public folder mailbox being returned to the client can change randomly, or if Outlook is closed and reopened, based on what GetPublicFolderRecipient function returns to Autodiscover which in turn returns the data to the client.

On the client side, public folder mailboxes being accessed will appear under the connection status in Outlook, as shown below:

The first public folder GUID value in here is a random primary public folder hierarchy mailbox. The remaining public folders GUIDs are populated and returned when user tries to access individual public folders which reside within those public folder mailboxes.
Scenario 2: Restricting clients to contact a specific public folder mailbox for hierarchy.

It is possible to override the behavior of random selection of default public folder hierarchy mailbox.

First, you need to confirm that the public folder mailbox has IsHierarchyReady populated with value of $True which confirms that it has completed its initial full hierarchy sync with the primary public folder mailbox.

Run the command:

Get-Mailbox -PublicFolder “Public Folder mailbox name” | FL Name,ExchangeGuid,*Hierarchy*

Once the above is confirmed, the next step is to assign the desired public folder mailbox as the DefaultPublicFolderMailbox on the user mailbox. In our example this would be accomplished by running the below command:

Set-Mailbox “user mailbox identiy” -DefaultPublicFolderMailbox “PF-MBX-002” -Verbose

Now, when the client opens Outlook, Autodiscover provides the DefaultPublicFolderMailbox’s SMTP address in the <PublicFolderInformation> XML element and the client then performs a second Autodiscover request to learn how to connect to this public folder mailbox.

When we check the Outlook connection status, it will list the assigned public folder mailbox.


Scenario 3: Setting the default public folder mailboxes close to the user’s location for better client experience

Our customers deal with communication links that may be highly latent and expectedly inoperable for periods of time. For demonstration purposes let’s consider our favorite company called Contoso which has the following configuration:

Three company sites are listed below:

  • Hyderabad: India with 23,000 mailboxes. Local servers have 10Gbps LAN connectivity and there are three public folder mailboxes in this site.
  • Adelaide: Australia with 5,000 mailboxes. Local servers have 10Gbps LAN connectivity and there is one public folder mailbox in this site.
  • A cruise ship with 500 mailboxes for employees on-board. Local server has 1Gbps LAN connectivity and there is one public folder mailbox per ship.

To maintain communications with their ships at sea, Contoso has established a 384Kbps satellite link to each ship and has also installed a dish at their Hyderabad site. All network routes to/from ships are routed via Hyderabad’s own satellite link.

Contoso has also purchased 1Gbps of bandwidth on a submarine cable link to Australia. All WAN routes to/from Australia site traverse this link.
Challenges with the above deployment

If we were to simply deploy modern public folders with all the default values, we could see some interesting things happen. For example, all users could be offered any of the five public folder mailboxes for hierarchy regardless of their location.

The worst-case scenario here would be a ship based user trying to access PFMBX-AUS-001 for hierarchy information or an Adelaide based user trying to access PFMBX-SHIP-001 for hierarchy information. In either of those scenarios we see client traffic traversing round-trip not only along the longest network path, but also the one with the least bandwidth and most latency. In this extreme example, you would more than likely have clients calling the help desk reporting the Outlook RPC popup after they attempted to expand the public folder tree.

Considering the above problems, we recommend administrators with similar decentralized and complex network topologies consider configuring user mailboxes to access public folder mailboxes located within local or geographically closer sites as their default public folder mailbox.
What would work better?

In an environment like the one in the example, it may make sense to set IsExcludedFromServinginHierarchy to $True for the public folder mailboxes on all cruise ships and Australia. This will remove them from being returned as valid public folder hierarchy endpoints for Autodiscover and OWA, leaving only the three well-connected Hyderabad based public folder mailboxes setup for automatic discovery.

Additionally, the DefaultPublicFolderMailbox attribute at the mailbox level should be utilized for employees based on the cruise ship or the Australia continent to ensure they always attempt to connect to a public folder mailbox that makes sense based on their geolocation. One caveat here is if a user from the Australia office were to visit the cruise ship (for work purposes sadly and not fun in the sun!), their client would continue to connect back to Australia for their PF hierarchy connection. In addition, the Hyderabad office with 23,000 mailboxes would need to monitor user concurrency to determine if they need additional public folder mailboxes or not over time to stay within supported user concurrency limits.
Things to remember and plan during the deployment:

  1. Understand the company topology completely before making any decision to deploy public folders for offices located in different geographical locations. Correct deployment of public folders using the recommended approach will make life easier for administrators and end users.
  2. Make use of the attribute IsExcludedFromServinginHierarchy by setting it to $True when it makes sense to exclude public folder mailboxes from being discovered by Autodiscover for providing hierarchy information to clients and avoid any unwanted connections.
  3. The DefaultPublicFolderMailbox attribute at the mailbox level should be considered when you need to ensure the users in less-connected sites must connect to public folder mailboxes close to their geographical location for hierarchy information. Misconfiguration can lead to serious issues such as latency in accessing public folder information and poor end user experience.
  4. No more than 2000 active connections being made to the same public folder mailbox at any point of time are currently supported. This will require advanced planning, to ensure that the public folders being heavily used by the clients are being distributed across the public folder mailboxes, which are in turn close to the user’s geographical site for better access and experience if necessary.
  5. You can add one or more additional Hierarchy Only Secondary Public Folder Mailboxes (HOSPFM) and Content Only Secondary Public Folder Mailboxes (COSPFM) depending upon the geographical location and identification of commonly used public folder mailboxes by the end users for better end user experience. Yeah, we like our acronyms. Yup, we just made that up.
What are those (HOSPFM) and (COSPFM), and why do we require them?
  • Hierarchy Only Secondary Public Folder Mailbox (HOSPFM): does not contain public folder content and only serves hierarchy. IsExcludedFromServingHierarchy is set to False
  • Content Only Secondary Public Folder Mailbox (COSPFM): has public folder content in it but is excluded from serving hierarchy. IsExcludedFromServingHierarchy is set to True

There are 2 type of connections being made to the public folder mailbox, when it is accessed.

  1. Hierarchy connection
  2. Content connection

Public folder mailbox connections (both hierarchy and content) should not exceed 2000 to remain within the support boundaries. Given this requirement, you should plan to have enough public folder mailboxes serve hierarchy and/or content so that you maintain a level of less than 2000 active and simultaneous client connections per secondary public folder mailbox.

The primary public folder mailbox must be excluded from providing hierarchy to clients (IsExcludedFromServingHierarchy parameter set to True). This allows the primary public folder mailbox to spend its time maintaining the hierarchy and dealing with hierarchy replication tasks. Overloading this public folder mailbox with client connections can in turn lead to performance and reliability issues with your PF hierarchy.
How to move the public folder data close to the user’s geographical location

Consider another company also called Contoso, which has many offices around the world and modern public folders have been deployed in the environment. Sarah is a user whose mailbox is in a datacenter which is in India and she frequently works with public folders. There is another large group of users who also frequently work with the same set of public folders, but they are in a different geographical location, in Australia.

The public folders being accessed are in the India site, close to Sara’s geographical location, so she has a better experience when accessing public folders.

In contrast, when Australia users try to connect to public folder mailboxes, the local hierarchy public folder mailbox in their datacenter will provide the content location for required public folders. Users will initiate a connection to the actual public folder located in India holding the content for the public folder. Since the actual folder content is in different geographical location, the connection request may be not as performant for the Australian group of users, resulting in user frustration.

This deployment is not recommended. The focus should be on identifying the most frequently used public folders by a common set of users, and moving the public folders with that content closer to users’ location. In this scenario, the content should be moved closer to the larger group of users in Australia.

Note: Moving public folders only moves the physical contents of the public folder; it doesn’t change the logical hierarchy, or layout of folders in the folder tree.

To move the public folder content, run the command:

New-PublicFolderMoveRequest -Folders “\path of the public folder to be moved” -TargetMailbox “target public folder mailbox name”

Note: To verify that the PublicFolderMoveRequest is complete, the command Get-PublicFolderMoveRequest can be run.

Like mailbox move requests, completed public folder move request must be removed before any other public folder can be moved to another public folder mailbox. To do this, run the command Remove-PublicFolderMoveRequest. If any other public folder move request is initiated without removing the old request, it will error out like this:

To remove the existing PublicFolderMoveRequest, run the command:

Get-PublicFolderMoveRequest | Remove-PublicFolderMoveRequest

Note: If a parent public folder and its subfolders need to be moved to another public folder mailbox, this can be done using Move-PublicFolderBranch.ps1 script, located in \scripts folder.

For more details, see: Move a public folder to a different public folder mailbox

Once the public folder content has been moved to a different public folder mailbox, users in Australia site accessing the public folder will be updated by the local public folder mailbox hierarchy connection to the folder’s new content location and connect to the local public folder mailbox. To continue with our example, Sarah will continue to connect to local public folder mailbox for hierarchy (which has been set by the administrator), but will then get her content from the Australia datacenter. Even though the experience may not be as great for that one user, Sarah can add frequently used public folders to Favorites using Outlook client or OWA to help with latency issues.

Looking at the above example, it becomes very important to determine network latency and bandwidth before you start deployment of public folder mailboxes in geographically dispersed environment to avoid any latency issues when accessed by end users. In such situations, the recommendation will be to use tools like Netmon which can help in determining the connections happening to public folder mailboxes. There is a great tool written by Mark Russinovich called Psping, which can be helpful in determining the round-trip latency. Based on the results customers can decide whether the current network is suitable for their environment or if there are any changes that needs to be done.
Summary: deployment considerations

Considerations when deploying public folder mailboxes in the organization, to ensure they are protected and readily available to the clients:

  • Public folder mailboxes, both hierarchy and content, should be protected by placing them in databases protected by multiple copies in a Database Availability Group. By doing this, mailboxes will remain protected in case of any outage and be available to end users.
  • There should be no public folders hosted within the primary public folder mailbox. This way we dedicate the primary public folder mailbox to specifically focus on its job of replicating hierarchy changes to other public folder mailboxes.
  • You should exclude the primary public folder mailbox from serving hierarchy to clients. This is done by setting the IsExcludedFromServingHierachy to $True.
  • The recommendation is to activate database copies hosting public folder mailboxes on mailbox servers which are geographically located close to the client location.
  • The general recommendation is having one public folder hierarchy mailbox for every 2000 users accessing public folders. Additional hierarchy only public folder mailboxes can always be created to divide the connection load among users to ensure that the 2000 connection limit is not reached.
  • Plan and create more secondary hierarchy public folder mailboxes and content mailboxes to ensure there are fewer than 2000 active and concurrent connections to public folders and that they are close to the users geographical location to ensure there are no latency issues and users have good experience.
  • Since Exchange Server 2016 CU3 has released, you can make use of up to 1,000 public folder mailboxes. Of the 1,000 public folder mailboxes, 100 of them can be used for hierarchy (or 99 once you exclude the primary PF) and the remaining 900 can be used for content storage.
Post summary

In the above post, we have provided information on how public folder mailboxes are accessed, and the importance of correctly deploying them in a geographically dispersed environment. In upcoming posts, we will discuss topics related to public folder logging analysis, management and quota related information

We would like to say thanks to Public Folders Feature Crew team for their valuable inputs while this blog post was being written.

Special Thanks to Ross Smith IV, Nasir Ali, Scott Oseychik for reviewing this content and validating the guidance mentioned in the blog post and Charlotte Raymundo, Nino Bilic for helping us to get this blog post ready!

Siddhesh Dalvi and Brian Day

S'abonner à Philippe BARTH agrégateur - Exchange (Anglais)