10/12/2015

Home

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

Library

Forums

Wiki

TechCenter

Exchange Server 2016 Architecture

Ross Smith IV 5 May 2015 12:30 PM

34

389
Tw eet

702
Exchange Server 2016 builds upon the architecture introduced in Exchange Server 2013, with the continued focus goal of improving the architecture to serve
Like
the needs of deployments at all scales.

Building Block Architecture

In Exchange Server 2016, there is a single building block that provides the client access services and the high availability architecture necessary for any
enterprise messaging environment.

Figure 1: Building Block Architecture

In our continuing quest to improve the products capabilities and simplify the architecture and its deployment, we have removed the Client Access server CAS
role and added the client access services to the Mailbox role. Even without the CAS role, the system maintains loose coupling in terms of functionality,
versioning, user partitioning and geographical affinity.
The Mailbox server role now:
1. Houses the logic to route protocol requests to the correct destination endpoint.
2. Hosts all of the components and/or protocols that process, render and store the data.
No clients connect directly to the backend endpoints on the Mailbox server; instead, clients connect client access services and are routed via local or remote
proxy to the Mailbox server that hosts the active database that contains the users mailbox.
Mailbox servers can be added to a Database Availability Group DAG, thereby forming a high availability unit that can be deployed in one or more
datacenters. DAGs in Exchange Server 2016 do have a few specific enhancements:
1. DatabaseAvailabilityGroupIpAddresses is no longer required when creating a DAG. By default, the failover cluster will be created without an
administrative access point, as this is the recommended best practice.
2. Replay Lag Manager is enabled by default.
3. Lagged database copy play down can be delayed based on disk latency, thereby ensuring active users are not impacted. scheduled for a future
cumulative update CU
4. Database failovers times are reduced by 33% when compared to Exchange Server 2013. scheduled for a future CU
Removal of the separate CAS role does not affect how communication occurs between servers. Communication between servers still occurs at the protocol
layer, effectively ensuring that every server is an island. For a given mailboxs connectivity, the protocol being used is always served by the protocol instance
that is local to the active database copy.

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

1/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

Figure 2: Interserver communication in Exchange 2016

The load balancer configuration is also not affected by this architectural change. From a protocol perspective, the following will happen:
1. A client resolves the namespace to a load balanced virtual IP address.
2. The load balancer assigns the session to a Mailbox server in the load balanced pool.
3. The Mailbox server authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
a. Mailbox version for this discussion, we will assume an Exchange 2016 mailbox
b. Mailbox location information e.g., database information, ExternalURL values, etc.
4. The Mailbox server makes the decision to proxy the request or redirect the request to another Mailbox server in the infrastructure within the same
forest.
5. The Mailbox server queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active
copy.
6. The Mailbox server proxies the request to the Mailbox server hosting the active copy.
The protocol used in step 6 depends on the protocol used to connect to client access services. If the client request uses HTTP, then the protocol used between
the servers is HTTP secured via SSL using a selfsigned certificate. If the protocol used by the client is IMAP or POP, then the protocol used between the
servers is IMAP or POP.
Telephony requests are unique. Instead of proxying the request at step 6, the Mailbox server will redirect the request to the Mailbox server hosting the active
copy of the users database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging
services on the Mailbox server.

Figure 3: Client Protocol Connectivity

Now many of you may be thinking, wait how does authentication work? Well for HTTP, POP, or IMAP requests that use basic, NTLM, or Kerberos authentication,
the authentication request is passed as part of the HTTP payload, so the Client Access services within each MBX server will authenticate the request naturally.
Formsbased authentication FBA is different. FBA was one of the reasons why session affinity was required for OWA in previous releases of Exchange the
reason being that that the cookie used a per server key for encryption; so if another MBX received a request, it could not decrypt the session. With Exchange
2013, we stopped leveraging a per server session key and instead leveraged the private key from the certificate that was installed on the Client Access server.
With Exchange 2016, we now leverage the organization certificate that is configured for the organizations authorization configuration. This means that any
Exchange 2016 server can decrypt the cookie.
And yes, the Edge Transport server role will ship in Exchange Server 2016 and at RTM, to boot!. All the capabilities and features you had in the Edge
Transport server role in Exchange Server 2013, remain in Exchange Server 2016.

