Now when a user logs on to the Exchange Server and open up EMS, the session will be proxied to the server where the user’s mailbox is located. If the aforementioned environment has all servers upgraded to Exchange 2013 CU11 and Exchange 2016 CU1 the behavior of Exchange Management Shell changes. Starting with Exchange Server 2013 CU11 and Exchange Server 2016 CU1, the Exchange Management Shell (EMS) session will also be using mailbox anchoring. For that I would have to logon directly to an Exchange 2016 Server. This means if I log into an Exchange 2013 Server I cannot manage any new cmdlets that became available in Exchange 2016. This is great for the client but what about the Exchange Management Shell (EMS)? In Exchange 2013 RTM through CU10 and Exchange 2016 (RTM), we do not use the mailbox anchoring logic to proxy the PowerShell session we just connect to the local server or proxy to another available server in the Exchange Organization. This process is utilized currently for most client protocols, such as OWA, ECP, and EWS with the exception of Remote PowerShell. If that server goes down and the database is a part of a DAG, the Client Access Proxy will proxy the session to the new active mailbox server for the corresponding database. Once CAS knows where the user's mailbox is located, the protocol request is then proxied to the appropriate mailbox server. As soon as we obtain the GUID, HTTP Proxy refers to Active Manager to locate the database containing the user's mailbox. In mailbox anchoring, CAS locates where the mailbox resides by querying Active Directory for the user's mailbox GUID. So in order to ensure that when a connection to the Exchange Management Shell (EMS) always goes to an Exchange 2016 server we have introduced mailbox anchoring into Exchange 2013 CU11 and Exchange 2016 CU1. This allowed us to have an Exchange 2013 server public facing and proxy traffic back to an Exchange 2016 server. Also with the release of Exchange 2016 we added an ability to proxy between Exchange 2013 and Exchange 2016. With Exchange 2013 and continuing on into Exchange 2016 we have removed the requirement for session affinity. In Exchange 2010 we used session affinity to provide a long-standing association between a particular client and a particular Client Access Server. Today we will dive deeper into these changes to help the Exchange Administrator understand how these changes will affect their Exchange Organization. This would lead customers to some broken administrative experiences based on the reliance of Exchange 2016 cmdlets and features. In previous versions, we have seen that customers who were reliant on a load balanced solutions for third party apps and scripts may get routed to a non-Exchange 2016 server. Update: behavior described in this blog post has changed in later Cumulative Update please see Remote PowerShell Proxying Behavior in Exchange 2013 CU12 and Exchange 2016.Ĭoming to the next CUs for Exchange 2013 and Exchange 2016 there are some changes to how the Exchange Management Shell (EMS) connects to Exchange.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |