Exchange (Anglais)

test table

Exchange Team Blog -

To… For messages… Use this command… Enable message copy Sent As the delegator

Set-Mailbox <delegator mailbox name> –MessageCopyForSentAsEnabled $true

Disable message copy Sent As the delegator

Set-Mailbox <delegator mailbox name> –MessageCopyForSentAsEnabled $false


Sent Items behavior control comes to Exchange Online user mailboxes

Exchange Team Blog -

It has been a while since we blogged about the ability to control the behavior of Sent Items for shared mailboxes when users either send as or on behalf of shared mailboxes. Today, we are glad to share with you that this feature is currently rolling out for User mailboxes also! What does that mean in real life?

Let’s say you have the following scenario:

  • Mary is a delegator/manager on the team
  • Rob is a delegate on Mary’s mailbox; Rob has Send As or Send on behalf of rights on Mary’s mailbox.
  • When Rob sends an email as Mary, the email will be only in Rob’s Sent Items folder

With this feature enabled on Mary’s mailbox, Exchange will copy the message that Rob sends as Mary to the Sent Items folder in Mary’s mailbox. In other words, both Rob and Mary will have the message in their Sent Items folders.

We have heard this request more than once, and now we are rolling it out to an Exchange Online mailbox near you! The configuration and behavior of the feature is the same as for the shared mailbox.

Note: If the user has used the Outlook 2013 feature to change the folder that Sent Items are saved to, the messages will be copied to that folder instead of the user’s Sent Items folder. Users can reconfigure this by clicking the Save Sent Items To button on the Email Options tab.

To For messages Use this command… Enable this behavior Sent As the delegator

Set-Mailbox <delegator mailbox name> –MessageCopyForSentAsEnabled $true

Enable this behavior Sent On Behalf of the delegator For emails Sent On Behalf of the delegator:

Set-Mailbox <delegator mailbox name> –MessageCopyForSendOnBehalfEnabled $true

Disable this behavior Sent As the delegator

Set-Mailbox <delegator mailbox name> –MessageCopyForSentAsEnabled $false

Disable this behavior Sent On Behalf of the delegator For emails Sent On Behalf of the delegator:

Set-Mailbox <delegator mailbox name> –MessageCopyForSendOnBehalfEnabled $false

Note, you can use the Office 365 Portal to configure this for shared mailboxes, but to configure user mailboxes, you’ll need to use PowerShell (the team would like to hear if you feel it should be in the Portal too!). For various other details of behavior please see the shared mailbox post.

Next question that some might have is: What about on-premises? We know you want to use this on premises also, and will update when we have more details!


The Calendaring Team

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

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:

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.


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.

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.

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.

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.


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.


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. 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. 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

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