Why did we remove the Client Access server role?

The Exchange Server 2016 architecture evolves the building block architecture that has been refined over the course of the last several releases. With this
architecture, all servers in the Exchange environment excluding Edge Transport are exactly the samethe same hardware, the same configuration, and so
forth. This uniformity simplifies ordering the hardware, as well as performing maintenance and management of the servers.
As with Exchange 2010 and in Exchange 2013, we continue to recommend role colocation as a best practice. From a cost perspective, the overall goal is to

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

2/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

ensure that the architecture is balanced for CPU and disk. Having separate server roles can result in longterm cost disadvantages as you may purchase more
CPU, disk, and memory resources than you will actually use. For example, consider a server that hosts only the Client Access server role. Many servers enable
you to add a given number of disks in a very economical fashionwhen you are deploying and using that number of disks, the cost is essentially zero. But if
you deploy a server role that uses far less than the given number of disks, youre paying for a disk controller that is either underused or not used at all.
This architecture is designed to enable you to have fewer physical Exchange servers in your environment. Fewer physical servers mean lower costs for a variety
of reasons:
Operational costs are almost always higher than the capital costs. It costs more to manage a server over its lifetime than it does to purchase it.
You purchase fewer Exchange server licenses. This architecture only requires a license for one Exchange server and one operating system, while breaking
out the roles required multiple Exchange server licenses and multiple operating system licenses.
Deploying fewer servers has a trickledown effect across the rest of the infrastructure. For example, deploying fewer physical servers may reduce the total
rack and floor space required for the Exchange infrastructure, which in turn reduces power and cooling costs.
This architecture ultimately distributes the load across a greater number of servers than deploying singlerole servers because all Mailbox servers also handle
client access because:
Youre distributing the load across a greater number of physical machines, which increases scalability. During a failure event, the load on the remaining
servers only increases incrementally, which ensures the other functions the server is performing arent adversely affected.
The solution can survive a greater number of Client Access role or service failures and still provide service, which increases resiliency.

Key Architectural Improvements

Exchange Server 2016 also includes a number of architectural improvements, beyond the server role consolidation, including search enhancements, document
collaboration improvements, and more.

Search Improvements
scheduled for a future CU: One of the challenging areas for onpremises environment was the amount of data that was replicated with each database copy in
previous releases. In Exchange Server 2016, we have reduced bandwidth requirements between the active copy and a passive copy by 40%. This was
accomplished by enabling the local search instance to read data from its local database copy. As a result of this change, passive search instances no longer
need to coordinate with their active counterparts in order to perform index updates.
Another area of investment in search has been around decreasing the length of time to return search results, especially in online mode clients like OWA. This is
accomplished by performing multiple asynchronous disk reads prior to the user completing the search term, which populates the cache with the relevant
information, providing subsecond search query latency for online mode clients.

Document Collaboration
In previous releases of Exchange, OWA included document preview for Office and PDF documents, reducing the need to have a full fidelity client. SharePoint
2013 had a similar feature, however it used the Office Web Apps Server 2013 now rebranded as Office Online Server to accomplish this capability. Within
Office 365, we also leverage Office Online Server to provide this capability, ensuring uniform document preview and editing capability across the suite.
In Exchange Server 2016, we leverage Office Online Server to provide the rich document preview and editing capabilities for OWA. While this was a necessary
change to ensure a homogenous experience across the Office Server suite, this does introduce additional complexity for environments that dont have Office
Online Server.
The next generation of Office Online Server will not be supported for colocation with Exchange. Therefore, you must deploy a separate server farm
infrastructure. This infrastructure will require unique namespaces, and will require session affinity to be maintained at the load balancer.
While Exchange supports an unbound namespace model, the Office Online Server will require a bound namespace for each site resilient datacenter pair.
However, unlike the bound namespace model within Exchange, Office Online Server will not require any namespace changes during a datacenter activation.

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

