Exchange (Anglais)

Understanding modern public folder quotas

Exchange Team Blog -

As a part of our ‘demystifying modern public folders’ series we have so far discussed the modern public folder deployment best practices and available logging for monitoring public folder connections. In this blog post, we are going to discuss public folder quotas. Let’s get to it!
Public folder mailboxes and quotas

Mailbox quotas are not a new thing. Planning and setting quotas has always been important for Exchange administrators and is equally important when it comes to deployment of public folders. Here is an illustration of types of quotas impacting public folders available for Microsoft Exchange 2013 / 2016 and Exchange Online


Organizational quotas

Those quota settings can be seen by running the command Get-OrganizationConfig | fl *defaultpublic*

DefaultPublicFolderProhibitPostQuota parameter specifies the size of a public folder at which users are notified that the public folder is full. Users can't post to a folder whose size is larger than the DefaultPublicFolderProhibitPostQuota parameter value. The default value of this attribute on-premises is unlimited.

Organizational Quotas in Exchange online are not unlimited and have predefined values. In Exchange Online the default values for DefaultPublicFolderIssueWarningQuota will be 1.7 GB and DefaultPublicFolderProhibitPostQuota is set at 2 GB.


What happens when DefaultPublicFolderProhibitPostQuota is reached in Exchange Online?

The below error will be shown if someone tried to post content to the public folder exceeding the DefaultPublicFolderProhibitPostQuota value.

If user tries to email the folder which exceeded the DefaultPublicFolderProhibitPostQuota limit, they will get the “554 5.2.2 mailbox full” non-delivery report.

If there are any public folders which are exceeding those values, the public folder migration to Exchange online will encounter problems as the mailbox size will be exceeded and the migration will fail.

Though the values can be modified using Set-OrganizationConfig before the start of the migration, we do not encourage this practice as our recommendation and official guidance suggest migrating the public folders below 2 GB. If any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders.

The details of other additional parameters can be found here
Mailbox database level quota and public folder mailboxes (on-premises only)

Mailbox database level quotas apply to public folder mailboxes and not to public folders themselves. Because public folder mailboxes architecturally are normal Exchange mailboxes then these values can come into play as they will limit how large or for how long content related to public folder mailboxes can grow or will be kept.

· RecoverableItemsQuota: determines how much content can be stored within the Recoverable Items folder of a public folder mailbox. If the quota for this parameter is reached, then no emails can be deleted and the following error will be shown:

· RecoverableItemsWarningQuota: defines when a public folder mailbox will start to warn that it is reaching its Recoverable Items quota. Warning events 10024 and 1077 will be logged on respective mailbox server (where the mailbox database hosting those public folder mailboxes is active) and the event ID will contain the Guid of the public folder mailbox. Since the public folder mailbox is not a user mailbox and therefore there is no active logon into the mailbox, keeping track of event logs is important to keep an eye on public folder mailboxes approaching the storage limit.

Details of additional parameters can be found here.

Note: In Exchange Online, public folder mailboxes are not using the quota settings set at database level. If you try to set the public folder mailbox to use the database level quota it will error out as below


Public folder mailbox level quotas

By default, a mailbox will use the values set forth by the mailbox database the mailbox resides in. Optionally you may turn off this inheritance and set specific values for the public folder mailbox in question if you need to utilize values outside of your defaults.

Note: You need to keep in mind that quota settings on the public folder mailbox should always be greater than the values specified at individual public folder level.

Only one parameter to discuss here as the others have been covered in prior sections.

UseDatabaseQuotaDefaults: The Boolean attribute that determines if the public folder mailbox will use the inherited values of its mailbox database ($True) or the values specified specifically on the public folder mailbox itself ($False).
Public folder level quota

Public folder level quota applies to individual public folder itself and can be configured to use different values than the one specified on public folder mailbox. If you create any new child public folders the quota settings will be inherited from the parent public folder.

If quota settings on existing parent public folder are modified, the values will not be “pushed down” to existing child public folders.
Retention settings on individual public folders

There is an option to set the retention setting value on individual public folders and this setting can be inherited by existing child public folders and new child public folders created under the parent folder will inherit the settings

The inheritance can also be applied to public folder age limit. If the inheritance for AgeLimit is applied at the parent public folder, the setting will apply to existing child public folders. If you wish to have the setting on new child public folders, you need to either use PowerShell to configure the value at the individual public folder or GUI to configure those as shown below or you may need to select the option highlighted below again on parent public folders to inherit the changes to the new child public folder.

This inheritance option is only available on the parent public folder itself. It will not be available on the child public folders

If those settings are not set, the organization level quotas will be used.

Also remember - If the inheritance has been enabled in Retention settings of parent public folders, it will automatically be inherited on existing child public folders and the new child public folders created in the future.

Note: In Exchange online the Deleted retention / Age limit settings must be enabled at individual public folder level itself using PowerShell cmdlets only.
How to find a list of public folders which exist in a public folder content mailbox?

To find out the content mailbox location for each public folder, you should run:

Get-PublicFolder –Recurse –resultsize "unlimited" | FT Name,*ContentMailboxName*

The result can be exported to Excel and then filter out data to find out the number of public folders present in a specific public folder mailbox.
How to find public folder mailboxes which are not using the DatabaseQuotaDefaults?

The following command can be run to check for those mailboxes:

Get-Mailbox -PublicFolder | Where {$_.usedatabasequotadefaults -ne "true"}

Method 1:

To calculate the total items size present on the public folder mailbox and get the size of the actual mailbox the following command can be run:

Get-PublicFolder –Identity "\" –Recurse –ResultSize unlimited | Where {$_.ContentMailboxName –eq "mailbox name"} | Get-PublicFolderStatistics | FT name,@{Label="MB"; Expression={$_.Totalitemsize.ToMB()}}

The output can be exported to CSV or TXT file and then opened in Excel.

While this method is handy, we can make full use of it by exporting the data on larger scale for all public folder mailboxes in the organization and then filtering that using Excel as shown below