3/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

Figure 4: Office Online Server Connectivity

Extensibility
scheduled for a future CU: Office 365 introduced the REST APIs Mail, Calendar, and Contact APIs, and now these APIs are available in Exchange Server 2016.
The REST APIs simplify programming against Exchange by providing a familiar syntax that is designed with openness e.g., open standards support JSON,
OAUTH, ODATA and flexibility e.g., granular, tightly scoped permission to access user data. These APIs allow developers to connect from any platform,
whether it be web, PC, or mobile. SDKs exist for.NET, iOS, Android, NodeJS, Ruby, Python, Cordova, and CORS for use in single page JavaScript web apps.
What about Exchange Web Services EWS? All existing applications that leverage EWS will continue to work with Exchange Server 2016. We are, however,
focusing new platform investments on the REST APIs and the apps for Office extensibility model. We expect to make significantly fewer investments in EWS so
that we can focus our resources on investing in a single modern API that will, over time, enable most of the scenarios that our partners currently use EWS.

Outlook Connectivity
Introduced in Exchange Server 2013 Service Pack 1, MAPI/HTTP is the new standard in connectivity for Outlook. In Exchange Server 2016, MAPI/HTTP is enabled
by default. In addition, Exchange Server 2016 introduces peruser control over this connectivity model, as well as, the ability to control whether the protocol
and Outlook Anywhere is advertised to external clients.
Note: Exchange Server 2016 does not support connectivity via the MAPI/CDO library. Thirdparty products and custom inhouse developed solutions need
to move to Exchange Web Services EWS or the REST APIs to access Exchange data.

Coexistence with Exchange Server 2013

In Exchange Server 2013, the Client Access server role is simply an intelligent proxy that performs no processing/rendering of the content. That architectural
tenet paid off in terms of forward coexistence. When you introduce Exchange Server 2016, you do not need to move the namespace. Thats right, the Exchange
Server 2013 Client Access infrastructure can proxy the mailbox requests to the Exchange 2016 servers hosting the active database copy! For the first time ever,
you get to decide when you move the namespace over to the new version. And not only that, you can even have load balancer pools contain a mix of Exchange
Server 2013 and Exchange Server 2016. This means you can do a oneforone swap in the load balancer pool as you add Exchange 2016 servers, you can
remove Exchange 2013 servers.

Topology Requirements
Exchange Server 2016 will only be supported on Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016 operating systems.
From an Active Directory perspective, Exchange Server 2016 will require:
Windows Server 2008 or later Active Directory servers.
Windows Server 2008 or higher Forest Functional Mode and Domain Functional Mode.
Exchange Server 2016 will only support coexistence with Exchange Server 2010 SP3 RU11 and Exchange Server 2013 CU10.

The Preferred Architecture

During my session at Microsoft Ignite, I revealed Microsofts preferred architecture PA for Exchange Server 2016. The PA is the Exchange Engineering Teams
best practice recommendation for what we believe is the optimum deployment architecture for Exchange 2016, and one that is very similar to what we deploy
in Office 365.
While Exchange 2016 offers a wide variety of architectural choices for onpremises deployments, this architecture is our most scrutinized one ever. While

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

4/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

there are other supported deployment architectures, they are not recommended.
The Exchange 2016 PA is very similar to the Exchange 2013 PA. A symmetrical DAG is deployed across a datacenter pair with active database copies distributed
across all physical servers in the DAG. Database copies are deployed on JBOD storage, with four copies perdisk. One of the copies is a lagged database
copy. Clients connect to a unified namespace that is equally distributed across the datacenters in the site resilient pair.
However, the Exchange 2016 PA differs in the following ways:
1. Exchanges unbound namespace model is load balanced across the datacenters in a layer 7 configuration that does not leverage session affinity.
2. An Office Online Server farm is deployed in each datacenter, with each farm having a unique namespace bound model. Session affinity is managed by
the load balancer.
3. The DAG is deployed without an administrative access point.
4. The commodity dualsocket server hardware platform contains 2024 cores and up to 96GB of memory, and a batterybacked write cache controller.
5. All data volumes are formatted with ReFS with the integrity feature disabled.
For more information, please see the Exchange 2016 Preferred Architecture article.

Summary
Exchange Server 2016 continues in the investments introduced in previous versions of Exchange by reducing the server role architecture complexity, aligning
with the Preferred Architecture and Office 365 design principles, and improving coexistence with Exchange Server 2013.
These changes simplify your Exchange deployment, without decreasing the availability or the resiliency of the deployment. And in some scenarios, when
compared to previous generations, the PA increases availability and resiliency of your deployment.

Ross Smith IV

Principal Program Manager

Office 365 Customer Experience

Updates
5/8/15: Added section on topology requirements.
7/8/15: Updated topology requirements.
10/1/15: Updated for RTM.
10/12/15: Added Preferred Architecture link.

Comments
Anon1 #

5 May 2015 9:49 PM

Ross : Thank you for this great Article. And Thank you for informing Exchange Server OnPremises customers worldwide.

JamesNT #

5 May 2015 10:15 PM

Ross,
Thank you for one of the best Exchange articles I have ever read. It looks like you guys are moving the bar up a few notches. And thank you to yourself and
Microsoft for not throwing us Private Cloud/OnPrem guys to the wolves. 0365 is a wonderful thing, it just isn't for us.
Question: Is there a supported upgrade scenario from Exchange 2010? Most of the upgrade stuff you mentioned involved 2013.
JamesNT

Brian Day [MSFT] #

6 May 2015 12:18 AM

@JamesNT, we will be talking migration/deployment at Ignite tomorrow. No fancy blog post prepped yet, but yes there is a path from 2010.

Satyajit321 #

6 May 2015 6:05 AM

This is exciting! Wonderful article. Thanks Ross for detailing this out for us.

Yaniv Totshvili #

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

6 May 2015 6:45 AM

5/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs
Thanks

Sidorenko Andrey #

6 May 2015 8:00 AM

Ross,
Thank you for this Article.
Question: What you mean by load balancer. This is separated hardware/software or i can use Windows NLB service as before ?

Mahmoud.Hanafi #

6 May 2015 9:19 AM

Thanks Ross for sharing such informative article.

Satyajit321 #

6 May 2015 9:37 AM

Q: Why do we need a "layer 7 configuration that does not leverage session affinity"
Is it we will be using the same Mailbox HLB for OWAS as well.
Q. "No clients connect directly to the backend endpoints on the Mailbox server" and "added the client access services to the Mailbox role".
Does it still behave like MultiRole 2013, which has 25, 2525 like ports segregation for FE,BE Services.

Exchange Queries #

6 May 2015 12:11 PM

Good Article...Two thing it concerns 1..." Exchange Server 2016 does not support connectivity via the MAPI/CDO library" ...is the Blackberry will not get
supported...2....Is there no other way company need to move and invest in HLB if they are staying in Windows NLB currently.. :

Jrg von der Ohe #

6 May 2015 1:08 PM

@Exchange Queries
if you are using BB 10 or higher you dont't need Mapi/CDO and i don't think that BB will support Exchange 2016 on their BES 5.x

Thomas Stensitzki MCSM MCM MCT #

6 May 2015 1:50 PM

As Jrd pointed out. Current versions of BES already can connect using EWS. CDO is so 80s.

Ross Smith IV #

6 May 2015 4:20 PM

Regarding the load balancer questions:

1. Windows Network Load Balancing will not be supported against Exchange 2016 for the simple reason that Windows Failover Clustering and Windows
NLB cannot coexist. Therefore, a thirdparty solution must be deployed. it doesn't have to be a hardware device, though. There are many softwarebased
load balancing solutions available. Ultimately, it will depend on your requirements and the capability of the device.
2. As to why the specific recommendation on the layer 7 architecture. With Exchange 2013 and later you have great flexibility in your load balancing
architecture session affinity is no longer required as we maintain it within the software stack. This opens up possibilities to use layer 4, however that
comes with a price perserver availability vs. perprotocol availability. Layer 7 without session affinity allows you to deploy a single unified namespace
while also achieving perprotocol availability. I discuss all of the scenarios here http://blogs.technet.com/b/exchange/archive/2014/03/05/loadbalancing
inexchange2013.aspx. We feel that perprotocol availability provides better resiliency, hence the recommendation.
Ross

Exchange Queries #

7 May 2015 7:01 AM

Thanks Ross, Jorg & Thomas for your reply..

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

6/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

Recep YUKSEL #

7 May 2015 8:02 AM

Thank you very much.

ManashM #

7 May 2015 10:04 AM

So from your post it look like all server role, except edge, will now resides in same box. So do we have any new features to come in 2016? Not
enhancement of existing feature rather a whole new one. So the ISO of exchange 2016 is there?

VinayMCITP #

7 May 2015 12:10 PM

Thank you for this Article.

AzureAmjad #

7 May 2015 2:53 PM

Ross,
Great Article and a good technical webcast. I like the part in the webcast when you stated that your DBs are moving to SQL, loads of the non technies
clapped and I went WT.... lol
But seriously, looking forward to test driving in Azure later this year, once available.
Some of this things that stood out and super cool:
* Database failovers times are reduced by 33% when compared to Exchange Server 2013!
* Reduced bandwidth requirements between the active copy and a passive copy by 40%
* The real cool aka smooth upgrade path from 2013
* No more MAPI/CDO, about time, so old school :
* Layer 7 / no session affinity
Although a die hard fan of Office 365 and Azure. This will be great news for all those onprep techs, still worried about the cloud or still trying to figure out
what is best for their particular setup.
Thanks Again !!

Sai Prasad Krishnan #

7 May 2015 4:08 PM

What about Public Folders ? If they are still modern PF's, I assume there will be an easier migration path from 2013 to 2016. This will open up a lot of
Onpremise Exchange 2013 PF's to migrate to Office 365's next version. This was my hope since we still don't have a way to migrate from Onpremise 2013 PF
to Wave 15 O365 tenant.

Jetze Mellema #

7 May 2015 5:26 PM

@ManashM With regards to architecture not that much has been changed. With 2010 and 2013 you would install all roles on a single server, per MS
recommendation. With 2016 Microsoft prevents customer from deploying splitroles server by installing all components from the MB+CA roles in a single
role, now named MB role. So the new MB roles actually contains all components from the 2013 MB and CA roles.

Jetze Mellema #

7 May 2015 5:32 PM

@Sai Prasad Krishnan: Microsoft shared at the Ignite Conference they are working on the migration scenario from Exchange 2013 to both 2016 and
Exchange Online.
Public Folder are still there in 2016, don't worry. :

jackal2001 #

7 May 2015 7:18 PM

Any word on upgrading/coexisting from Exchange 2010 SP3 to Exchange 2016?

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

7/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs

Jrg von der Ohe #

7 May 2015 7:33 PM

@jackal2001
should be possible, as far as i know, there is no path from 2007, but 2010 is ok

Brian Day [MSFT] #

8 May 2015 6:55 PM

You can coexist/upgrade from 2010 SP3 to 2016 in the same AD forest, but not from 2007. Setup will not allow you to install 2016 if 2007 exists in the
Exchange org. We will announce the required 2010 SP3 update rollup and 2013 CU for coexistence/migration closer to 2016's release.

Ross Smith IV #

8 May 2015 8:59 PM