Example:

Get-PublicFolder -Identity "\" -Recurse | Where {$_.Mailboxownerid -ne $null} | Get-publicfolderstatistics | FT name,*mailboxownerid*,*path*,@{Label="MB"; Expression={$_.Totalitemsize.ToMB()}} -Autosize >c:\total4.txt

Using the specific filter MailboxOwnerId and then exporting the data to TXT or CSV file and opening in Excel gives us this:

From here, it is easy to filter and sum up as needed.

Method 2:

While the above method provides information on individual public folders, it does not provide information about DeletedItems or TotalDeletedItemSize.

To sum-up the TotalItemSize of the public folder mailbox and fetch information for the DeletedItems, TotalDeletedItemSize, the following command can be run:

Get-Mailbox -PublicFolder | Get-MailboxStatistics | FT Displayname,*Item* –wrap

If you want to specifically filter out mailboxes present on a specific mailbox server, the following command can be run to get list of those public folder mailboxes and then the previous command can be used to check for the public folders hosted on those public folder mailboxes.

The output can be exported to CSV or TXT file as needed and then the values can be summed up to ensure that public folders present within the mailbox are not reaching the quota.
How do all those settings work together?

A specific public folder limit (whether they are defined by the organization or explicitly on the public folder) can never exceed the limits being applied to a public folder mailbox containing it.

For example, you should never set a public folder limit of 30 GB if the underlying public folder mailbox has a quota of 15 GB. Your goal should be that all public folders contained within a single public folder mailbox do not add up to a limit greater than the public folder mailbox they are contained in. To keep track of the size of the mailboxes you can use the method discussed earlier in this post.

To following image was created as an attempt to visualize how various quota settings relate:

Mailbox database named Database contains four of the organization’s public folder mailboxes. Three of the public folder mailboxes (green) utilize the mailbox database size limits via inheritance while the fourth public folder mailbox (yellow) uses a non-inherited explicitly defined smaller value. Each public folder mailbox has one or more public folders within them. Six public folders (purple) are using the organization defined limits and five public folders (red) are all using different custom values.
Public folder mailbox sizing best practices

This is one of the frequently asked question when it comes to deployment of public folder mailboxes and setting sizes for them. Our simple advice will be to follow the supported guidelines and best practices for the public folders as mentioned in our published guidance:

Limits for public folders

You should monitor the size of public folder mailboxes and see which public folders might be getting more use than the others (as they might need to be moved to a different mailbox). Use the Get-PublicFolderStatistics to track the number of items being added to public folders.

I would like to say Thanks to Brian Day, Nasir Ali, Ross Smith IV, Scott Oseychik and Bhalchandra Atre for their help reviewing this blog post and providing inputs and Nino Bilic in helping to get this blog post ready!

Siddhesh Dalvi
Support Escalation Engineer

Why is my Address Rewriting not working as expected?

Exchange Team Blog -

Address Rewriting is a feature of the Transport Agent that runs on the Edge Server role. It enables the modification of addresses for both senders and recipients on messages that enter and leave your Exchange organization. First introduced in Exchange 2007, customers are using Address rewriting to present a consistent appearance of E-mail Address for messages sent to external recipients. Two TechNet Articles published here and here document both Address Rewrite inbound and outbound agents, various situations where it's applicable, and commands that can be used to configure and control these agents. However, based on my experience in the Support Team, I have seen scenarios where Address Rewrite is not working as expected, and wanted to work through these.

A potential scenario with Address Rewrite would be Exchange treating certain messages as inbound whereas your expectation is the Address Rewrite outbound agent should work on that particular message. In other words, you were expecting the “From” address to change, but it is not happening. I have also seen cases where the Inbound agent is working fine but not the Outbound, or vice versa. Then there are situations when it works for MAPI submitted messages but not when an application is relaying mail thorough your Exchange environment. In this post, we will discuss how Exchange decides when the Address Rewrite Inbound agent should work and when Address Rewrite Outbound agent should work. We will also try to simplify the scenarios with various examples so that we understand it better.

There are two Address Rewrite agents:

  1. Address Rewrite Inbound Agent – works on inbound messages and changes the RCPT TO/TO
  2. Address Rewrite Outbound Agent – works on outbound messages and changes the MAIL FROM/FROM

How does your Edge Server decide which Address Rewrite Agent will work on a particular message? This is based on combination of below three rules:

  1. If the sender domain (Mail From address) is part of the Accepted Domain (Authoritative or Internal Relay, External Relay domain will be treated as external).
  2. If the mail is submitted Anonymously or with Authentication.
  3. If recipient's address is part of Accepted domain or not.

If the “Mail From” is part of the Accepted Domain, and the session is also authenticated, the mail will be treated as Outbound mail and the “Address Rewrite Outbound Agent” will work. If the “Mail From” is not part of the Accepted Domain or the session is not authenticated, the mail will be treated as Inbound and the “Address Rewrite Inbound Agent” will work. We also have to remember the Address Rewrite Inbound Agent (Priority 2) works before the Address Rewrite Outbound Agent (Priority 10).

Let’s discuss various scenarios and which of the Address Rewrite Agents will work on each of these situations. These scenarios are true for both on-premises and Hybrid environments:

Scenario Result Message is submitted from one of the internal addresses (sender’s address is part of the Accepted Domains) to another internal address (recipient’s address is also part of Accepted Domain) Neither Address Rewrite Inbound or Address Rewrite Outbound will work on this message. As the sender address is internal, the Address Rewrite Inbound Agent will be skipped. As the recipient has an internal address, Address Rewrite Outbound will be skipped also. Message is submitted from one of the internal users to an external recipient. But the sender’s primary SMTP address is not part of the Accepted Domains, something which can happen in a company merger/takeover scenario. Message is treated as sent by an external sender as the sender’s SMTP address is not part of the Accepted Domain. So, the mail will be treated as inbound mail and Inbound Address Rewrite will work although the recipient is external. Message is submitted from an internal address to an external recipient, but the session was not authenticated. For example, mail is anonymously sent from an application through a relay allowed Receive Connector to the Internet. Message is treated as sent by external sender as the session was not authenticated. So, the mail will be treated as Inbound and Inbound Address Rewrite will work. Message is submitted from an external address (sender’s address is not part of Accepted Domain), to an internal address (recipient’s address is part of Accepted Domain) The Address Rewrite Inbound agent will work as Exchange will treat this mail as originating from an external source, Address Rewrite Outbound will not work as the sender is treated as external. Message is sent from an external address (not part of Accepted Domain), and recipient’s address is also an external address (not part of Accepted Domain) The message will be treated as inbound as the sender is external address and Inbound Address Rewrite will work. As the mail is sent from external address, Exchange will not treat the mail as outbound and the Outbound Address Rewrite would not work in this scenario. Message is submitted from authentication source (from Outlook/Outlook on the web or through SMTP with authentication or to an Externally Secured Connector) and sender’s address is internal (part of Accepted Domain), and the recipient’s address is also an internal address (recipient's address is part of Accepted Domain) Neither Rewrite Agent will trigger. Address Rewrite Inbound will not work as the sender is Internal. Also, Address Rewrite Outbound will not work as the recipient is internal. Message is submitted from an authenticated source (from Outlook/Outlook on the web or through SMTP with authentication or to an Externally Secured Connector) and sender’s address is internal (part of Accepted Domain), and sent to an external address (recipient’s address not part of Accepted Domain) Mail is sent from an internal address and from an authenticated source, so the sender will be treated as Internal and mail will be treated as Outbound. Address Rewrite Inbound agent will not work in this case. Address Rewrite outbound agent will work, and the Mail From/From address would change.

 

Based on the above scenarios, it is clear the Address Rewrite Outbound agent will work only when the sender’s SMTP address is internal, and the session is authenticated. There might be situations where mail is submitted from an application or third-party source using an internal address, but it can’t authenticate against Exchange, and you want the Address Rewrite Outbound agent to work on these messages. You can force Exchange to treat the message as submitted from an authenticated source by creating a Receive Connector with the “ExternalAuthoritative” Authentication mechanism. Make sure you only have the IP address of the application or third-party source under the remote IP Address range in this receive connector. This is important, since when you select ExternalAuthoritative for authentication, you’re telling Exchange to completely trust the IP address(es) or subnets specified in the RemoteIPRanges parameter of that connector, allowing those IP addresses to relay through your server.

You can run the below commands to create a connector with ExternalAuthoritative Authentication enabled:

New-ReceiveConnector -Name “Application relay” -RemoteIPRanges 192.168.0.1 -Usage custom -AuthMechanism Tls -PermissionGroups AnonymousUsers, ExchangeUsers, ExchangeServers -Bindings 0.0.0.0:25
Set-ReceiveConnector -Name “Application relay” -AuthMechanism ExternalAuthoritative

After running the above commands, mail received from IP Address 192.168.0.1 will be treated as Authenticated and trusted and if the sender address is part of the accepted domain, the Outbound Address Rewrite agent will work on them.

In this post, I tried to cover as many scenarios as possible. However, if you have something which does not match any of those scenarios and you are facing an issue setting up the Address Rewrite, please leave details in the comment section.

Arindam Thokder

Looking back at Microsoft Ignite 2017

Exchange Team Blog -

Ignite 2017 was busy and fun! We loved talking to many of you, answering many of your questions and listening to your feedback. Many teams are still collecting their thoughts into action items and following up with many of you. We also walked. A lot. You know what we mean if you were there!

Most of the sessions are now online. As we usually do, we picked some of the sessions that are closely related to subjects we often talk about and provided the list below. There are many more sessions available than the following list:

Keynotes:

Core Exchange / Exchange Online:

Hybrid:

Groups:

Protection:

Outlook:

See you next year!

We have already announced that Ignite 2018 is going to be back in Orlando! Pre-registration is available!

The Exchange Team

Exchange Server 2019

Exchange Team Blog -

We wanted to post a quick note on our blog to mention to all that at Microsoft Ignite 2017 we have announced that we will be releasing Exchange Server 2019 as an on-premises release to our customers.

We are looking forward to sharing more details about this release with you in calendar year (CY) 2018. We expect to release a preview in mid CY 2018 with the final release near the end of CY 2018. Please review our TAP program post, as we will be looking for more customers to help us validate this release!

The Exchange Team

TAP: Outlook mobile support for Exchange on-premises with Microsoft Enterprise Mobility + Security

Exchange Team Blog -

As announced at Ignite 2017, Outlook for iOS & Android will soon be fully powered by the Microsoft Cloud for hybrid Exchange on-premises customers. These updates will also provide support for management via Microsoft Intune, included in Enterprise Mobility + Security (EMS). This article outlines what the changes will provide for customers and how to apply to participate in the Technology Adoption Program (TAP) for this new architecture.

Overview of the new Microsoft Cloud architecture for Exchange Server customers

For Exchange Server mailboxes, Outlook mobile’s new architecture will be similar in design to our legacy architecture. However, as the service is now built directly into the Microsoft Cloud (using Office 365 and Azure) customers receive the additional benefits of security, privacy, built-in compliance and transparent operations that Microsoft commits to in the Office 365 Trust Center and Azure Trust Center.

Data passing from Exchange Online to the Outlook app is passed via a TLS-secured connection. The protocol translator running on Azure serves to route data, commands and notifications, but has no ability to read the data itself.

The Exchange ActiveSync connection between Exchange Online and the on-premises environment enables synchronization of the user's on-premises data and includes 4 weeks of email, all calendar data, all contact data, and out of office status into your Exchange Online tenant. This data will be removed automatically from Exchange Online after 30 days of inactivity.

Data synchronization between the on-premises environment and Exchange Online happens independent of user behavior. This ensures that we can send new messages to the devices very quickly.

Benefits of the new Microsoft Cloud-based architecture

In order to deliver the best possible experience for our customers, we built Outlook for iOS & Android as a cloud-backed application. This means your experience consists of a locally installed app powered by a secure and scalable service running in the Microsoft Cloud.

Processing information in the Microsoft Cloud enables advanced features and capabilities, such as the categorization of email for the Focused Inbox, customized experience for travel and calendar, improved search speed and more. It enhances Outlook’s performance and stability, relying on the cloud for intensive processing and minimizing the resources required from users' devices. Lastly, it allows Outlook to build features that work across all email accounts, regardless of the technological capabilities of the underlying servers (e.g. different versions of Exchange, Office 365, etc.).

Specifically, this new architecture has the following improvements:

    1. EMS Support: Customers can take advantage of Microsoft Enterprise Mobility + Security (EMS) including Microsoft Intune and Azure Active Directory Premium to enable Conditional Access and Intune App Protection policies to control and secure corporate messaging data on the mobile device.
    2. Fully powered by Microsoft Cloud: The mailbox cache is moved off AWS, and is now built natively in Exchange Online. It provides the benefits of security, privacy, compliance and transparent operations that Microsoft commits to in the Office 365 Trust Center.
    3. OAuth protects user’s passwords: Outlook will leverage OAuth to protect user’s credentials. OAuth provides Outlook with a secure mechanism to access the Exchange data without ever touching or storing a user’s credentials. At sign in, the user authenticates directly against an identity platform (either Azure AD or an on-premises identity provider like ADFS) and receives an access token in return, which grants Outlook access to the user’s mailbox or files. At no time does the service have access to the user’s password in any form.
    4. Provides Unique Device IDs: Each Outlook connection will be uniquely registered in Microsoft Intune and be able to be managed as a unique connection.
    5. Unlocks new features on iOS & Android: This update will enable the Outlook app to take advantage of native Office 365 features that are not supported in Exchange on-premises today, such as leveraging full Exchange Online search and Focused Inbox. These features will only be available when using the Outlook apps for iOS & Android.

Note: Device management through the Exchange Admin Center will not be possible; Intune is required to manage mobile devices.

Other notes about Outlook mobile, Exchange Server & EMS
  • Managing mobile devices: Microsoft Intune is the only way to manage the devices and perform wipe operations. Individual device IDs will not be manageable in the on-premises Exchange environment.
  • Support for Exchange Server 2007: Users with an Exchange Server 2007 mailbox will be unable to access their email and calendar in Outlook for iOS & Android as Exchange Server 2007 is not in mainstream support.
  • Support for Exchange Server 2010: Exchange Server 2010 SP3 is out of mainstream support and will not work with Intune-managed Outlook mobile. In this architecture, Outlook mobile utilizes OAuth as the authentication mechanism. One of the on-premises configuration changes performed enables the OAuth endpoint to the Microsoft Cloud as the default authorization endpoint. When this change is made, clients can start negotiating the use of OAuth. As this is an organization-wide change, Exchange 2010 mailboxes fronted by either Exchange 2013 or 2016 will incorrectly think they can perform OAuth and will end up in a disconnected state as Exchange 2010 does not support OAuth as an authentication mechanism.
Technical and licensing requirements

Our new architecture will have the following technical requirements:

  1. Exchange on-premises setup:
    • A minimum of cumulative update (CU) deployment on all Exchange servers of Exchange Server 2016 CU6 or Exchange Server 2013 CU17.
    • All Exchange 2007 or Exchange 2010 servers must be removed from the environment.
  2. Active Directory Synchronization: Active Directory synchronization with Azure Active Directory via Azure AD Connect. Ensure the following attributes are synchronized:
    • Office 365 ProPlus
    • Exchange Online
    • Exchange Hybrid writeback
    • Azure RMS
    • Intune
  3. Exchange hybrid setup: Requires full hybrid relationship between Exchange on-premises with Exchange Online.
    • Hybrid Office 365 tenant is required that is configured in full hybrid configuration mode and is setup as specific in the hybrid configuration guide.
    • Requires an Office 365 Enterprise, Business or Education tenant.
    • The mailbox data will be synchronized in the same datacenter region where that Office 365 tenant is setup. For more about where Office 365 data is located, visit the “Where is my data?” section Office 365 Trust Center.
    • Use of Office 365 US Government Community and Defense, Office 365 Germany and Office 365 China operated by 21Vianet tenants will not be supported at launch.
    • The external URL hostname for EAS must be published as a service principal to AAD through the Hybrid Configuration Wizard.
    • Autodiscover and EAS namespaces must be accessible from the Internet and support anonymous connections.
  4. EMS setup: Both cloud only and hybrid deployment of Intune is supported (MDM for Office 365 is not supported).
  5. Office 365 licensing*: One of the following Office 365 licenses for each user that includes the Office client applications required for Outlook for iOS & Android commercial use:
    • Commercial: Enterprise E3, Enterprise E5, ProPlus or Business licenses
    • Government: U.S. Government Community G3, U.S. Government Community G5
    • EDU: Office 365 Education E5
  6. EMS licensing*: One of the following licenses for each user:
    • Intune standalone + Azure Active Directory Premium standalone
    • Enterprise Mobility + Security E3, Enterprise Mobility + Security E5

*Microsoft Secure Productive Enterprise (SPE) includes all licenses necessary for Office 365 and EMS.

Data Security, Access, and Auditing Controls

Data within Exchange Online is protected via a variety of mechanisms. The Content Encryption whitepaper discusses how BitLocker is used for volume-level encryption. Service Encryption with Customer Key as discussed in the Content Encryption whitepaper will be supported in this architecture, but note that the user must have an Office 365 Enterprise E5 (or the corresponding versions of those plans for Government or Education) license to have an encryption policy assigned.

By default, Microsoft engineers have zero standing administrative privileges and zero standing access to customer content in Office 365. The Admin Access whitepaper discusses personnel screening, background checks, Lockbox and Customer Lockbox, and more.

ISO Audited Controls on Service Assurance documentation provides the status of audited controls from global information security standards and regulations that Office 365 has implemented.

Participating in the Technology Adoption Program (TAP)

Prior to rolling this updated architecture out to all customers, we are looking for customers to participate in the TAP. The TAP will allow Microsoft to work closely with customers to deploy the solution, and validate that it meets the needs and requirements of our customers.

What is in it for TAP customers:

  • Direct engagement and support from product engineering
  • Deployment assistance and support
  • Early product training
  • Regular conference calls
  • Opportunity to provide input and feedback that will be integrated into the product

What do customers have to commit to in order to participate in the TAP:

  • Must sign a non-disclosure agreement with Microsoft
  • Willing to work closely with Microsoft during TAP program, share any issues, bugs and feedback
  • Code Deployment: Must deploy pre-production Exchange Server software in production.
  • Wiling to deploy more than 25 devices utilized by real-world users
  • Deploy to production mailboxes that vary in size (medium, large, and very large)

To nominate yourself for the TAP, please work with your account team.

Additional technical requirements for participating in the TAP

In addition to the evergreen technical requirements outlined above, these additional requirements are necessary during the TAP program period:

  • Authentication support: OAuth is the only supported authentication mechanism.
  • Exchange mobile device access policies (also known as ABQ policies): these are not supported. ABQ policies from Exchange Server on-premises will block syncs from cloud. ABQ policies setup in Office 365 will not be enforced.
  • Exchange mobile device mailbox policies (also known as EAS policies): these will not be enforced by Outlook mobile. This means users must be managed by Intune to receive security policies.

If you have any questions, please let us know.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Ask the Perf Guy: Update to scalability guidance for Exchange 2016

Exchange Team Blog -

I’m happy to announce a significant update to our scalability guidance for Exchange 2016. Effective immediately, we are increasing our maximum recommended memory for deployments of Exchange 2016 from 96 GB to 192 GB.

This change is now reflected within our Exchange 2016 Sizing Guidance, as well as the latest release of the Exchange Server Role Requirements Calculator.

We have received ongoing feedback that the previous recommended maximum memory size of 96 GB was far too limiting, and that it was difficult to purchase modern hardware with memory of that size. We are aware that this has led to many difficult architectural choices, and we have been evaluating multiple types of larger hardware in our Exchange Online deployments to get to a significant level of comfort that customers will not experience issues with utilization of memory up to this size.

At this time, we are not raising the recommended maximum processor core count. While we are evaluating hardware with core counts dramatically larger than 24, we have additional work to do within the Exchange product to be able to safely recommend those core counts.

In summary, the updated Exchange 2016 processor and memory scalability guidance is as follows:

Recommended Maximum Processor Core Count

24

Recommended Maximum Memory

192 GB

Hopefully this helps to resolve some of the architectural challenges we have been hearing about.

Jeff Mealiffe
Principal PM Manager
Office 365 Customer Experience

Migrate your public folders to Office 365 Groups

Exchange Team Blog -

Over the last few months, we ran a TAP Program where our customers tested the batch migration process to move their public folders (both online and on-premises) to Office 365 Groups. We want to thank all of the customers who helped us out with the testing by sharing their experiences with us. The TAP program proved successful, and so we are now making this process available worldwide.

We encourage you to read Migrate your public folders to Office 365 Groups to learn about the advantages Office 365 Groups offers over public folders in a number of scenarios. Hopefully, you’ll want to migrate your own public folders to Office 365 Groups.

If you’ve already decided to migrate, you can click one of the following links to understand the step-by-step details of the migration process, which is dependent upon the current version of your Exchange environment.

Enjoy!

Public folder team

Released: September 2017 Quarterly Exchange Updates

Exchange Team Blog -

The latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013 are now available on the download center.  These releases include fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Minimum supported Forest Functional Level is now 2008R2

In our blog post, Active Directory Forest Functional Levels for Exchange Server 2016, we informed customers that Exchange Server 2016 would enforce a minimum 2008R2 Forest Functional Level requirement for Active Directory.  Cumulative Update 7 for Exchange Server 2016 will now enforce this requirement.  This change will require all domain controllers in a forest where Exchange is installed to be running Windows Server 2008R2 or higher.  Active Directory support for Exchange Server 2013 remains unchanged at this time.

Support for latest .NET Framework

The .NET team is preparing to release a new update to the framework, .NET Framework 4.7.1.  The Exchange Team will include support for .NET Framework 4.7.1 in our December Quarterly updates for Exchange Server 2013 and 2016, at which point it will be optional.  .NET Framework 4.7.1 will be required on Exchange Server 2013 and 2016 installations starting with our June 2018 quarterly releases.  Customers should plan to upgrade to .NET Framework 4.7.1 between the December 2017 and June 2018 quarterly releases.

The Exchange team has decided to skip supporting .NET 4.7.0 with Exchange Server.  We have done this not because of problems with the 4.7.0 version of the Framework, rather as an optimization to encourage adoption of the latest version.

Known unresolved issues in these releases

The following known issues exist in these releases and will be resolved in a future update:

  • Online Archive Folders created in O365 will not appear in the Outlook on the Web UI
  • Information protected e-Mails may show hyperlinks which are not fully translated to a supported, local language
Release Details

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

Exchange Server 2016 Cumulative Update 7 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 18 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 18. 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 CU18, 2016 CU7) or the prior (e.g., 2013 CU17, 2016 CU6) 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 availability of 250,000 public folder Exchange 2010 hierarchy migrations to Exchange Online