Since many have asked why coexistence with Exchange 2010 was not mentioned in the article, it is because from an architectural standpoint, nothing there
has changed between Exchange 2013 and Exchange 2016 deploy enough MBX2016 to handle load, update load balancer configuration and have all
traffic routed to MBX 2016, enabling MBX2016 to proxy to CAS2010.
Brian does an excellent job of describing this in his session http://aka.ms/e2016deployignite.
Ross

island apple #

8 May 2015 9:07 PM

HI Team,
1 Thanks for the info so that we can preplan for Exchange 2016 deployment.
2 In regards to 'Setup will not allow you to install 2016 if 2007 exists in the Exchange org',
is there any possibility to request a feature to allow Exchange 2007 in the Exchange Org with 2016.
Our Org includes 2007,2010 and 2013
Thanks

Ross Smith IV #

8 May 2015 9:13 PM

@island apple For the past several releases we have only supported N2 major versions in coexistence. This continues with the Exchange 2016
coexistence model. There are many factors that come into play here, including, but not limited to, support lifecycle, testing resources, code changes, etc.
I recommend moving the 2007 resources to 2010 or to 2013.
Ross

island apple #

8 May 2015 11:58 PM

TY!
Is it too soon to ask about offering both certificate and password auth for Exchange 2016?
In my org we offer both we have a namespace for Password auth and different namespace for Cert based Auth

Ross Smith IV #

11 May 2015 1:59 PM

@island apple Take a look at http://channel9.msdn.com/events/Ignite/2015/BRK3136

Christian Schindler #

12 May 2015 6:11 PM

Ahhh! Good news! Never ever will I have to talk to customers why MutliRole Servers are the optimal solution. Never ever will I have to argue about why NLB
is poor mans Load Balancing. The future looks bright : Thanks Ross for this first round of info about E2016! Christian

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

8/9

10/12/2015

ExchangeServer2016ArchitectureExchangeTeamBlogSiteHomeTechNetBlogs
30 May 2015 3:38 AM

Gappuss #
Ross,

I was in MS Ignite 2015. Loved it. I do have one confusion. As you mentioned in your session that in an unbounded model outlook client hits Server A but the
mailbox is in Server B in another physical site. In this scenario, Server A proxies the Outlook client connection to Server B. My question is, once the
connection is established between Outlook Client and Server B does Server A hand over the connection completely to Server B or user continues to
traverses through Server A to reach its mailbox in Server B?
Can you please help me clarify my confusion?

2 Jun 2015 5:36 PM

Ross Smith IV #
@Gappuss it is proxied for the life of that session.
Ross

5 Jun 2015 8:20 PM

Random Anonymous Name #

Regarding Topology requirements, specifically the Active Directory servers.. There is no statement that RODCs / ROGCs are unsupported. Has this changed
from previous releases of Exchange Server?

10 Jun 2015 6:06 AM

Satyajit321 #

"RODCs / ROGCs are unsupported." I don't see any possibilities supporting them as Exchange does lots of Writes to the DC. Hence RODC wouldn't be
useful, until we have something like ReadOnly Exchange Servers.

13 Jun 2015 10:18 AM

JeevanIM #
Thanks

Exchange TechNet
Resources

Exchange TechCenter
Exchange Server 2010
Exchange Server 2007
TechNet Library
Forums

Other Microsoft Team Blogs

Quick Links

Support

Cool Community Links

Exchange Development
Blog

Buy Now

Exchange Server Forums

MSExchange.org

The NextHop Lync

Community

Exchange Online

Exchange Server 2010

Tony Redmond's Blog

Forefront Protection 2010

for Exchange Server

Exchange Server 2007

MSExchangeGuru's Blog

Forefront Online Protection

for Exchange

Exchange Server DevCenter

The Master Blog

Exchange Server Wiki

Ask Perry

The Microsoft Windows

Blog
The Microsoft Office Blog
Bing Community

2011 Microsoft Corp.

About

More...

Microsoft Office 365

Terms of Use

Trademarks

http://blogs.technet.com/b/exchange/archive/2015/05/05/exchangeserver2016architecture.aspx

Privacy Statement

Report Abuse

9/9