Exchange Team Blog -

Last September, we announced a beta program to validate onboarding of public folder data from Exchange 2010 on-premises to Exchange Online with large public folder hierarchies (100K – 250K public folders).

We are glad to announce that Exchange Online now officially supports public folder hierarchies of up to 250K public folders in the cloud – more than double the previously supported limit of 100K public folders!

In line with our efforts to help larger customers onboard to Exchange Online, we would like to additionally announce support for the migration of public folders from on-premises Exchange 2010 to Exchange Online, for customers with folder hierarchies up to 250K.
What does all this mean?

  • All existing customers using Exchange Online who would have been constrained by the limit of 100K public folders, can now expand their Exchange Online public folder hierarchy up to 250K folders.
  • Any on-premises customers running Exchange 2010 with up to 250K public folders, who would like to onboard to Exchange Online, can now do so.

Note: At this point in time, Exchange 2013/2016 customers with over 100K folders can still only migrate up to 100K public folders to Exchange Online. However, once they have migrated to Exchange Online, they can expand their hierarchy up to 250K public folders. We are working to resolve this limitation for our Exchange 2013/2016 customers in the future.

Keep checking this blog for further updates on the subject.

Public folder team

Modern public folders logging and when to use it

Exchange Team Blog -

Hello again! In our last article, we discussed recommendations for deployment of public folders and public folder mailboxes. In this post, we will be discussing methods and tips for monitoring connections being made to the Public Folder mailboxes with the help of different log types available in Exchange Server 2013 and Exchange Server 2016. This article mainly focuses on logging related to public folder mailbox activity and provides information on how to analyze these logs to get the information on the usage of public folders. Let’s get to it!

How do I log and report on different public folder connections?

As we discussed in previous post, the ability to estimate the number of connections being made to public folder mailboxes is very helpful as deployment guidance for public folders partially revolves around connection counts. As of today, currently available logging methods will not reveal individual names of public folders clients are connecting to but will contain information about public folder mailboxes being accessed by clients.

Depending on what information you are looking to gather there are several flavors of logging you can consider.

  • Autodiscover logs – use these to learn which public folder mailboxes Outlook clients get sent to during the Autodiscover process.
  • Outlook Web App logs – use these to learn which default public folder mailboxes Outlook Web App clients get sent to during connection process. As stated in our first article, the default public folder mailboxes could be either the ones which are provided randomly to the requesting OWA client or could be a hard coded default public folder mailbox assigned to a specific user’s mailbox.
  • RPC Client Access logs & MAPI Client Access on Microsoft Exchange 2013 Mailbox Servers – use these to find out which public folder mailboxes on a specific mailbox server the users are connecting using RPC/HTTP and MAPI/HTTP protocols. These logs can be used with Microsoft Exchange 2013.
  • MAPI/HTTP logs in Microsoft Exchange 2016 Servers – learn which public folder mailboxes your MAPI/HTTP clients are connecting to. These logs should only be used with Microsoft Exchange 2016.

Let’s get started! In the upcoming section, we are going to make extensive use of Log Parser Studio (LPS) tool which will be used to parse the logs to help get the required data. It is a great tool and if you are not aware of it, I would recommend you to first visit the following links and get yourself familiarized with it first:

Autodiscover logs: Which public folder mailboxes are Outlook clients connecting to? Why do Autodiscover logs need to be investigated?

The Autodiscover service is responsible for informing Outlook clients where and how to connect to a public folder mailbox. This may be so Outlook can display the public folder hierarchy tree, or to make a public logon connection to access content within a public folder mailbox.

Thus, the Autodiscover logs can be useful to administrators in determining which public folder mailboxes are being returned by the Autodiscover service. This information can be very helpful in large multi-site environments when trying to identify possible improvements in public folder mailbox or public folder locations.

To understand this better let’s consider a common scenario that an administrator might face in the environment. An administrator may need to determine which public folder mailboxes are being returned to the end users when they connect from different sites using Outlook. This can be a challenging task if there are many sites and users resulting in a huge data set. Rather than try to analyze the data manually there needs to be an automated way which can get the desired outcome.

This is where the Log Parser Studio (LPS) queries can be used to parse the Autodiscover logs on mailbox servers to get us the required data for further investigation and actions.

Where are Autodiscover logs located?

Autodiscover logs should be investigated on Mailbox servers and can be found in the following default path for Microsoft Exchange 2013/2016:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\Autodiscover

(The location may change if the installation path is different from the default.)

Autodiscover Method 1, server-side.

At this point it is assumed Log Parser Studio has been installed.

1. Open the Log Parser Studio by double clicking the LPS.exe application file as shown in the below image which will launch the LPS.

2. Once the LPS launches, at the top of the left corner, select File and then click on New Query which will open new tab for query

3. Copy the sample query mentioned in the example below to the query section and set the Log Type to EELXLOG

/* New Query */
SELECT Count(*) As Hits,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'Caller='), 0, ';') as User-Name,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ResolveMethod='), 0, ';') as Method,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ExchangePrincipal='), 0, ';') as PF-MBX,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'epSite='), 0, ';') as Site-Name
FROM '[LOGFILEPATH]'
WHERE Method LIKE '%FoundBySMTP%'
GROUP BY User-name, Method, PF-MBX, Site-Name
/* End Query */

4. Lock the query to avoid any modifications by clicking on the Lock icon once as shown below

5. Click on the Log file manager button available at the top panel window of LPS to add required logs as shown in the below image.

6. Specify the log location of the required log files and select one file in the folder where the logs reside and click Open and hit OK

7. In this example, I have accessed and selected logs from a specific mailbox server by specifying the UNC path of the server and log location. It is possible to add multiple folders of same log type from different servers and parse all of them at same time.

8. The only thing left is to execute the query and to do so just click the execute query button. in the LPS panel. The output will be similar format to the one shown

Note: This LPS query will provide a report that includes information on what users are connecting to what public folder mailboxes along with the Active Directory site the mailbox resides in:

Why might this type of report be useful?

The output of this data may help an administrator determine if a significant number of users in a geographic location would benefit from a public folder mailbox to be located closer to them. Depending on the results administrator can make decision to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) in those geographic sites and then set the DefaultPublicFolderMailbox property on the mailboxes so that they contact the PF Mailbox (HOSPFM) in their own site for fetching the public folder hierarchy information and in turn the user experience while accessing public folders will be better!

One more point to be noted is that only Microsoft Exchange 2016 Autodiscover logs will show the Site Name. This logging feature functionality is not present in Microsoft Exchange 2013 and will require additional manual work to figure out the site location of the mailbox.

Note: The example query will return additional Autodiscover log entries for non-public folder mailbox queries. If you have standardized naming convention for your public folder mailboxes you could enhance the query to only return results where the ExchangePrincipal value contains a portion of your naming convention.

Autodiscover Method 2, client-side.

You can also use the Test E-mail AutoConfiguration tool from within the Outlook client to perform a single user test. This will provide you with which public folder mailbox is being returned to a single end user by Autodiscover service for hierarchy connections.

To start the Test E-mail AutoConfiguration tool, follow these steps:

  1. Start Outlook.
  2. Hold down the Ctrl key, right-click the Outlook icon in the notification area, and then click Test Email AutoConfiguration.
  3. Verify that the correct email address is in the E-mail Address box. You do not need to provide a password if you are running a test for the currently logged in user. If you are testing a different user account than the one currently logged into the machine, then you will need to provide both the email address and password for that account.
  4. In the Test Email AutoConfiguration window, click to clear the Use Guessmart check box and the Secure Guessmart Authentication check box.
  5. Click to select the Use Autodiscover check box, and then click Test.

Below is the excerpt from the XML File gathered from Test E-mail AutoConfiguration:

As you can see above the user administrator@contoso.com will be using the public folder mailbox HOSPFM-001@contoso.com to make a hierarchy connection.

Please note this is only an example; if you follow our guidance you will not have any users making connections to your primary public folder mailbox for hierarchy or content.

Outlook Web App logging: which default public folder mailboxes do Outlook Web App clients get sent to?

When users log into Outlook on the Web (OWA) in an environment with public folders, the public folder mailbox used for hierarchy information could be a static default public folder mailbox (if one has been set manually on the mailbox), or a random public folder mailbox. It should be noted Autodiscover is not utilized when accessing public folders using OWA. Instead, OWA uses its own function to return a default public folder mailbox to the requesting user. As such, you will not find OWA users in the previously mentioned Autodiscover logs.

Location of OWA logs

All logging data for Outlook on the Web (OWA) including public folder access will be in the following folder on Exchange 203 Client Access Servers or Exchange 2016 Mailbox Server:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa

Here is an example of a Log Parser Studio query to fetch data from OWA logs:

/* New Query */
SELECT COUNT(*) as hits,
AnchorMailbox AS PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction
FROM '[LOGFILEPATH]'
WHERE PF-MBX LIKE '%smtp%'
GROUP BY PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction
ORDER BY hits ASC

Log type is set to EELXLOG

Fields used in Query Field Description AnchorMailbox The default public folder mailbox being returned to the user AuthenticatedUser Users accessing the PF mailbox ProtocolAction Action being taken by the user while accessing public folder such as GetFolder, Getitem, Createitem, Finditem TargetServer Provides information on which Exchange Server the query is being redirected to fetch the public folder mailbox HttpStatus & BackEndStatus Provides information on connection status for the public folder mailbox connection

Output is as follows:

In the output below the AnchorMailbox value is the public folder mailbox the end user is accessing for their hierarchy connection.

In the above sample result, the user “Administrator” is logged into OWA and is accessing public folder mailbox HOSPFM-001 which is returned as default public folder mailbox. We know Administrator is using this public folder mailbox for a hierarchy connection as OWA logging currently does not capture information for public folder content access.

In Log Parser Studio, you can save this query and execute it in batches to get concurrent logging. You can also add entire folder instead of individual logs which will make it easier to parse existing and newly written logs. The number of hits returned and being logged against specific public folder mailbox by the user will reveal the public folder mailboxes which are most often being used for fetching hierarchy information.

How can this logging be useful?

Since OWA does not use Autodiscover to fetch a default public folder mailbox, it may make sense to identify the public folder mailboxes being returned to users when they use OWA. Like our earlier example for Outlook, it may identify cases were OWA is using public folder mailboxes that are a less optimal performance choice. Keep in mind that for OWA a better performing hierarchy mailbox is one closer to the Exchange mailbox server where OWA is being rendered rather than one closer to where the user’s Outlook client sits. Depending on your Exchange deployment and where OWA is served this may mean making choices about your public folder mailbox deployment based on what client is more often used in your environment to provide that client more optimal experience.

As mentioned in my earlier post the recommendation for users in geographically disperse sites is to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) and set the DefaultPublicFolderMailbox property on the user mailboxes in those sites to ensure a public folder mailbox within the Site is being used by the respective users for hierarchy.

RPC Client Access logs & MAPI Client Access logs on Mailbox Servers (Microsoft Exchange 2013)

While AutoDiscover logs can provide information about public folder mailboxes Outlook is learning about and may potentially connect to, the RPC Client Access (RPC/HTTP) & MAPI Client Access (MAPI/HTTP) logs will provide information about actual public folder mailbox connections established by users.

Both log types in this case can be combined in LPS in single query and parsed to get some useful information on Public folder mailboxes being accessed.

Default location of logs:

  • MAPI Client Access: C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access
  • RPC Client Access: C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access
Which public folder mailboxes on a specific server are users connecting to?

Consider the scenario consisting of a multi-site environment where the administrator is given a task to determine which users are connecting to public folder mailboxes on a specific server. Let’s say E15-CLASS-MB1 is the Mailbox server hosting the public folder mailboxes and the administrator needs to find who is making connections to them. Depending on the results decisions can be made whether or not it makes sense to move certain public folder mailboxes closer to a certain user location based on who actually uses that public folder mailbox. Below are the steps to be followed:

1. Open the LPS on the machine. Copy and paste the query below in the New Query Window in LPS as per the instructions mentioned earlier in the post.

/* Public Folder Mailboxes Hits */
SELECT Count(*) as Hits,
operation as Operation,
user-email as [SMTP Address],
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'Logon:'), 0, ';') as MailBox-LegacyExchangeDN,
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'on '), 0, ';') as Server
INTO '[OUTFILEPATH]\GeoReport.CSV'
FROM '[LOGFILEPATH]'
WHERE operation-specific LIKE '%Logon: Public%' AND Server LIKE '%E15-CLASS-MB1%'
GROUP BY Operation, Mailbox-LegacyExchangeDN, Server, [SMTP Address]
ORDER BY hits DESC

Fields used in query:

Field Description Operation Used to extract the logons for public folder mailboxes SMTP Address Email address of the users accessing the public folder mailbox Mailbox LegacyExchangeDN Public folder mailboxes in form of LegacyExchangeDN Server Connection requests coming to the server

2. Set the Log File type to EELLOG. Add the required folders to parse from respective mailbox servers and start the query by clicking Query button in LPS Panel.

3. The above sample query exports the results in CSV format. If there is no specific location specified in the query to export the report the default export directory will be used.

4. Once the query has finished executing, it will export the output to a CSV file, which can be further formatted as table.

5. To do so Open the CSV file. By default, the CSV file will not have any formatting and will show the output in similar format.

6. Select all the cells which contains the data and then select Insert tab and click on Table which will open a new pop-up window to Create Table. Click on OK button

7. A new table will be created in structured format to help sort the data and filter it.

8. The filtering can be used to sort the data by available fields such as SMTP Address, Mailbox-LegacyExchangeDN

If the LegacyExchangeDN output is trimmed and you cannot figure out the full public folder mailbox name, then you can copy the LegacyExchangeDN value of the public folder mailbox in Exchange PowerShell and use it to find the name of relevant mailbox as shown below:

You now have information regarding public folder mailboxes being actively used by users on the server. Not only which ones, but also the frequency. This can be utilized by the administrator to make public folder deployment decisions.

MAPI/HTTP Logs (Exchange 2016 Only)

In Microsoft Exchange 2016 there is one additional folder created specially to log MAPI/HTTP protocol traffic. Recent updates to Exchange 2016 have removed MAPI/HTTP traffic from the MAPI Client Access log. If not all of your Outlook for Windows clients are connecting to Exchange 2016 via MAPI/HTTP you may need to analyze both logs to get a full picture of your public folder mailbox connections until such time that all Outlook for Windows clients are using MAPI/HTTP. All MAPI/HTTP logging is now logged in to the MapiHttp folder.

The logs reside in the following default path:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\MapiHttp\Mailbox

Exchange Server 2016 uses slightly different field names for MAPI/HTTP logging, and a query used previously with Exchange Server 2013 for parsing the MAPI/HTTP traffic in the older MAPI Client access logs will no longer work with Exchange Server 2016.

Which public folder mailboxes are your MAPI/HTTP clients connecting to?

MAPI/HTTP logs can be investigated for connections established to public folder mailboxes over the MAPI/HTTP protocol in Exchange Server 2016 using the below query in Log Parser.

Ensure the Log Type is set to EELXLOG

/* New Query */
SELECT Count(*) as Hits,MailboxId AS PF-Mailbox, MDBGuid AS Database, ActAsUserEmail AS SMTP-Address, SourceCafeServer FROM '[LOGFILEPATH]'
WHERE OperationSpecific LIKE '%PublicLogon%'
GROUP BY PF-Mailbox,Database,SMTP-Address, SourceCafeServer
ORDER BY Hits DESC

Fields used in this query: Field Description Operation-Specific Used to extract the logons for public folder mailboxes SMTP Address Email address of the users accessing the public folder mailbox PF-mailbox Mailbox Guid of PF mailbox SourceCafeServer Connection request coming to the server Database Shows which specific mailbox database which host public folder mailboxes is being connected to

Once the query is executed it will gather the information and will populate the results in the below format which can be exported to CSV and output can be gathered in batches by running the query in batches to fetch more data.

Sample output:

In Exchange 2016 MAPI/HTTP logs, the name of the public folder mailbox is not revealed but, the log does capture the mailbox GUID of the public folder mailbox which can be used in PowerShell command to fetch the actual public folder mailbox name.

Note: If there are any users hosted in Exchange 2016 who still use the RPC/HTTP protocol, the RPC/HTTPS query previously shown can be used to fetch the data for these specific users.

How this data can be useful to administrators?

The administrators can run this report repeatedly in batches and gather the data in CSV file. The data can be collated for the results from different batches and investigated for public folder mailboxes being accessed frequently by the users. From there administrators should be able to find if there are any public folder mailboxes being used heavily by the users and then make decision to move any specific public folder mailboxes or maybe even specific public folders closer to users in specific location.

There are so many log types. When should I use what?

It is true there are many different logs in Exchange Sever showing similar information. Depending on what protocol your users use you may make decisions on the log type to parse. Autodiscover logs will give a combined view of what public folder mailboxes users are at least trying to access once. If you have content-only public folder mailboxes in your environment that are excluded from serving hierarchy and not directly assigned to users as their default, you may be able to determine if some are never accessed and may contain content worthy of purging. If you need a more granular view of the world, and the ability to generate some sort of heat map you may choose to go with more protocol specific logs. These logs will provide data on each time the client creates a new connection to a public folder mailbox and allow you to determine more than just if the client learned about it through Autodiscover but if it is being used far more heavily by many users over time. The options are varied and up to you to choose based on your need.

Summary

In this post, I have discussed and provided information on different types of public folder logging and how this logging can be useful to administrators to identity heavily used public folder mailboxes, which in turn can be used to do planning and deployment of public folders in the environment. In upcoming posts, we will discuss topics related to public folder management and quota related information

I would like to thank Brian Day, Ross Smith IV & Nasir Ali for their inputs while reviewing this content and validating the guidance mentioned in the blog post, Special thanks to Kary Wall for providing inputs with Log parser studio queries and Nino Bilic for helping to get this blog post ready!

Siddhesh Dalvi
Support Escalation Engineer

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