Exchange web services manage the internal and external url address part 10#36

of 40 | Exchange Web services | Manage the Internal and external URL address |
Part 10#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Exchange Web services | Manage the
Internal and external URL address
|Part 10#36
The current article should provide us a small glimpse to the subject of managing
the internal and the external Exchange URL address of the different services.
We will review a couple of examples to the interfaces the available for us for
managing the variety of Exchange services – the graphical interface and the
PowerShell interface.
In the following articles, we will look “under the hood” of Exchange configurations
that relate to the configuration of the Exchange internal and external URL’s.

Part 10#36
Exchange web service versus Exchange-based services
Before we begin a small philosophical debate about the term – Exchange web
service.
The formal use of the term – Exchange web service relate to a specific Exchange
server interface named – EWS (Exchange web service).
This Exchange interface enables clients to address the Exchange server and ask for
specific web-based service such as – availability service, Automatic reply (out of
office), mail tips and more.
Besides of the EWS interface, Exchange server provides many other different
services.

Part 10#36
For example, the Exchange provides a “dedicated” interface for each of the different
mail clients such as:
 OWA – enable a web-based client to access their mailbox
 Outlook Anywhere – enable Outlook based client to access their mailbox
 ActiveSync – enable a mobile based clients to access their mailbox.
Additional examples for services that Exchange provides are:
 OAB – the offline address book that is used by Outlook client.
 ECP – Exchange control panel, the ability to manage an Exchange server or access
specific parts of Exchange management by using a web-based
The common denominator for all of these services is, that all of them are can be
described as a “web-based service.” services”. The communication protocol is –
HTTP or HTTPS, and the access for each of the different Exchange services are
implemented by using URL address.

Part 10#36
So the big question is – when we say Exchange web service, what we the exact
meaning?
My answer is that it doesn’t matter.
The Exchange architecture is based heavily on web-based services and, the exact
definition of Exchange web service versus Exchange web-based services doesn’t
matter.
What matter is:
1. Exchange dual identity in a scenario meaning internal hostname versus external
hostname, we need to know how these “identities” are assigned for each of the
Exchange web services.
2. Multiple public names
Many times, the Exchange will have a couple of public names. In again, it’s
important that we would know how these “identities” (different public names) are
assigned for each of the Exchange web services.

Part 10#36
Managing Exchange web services URL address.
As mentioned, each of the Exchange web-based services, is represented by URL
address. In the following article, we will review three Exchange management
interfaces that we use for managing the URL address:
1. Exchange 2010 graphical management interface
2. Exchange 2013 graphical management interface
3. Exchange PowerShell commands

Part 10#36
Q: Why should I use Exchange PowerShell interface instead of the Exchange graphic
interface?
A: In theory, we can assume that in case that we can manage the Exchange internal
and external URL’s address using a graphical interface, and there is no need for
using the un-friendly PowerShell interface.
In reality, many times we will have to use the PowerShell interface because some of
the configurations are not available via the Exchange server graphical interface.
Another aspect is that the Exchange 2010 graphical interface doesn’t include the
option to manage all the different Exchange web services.
One of the improvements in Exchange 2013 is the additional options for managing
Exchange web services that were not available in the Exchange 2010 management
interface.
THE EXCHANGE WEB SERVICES THAT WE WILL NEED TO KNOW ABOUT.
In the following section, we will review the part of “how to” manage Exchange
internal and external URL’s address, but it’s important to emphasize that the
preliminary stage, is the “planning phase”, in which we decide about the most
appropriate scenario that will match our specific organization needs.
For example
 Decide if we want to use the option of a unified namespace in which the
internal namespace and the external namespace will be identical.
 Decide what are the public “identities” (public host names) that we will assign
to the Public facing Exchange server.
Based on the characters of a specific scenario that is suitable for our organization,
we will have the required information that is needed for
 Purchasing a public certificate
 Create the required configuration in Exchange relating the Exchange web
services internal + external URL address

Part 10#36
Managing Exchange 2010 web services using the
Exchange graphic interface
The configuration of most of the Exchange 2010 web services is implemented by
accessing the section on – Server configuration and then the subsection of – Client
Access.
Notes
1. The management interface includes the option for managing POP3 and IMAP4
protocols. We will not relate to this part because this protocol is not considered
as an Exchange web service
2. The current interface doesn’t include the option for managing the Exchange
Outlook Anywhere service. The management of Outlook Anywhere is
implemented via the “server configuration” section.
1.Outlook Web App and Exchange Control panel tab

Part 10#36
This tab, enable us to set the URL address of the Exchange services for webmail
clients (OWA) and the Exchange ECP (Exchange control panel).
The first tab – Outlook Web App enables us to set the internal + external URL
address which will be used by the OWA mail client.
In the following screenshot, we can see the option in the General tab.
In our example, the internal URL for the OWA mail client is based internal hostname
of the Exchange server – ex01.0365info.local versus, the external or the public URL
address that uses the public name of the Exchange server – owa.o365info.com
The Exchange OWA service includes additional tabs that enable us to set the
authentication protocol and additional setting that relate to the OWA mail service.

Part 10#36
2. Exchange ActiveSync URL settings
When looking at the options that are available to us regarding the Exchange
ActiveSync URL settings, we can see that we can set the external and the internal
URL for the ActiveSync URL.

Part 10#36
At a first glance, it looks a little strange because ActiveSync client such as a mobile
device, can never access the – “internal ActiveSync URL” because, the ActiveSync
clients are accessing the Exchange CAS server only via public networks.
The answer is that the Internal URL of the ActiveSync, is only used for proxying
purposes in a scenario of Public facing Exchange CAS server who need to connect
additional or internal (not exposed) Exchange server.

Part 10#36
3. Outlook Anywhere host names settings.
In the following screenshot, we can see that way that we use the Exchange
graphical interface for configuring the Outlook Anywhere service.
Note that in Exchange 2010 server architecture, versus all the “other Exchange web
services”, the setting of the Outlook Anywhere service includes only the public host
name of the Exchange server.
Exchange 2013 server architecture include the option of configuring internal +
external server host name for Outlook Anywhere clients.

Part 10#36
Exchange web services that cannot be configured from the Exchange graphic
management interface.
As mentioned, the Exchange graphic management interface doesn’t include the
option of configuring all the available Exchange web services.
The following Exchange web services cannot be configured from the Exchange
graphic management interface
 Exchange EWS services
 Exchange Autodiscover web service
Managing Exchange 2013 web services using the
Exchange graphical web interface

Part 10#36
Exchange 2013 graphic interface (web based)
We will not get into a detailed comparison of the Exchange 2010 graphic interface
versus the Exchange 2013 graphic interface, but I would like to review some major
difference between those two Exchange interfaces.
The setting of the Exchange web services in Exchange 2013 is implemented by
accessing the server menu and at the top menu bar, the virtual directory menu.
The Exchange 2013 graphic interface includes the “additional web services” that
were missing from the Exchange 2010 interface.
The additional web services that appear in the Exchange 2013 management are:
 Exchange EWS
 Autodiscover
 PowerShell
1. Autodiscover web service settings
In case that we want to take a look at the configuration settings of the Autodiscover
web service, we can see that the Exchange 2013 graphical interface, doesn’t include
an option to configure the internal or the external URL of the Autodiscover service.
The only option is to configure the authentication protocols.

Part 10#36
Technically speaking, the scenario in which we will need to setupdate the value of
the Exchange web services that relate to Autodiscover are very rare.
2. Exchange EWS settings
An interesting refreshment is the ability in Exchange 2013 to configure the
Exchange EWS URL’s using the graphic interface. The option was omitted from the
Exchange 2010 interface, for some reason.

Part 10#36
Just a quick reminder of the purpose of the EWS – The EWS (Exchange Web Service)
is one of the Primary Exchange web services, that serve as a “gateway” for many
types of web services such as – Availability service (Free/Busy time), automatic reply
(Outlook of office), Mail tips and more.
Note – the EWS URL serves for additional service such as the MRSProxy for moving
mailbox and other Exchange services that are not directly related to the subject of –
”Autodiscover”
3. Exchange Outlook Anywhere management interface

Part 10#36
The Exchange 2013 interface for managing the Outlook Anywhere service is a bit
friendlier then the former interface of Exchange 2010.
The 2013 interface enables us to edit + view the name of the Exchange server that
will provide the Outlook Anywhere services and In addition enable to configure
internal + external host name
Managing the Exchange Autodiscover services URL
address in Active Directory based environment.

Part 10#36
The reason that I have decided to allocate a dedicated section for the subject of
managing the URL address of the Exchange Autodiscover service is because this
subject is very confusing and not so clear.
The Autodiscover client “journey” start with the first step in which the Autodiscover
client needs to locate an Exchange server who will provide him the required
Autodiscover services, address the Exchange server, submit a query and so on.
Now, let’s focus on the word – “locate”.
The method that internal Outlook client use for locating the required Autodiscover
Endpoint
(The Exchange server) is totally different from the method that is implemented by
external Outlook clients.
The internal Outlook client doesn’t know.
 Who are the available Exchange servers who can provide Autodiscover
Services?
 What is their host name?
 What is the required URL address for addressing the Exchange Autodiscover
service?
In an On-Premise Active Directory environment, the Autodiscover client doesn’t
know the name of “his” Exchange CAS server (the internal Exchange infrastructure,
could have one or many Exchange CAS servers).
To be able to get the “names” of the available Exchange CAS servers, the internal
Autodiscover client needs to address the local Active Directory and query the Active
Directory for the names of the available Exchange CAS server servers.

Part 10#36
For this reason, there is a mandatory pre-requirement for the successful
composition of the Exchange CAS server “registration process”
Note – by default the process of the Exchange CAS server “registration process” is
implemented automatically by each of the Exchange CAS servers.
Versus this character of the internal Outlook client, the opposite is true regarding
external Outlook clients:
External Outlook client “know in advance” the exact URL address of the Exchange
server that could provide him the required Autodiscover services.

Part 10#36
The external Autodiscover client doesn’t need a “source of information” such as –
the
On-Premise Active Directory that will provide him the name of existing
Autodiscover Endpoint but instead, the external Autodiscover client is searching for
a very specific host name.
In our example, because the E-mail address of the external mail client uses the
domain name –o365info.com , the Autodiscover client (such as Outlook) will query
the DNS server looking for the IP address of the host named
– autodiscover.o365info.com
When the external Autodiscover client addresses the Public facing Exchange CAS
server using the Autodiscover host name (autodiscover.o365info.com in our
example) the IIS component of Exchange CAS server “know” how to accept the
request for the FQDN autodiscover.o365info.com

Part 10#36
Registering the information about the Autodiscover Endpoint
Let’s make it even more complicated.
Autodiscover service and internal organization infrastructure
Regarding the internal organization infrastructure, in standard or simple scenarios,
we do not need to take any action for “registering” the Exchange server and inform
the internal client about “their Autodiscover Endpoint” because Exchange knows
how to register himself automatically in the Active Directory.
The automatic process in which Exchange server register himself in the Active
Directory is relevant only in a simple scenario. In more advanced scenarios we will
need to “cancel” the information that was registered by Exchange Automatically and
create a new and updated value.
Autodiscover service and external infrastructure
Regarding a scenario in which external Autodiscover client need to “consume”
Exchange Autodiscover services, the way that the Autodiscover clients use for
locating the Exchange server who will provide the required Autodiscover services is
totally different.
The Autodiscover client knows the host name + the URL address of the Exchange
server that could provide the Autodiscover information.
As Exchange administrators, we will need to
 Publish the Autodiscover host name in the public DNS infrastructure
 Add the Autodiscover host name to the public certificate
An interesting thing is that versus the “other” Exchange web service in which we
need to “play” with the internal and an external URL address, the authentication
type and other parameters, when dealing with the Exchange Autodiscover

Part 10#36
mechanism that should serve an external Exchange client the main concept is that
we don’t need to do anything!
The scenario in which we need to “play” with the Exchange Autodiscover setting
that impact external Autodiscover clients is very rare.
Managing Exchange Autodiscover settings
In case that we need to manage the Exchange Autodiscover settings, we need to
use the Exchange PowerShell interface.

Part 10#36
In the next section, we will demonstrate how to manage the “internal Autodiscover
registration” of Exchange in the Active Directory.
We will not demonstrate how to manage the “external Autodiscover registration” of
Exchange because of the simple reason that 99.9% we don’t need to “play” with the
Exchange Autodiscover setting of the Exchange web service.
Q: What are the scenarios, in which we wantneed to update the information that
was registered by the Exchange server in the Active Directory?

Part 10#36
A: The answer could relate to a couple of passable scenarios:
Scenario 1: Exchange 2010 CAS Array
In the scenario of Exchange CAS Array we will need to “remove” the default URL
address that was automatically registered with the Exchange CAS server and
instead, add a new URL address that will include the host name (the FQDN) that
represents the Exchange CAS Array name.
Scenario 2: Split DNS
The scenario of “Split DNS”, describe a configuration in which the internal and the
external Exchange CAS server URL’s address are identical.
In this scenario, we will also need to “remove” the default URL address that was
automatically registered with the Exchange CAS server and instead, add the URL
that includes the FQDN that is used for the internal and the external URL’s.

Part 10#36
By default, the Exchange CAS server will register his “NetBIOS” name as the host
name + the Active Directory domain name.
In case that we want to use a different host name who will represent the Exchange
CAS server, we will need to change the default Exchange host name (the default
“NetBIOS” name).
Scenario 3: “Cloud only” environment
In a specific scenario in which all of the mail infrastructure was migrated to the
cloud (Office 365 and Exchange Online) it’s passably to change the default URL that
was automatically created by the Exchange CAS server that “doesn’t exists
anymore” and instead, update the part of the FQDN in the URL address to point to
the Office 365 Autodiscover Endpoint –

Part 10#36
autodiscover.o365info.com
Additional reading
 Managing Exchange 2010 External/Internal URL’s via PowerShell
 Exchange 2007/2010 Autodiscover Virtual Directory URLs – Should I care?
 Busting The Set-AutodiscoverVirtualDirectory Myth
 Exchange & The Autodiscover Web Service
Exchange web services | The Exchange PowerShell
interface
In the following section, we will review the subject of the Exchange web services
internal and external URL by using the PowerShell.
As mentioned, we will need to use the PowerShell interface because in some
scenarios such as when using the Exchange 2010 graphical interface, there is no
available option for creating or updating the required URL settings.
There is an additional advantage for using PowerShell command because, many
times we can see additional information that doesn’t appear in the default
Exchange graphic interface

Part 10#36
Managing Exchange Autodiscover information registered in the
Active Directory SCP using PowerShell
Exchange Autodiscover service and On-Premise Active Directory SCP
The management tasks, which relate to the information that is registered with the
Exchange CAS server in the SCP of the Active Directory are:
1. View the details that were registered with the Exchange CAS server in the Active
Directory SCP. To be able to view the information in the Active Directory service
connection point (SCP), we use the command – Get-ClientAccessServer
2. Managing (updating) the details that were registered with the Exchange CAS
server in the Active Directory SCP. To be able to update the information in the
Active Directory service connection point (SCP), we use the command – Set-
ClientAccessServer
Q: What is the “information” that is registered with the Exchange CAS server in the
Active Directory service connection point (SCP)?
A: The details of the Exchange CAS server who are registered in the Active Directory
service connection point (SCP) are:
1. Internal FQDN of the Exchange On-Premise server
2. The Autodiscover URL (the more accurate term is URI)
3. The Autodiscover Site scope (the On-Premise Active Directory site in which
the Exchange server is located).
The “magical” PowerShell command that will help us to manage the information
registered in the Active Directory service connection point (SCP) is – Set-
ClientAccessServer

Part 10#36
1. Display information that is registered in the Active Directory service
connection point (SCP)
To be able to see this information (the information that is registered with the
Exchange server for internal clients), we can use the following PowerShell
command:
Get-ClientAccessServer –Identity <Server> | FL Autodiscover*
Example 1: view information about the name who was registered at the Active
Directory SCP by Exchange server named – ex01
In the following screenshot, we can see that the Exchange server is registered at the
SCP by using the URL address:
https://ex01.0365info.local/Autodiscver/Autodiscver.xml
In addition, we can see that the Exchange server appear is a member in the
{Default-First-Site-Name}

Part 10#36
The value which represents the information that Exchange server register in the
Active Directory is – AutoDiscoverServiceInternalUri
Example 2: optimize the output from the PowerShell command
In case that we want to optimize the output from the PowerShell command, so we
can clearly see the information that realized to the URL address that was registered
+ the information about
Get-ClientAccessServer –Identity <Server> | Select name,
AutodiscoverServiceInternalURI, AutodiscoverSiteScope | FT –AutoSize
In the following screenshot, we can see the details on Exchange server named –
ex01.o365local.com
Under the section of – AutodiscoverServiceInternalURI, we can see the Autodiscover
URL address Active Directory service connection point (SCP).
We can see that the Exchange server FQDN is based on the “private” (NetBIOS)
Exchange name + On-Premise Active Directory domain name.
Additionally, we can see information about the On-Premise Active Directory site in
which the Exchange server is installed. In our scenario, we can see that the
Exchange server is installed on an On-Premise Active Directory site named
– {Default-First-Site-Name}.

Part 10#36
2. Update the Exchange CAS server Autodiscover information
In some scenarios, we need to change or update the Autodiscover Exchange CAS
server default values that was automatically registered at the Active Directory
service connection point (SCP)
Example 1: Exchange CAS Array
In case that we want to add the name of the CAS array to the Active Directory
service connection point (SCP) we can use the following PowerShell command
syntax:
Set-ClientAccessServer -Identity “<Exchange server>” -
AutodiscoverServiceInternalURI “<CAS Autodiscover URL address>”
For example, in our scenario the Exchange CAS server CAS array name is
– cas.o365info.local
Set-ClientAccessServer -Identity “<Exchange server>” -
AutodiscoverServiceInternalURI “<CAS Autodiscover URL address>”
Example 2: add additional Active Directory site to the Exchange CAS server
In a scenario of multiple Exchange sites, the best practice is to “assign” the site
value of the information that appear in the Active Directory SCP.
For example, we want to implement a configuration in which a specific Exchange
CAS server named – exo1, will “register” himself as an available Exchange CAS
server for two different Active directory sites at the same time.
In our example, we want to “attach” the Exchange CAS server to the following Active
Directory sites: USA-NY and USA-LA

Part 10#36
The PowerShell command that we use will be:
Set-ClientAccessServer -Identity “ex01″ -AutodiscoverSiteScope “USA-
NY”,”USA-LA”
Get information about the Exchange Autodiscover web service
using PowerShell
As we have mentioned before, most of the time there is no need for configuring or
managing the Autodiscover internal and external URL address of the Exchange CAS
server.
But I’m sure that some of you are a little bit curious and, want to verify is this is just
a fairy tale or a real statement.
To be able to satisfy your hunger get some more information about the
Autodiscover internal and the external URL address of the Exchange CAS server.
The PowerShell commands that we use for getting information and managing the
Autodiscover service -internal and external URL address are:
Get-AutodiscovervirtualDirectory
Set-AutodiscovervirtualDirectory

Part 10#36
Display information about Exchange Autodiscover virtual folder
Example 1: view the Autodiscover web service settings of Autodiscover a specific
Exchange CAS server
To be able to view the Autodiscover web service settings of Autodiscover a specific
Exchange CAS server, we will use the following PowerShell command:
Get-AutodiscovervirtualDirectory “ex01*” | FL
In the following screenshot, we can see a couple of details about the Exchange CAS
server Autodiscover virtual folder.
You can see the value of the InternalUrl and, the ExternalUrl are empty!
Additional available information relates to the authentication method that will be
used such as: Basic, NTLM, Windows Integrated and WSSecurity.

Part 10#36
Example 2: refine the results of the PowerShell
In case that we want to refine the results of the PowerShell command we can filter
the output by using the PowerShell command:
Get-AutodiscovervirtualDirectory “ex01*” | Select name, Server, InternalUrl,
ExternalUrl
Example 3: get information about the Autodiscover settings of all of the existing
Exchange CAS servers
In case that you want to get information about the Autodiscover settings of all of
the existing Exchange CAS servers you can use the PowerShell command:
Get-AutodiscovervirtualDirectory | Select name, Server, InternalUrl,
ExternalUrl
In the following screenshot, we can see information about the Autodiscover
settings of all of the existing Exchange CAS servers

Part 10#36
Setting the authentication settings of the Exchange CAS server
Autodiscover service
The authentication settings for the Autodiscover web services are supposed to
configure automatically to support the requirement for authentication + support
the required authentication protocol.
In some troubleshooting scenario, in case that there is a problem or a miss
configuration of the Autodiscover web services, we can “fix” the issue by using a
PowerShell command.
In the following PowerShell we will configure the Autodiscover web services to
support the WSSecurity authentication protocol:
Set-AutodiscoverVirtualDirectory –identity ” CASServerNameAutodiscover
(Default Web Site)” –WSSecurityAuthentication $true
Managing the Exchange web services (EWS) using
PowerShell
As mentioned, the option for configuring the internal and the external URL address
of Exchange web services (EWS) is not available when using the Exchange 2010
graphic interface only when using the Exchange 2013 web management interface.

Part 10#36
Just a quick reminder – the Exchange web services (EWS) are an essential
component for many of the well-known Exchange web servers such as the available
service (FreeBusy time), Auto replay (Out of office), mail tips and much more.
In a scenario of Public facing Exchange CAS server, it’s important to check and verify
that the Exchange web services (EWS) external URL is updated and include the
“right settings” that will enable external mail client to access the required Exchange
EWS services.
Display information about Exchange web services (EWS)
The first step is to display information about the “values” of the Exchange web
services (EWS) internal and external URL’s.
Example 1: display information about a specific Exchange CAS server EWS setting
To be able to view the EWS settings of an Exchange CAS server named: exo1, we will
use the following PowerShell command:
Get-WebServicesVirtualDirectory “ex01*” | FL *url*
In the following screenshot, we can see an example for the Outlook that we get
from Exchange server that was configured as Public facing Exchange server.
We can see that
 The value in the InternalURL includes the “private host name” of the Exchange
server –o365info.local
 The value in the ExternalURL includes the “public host name” of the Exchange
server – o365info.com

Part 10#36
Example 2: display information about the EWS settings of all of the existing
Exchange CAS servers
To be able to view the EWS settings of all of the existing Exchange CAS servers, we
will use the following PowerShell command:
Get-WebServicesVirtualDirectory | FL *url*
In the following screenshot, we can see information about the Exchange web
service URL address of all the Exchange servers in the organization.
Example 3: display information about a specific Exchange CAS server EWS setting +
is refined the output results
Get-WebServicesVirtualDirectory “ex01*” | Select InternalUrl,ExternalUrl

Part 10#36
In the following screenshot, we can see information about the Exchange web
service authentication settings.
Setupdate the URL address of the Exchange web services (EWS)
Example 1: Set the “public” (external) URL address of the Exchange web services
(EWS)
In the following example, the FQDN of the Public facing Exchange CAS server is –
mail.o365info.com

Part 10#36
PowerShell command:
Set-WebServicesVirtualDirectory -Identity “CAS01EWS (Default Web Site)” –
ExternalUrl https://mail.o365info.com/ews/exchange.asmx
Example 2: Set the internal URL address of the Exchange web services (EWS)
In the following example, the FQDN of the Exchange CAS server is
– ex01.o365info.local
PowerShell command:
Set-WebServicesVirtualDirectory -Identity “CAS01EWS (Default Web Site)” -
InternalUrl https://ex01.o365info.local/ews/exchange.asmx
Managing the “reset” of Exchange web services using PowerShell
In the following section, we will provide some general examples to common
scenario in which we need to manage the URL address host name for different
Exchange web services
Exchange OAB (offline address book)
Set-OABVirtualDirectory -identity ” ex01OAB (Default Web Site)”
-InternalUrl “https://ex01.o365info.local/oab”
-ExternalUrl “https://mail.o365info.com/oab “
ActiveSync Exchange web service
Example 1: Display information about the Exchange ActiveSync | internal and
external URL
PowerShell command:
Get-ActiveSyncVirtualDirectory -Server “ex01″ | FL
Example 2: set the Exchange ActiveSync internal and external URL

Part 10#36
Set-ActiveSyncVirtualDirectory -Identity “EX01Microsoft-Server-ActiveSync”
-InternalUrl “https://ex01.o365info.local/Microsoft-Server-ActiveSync”
-ExternalUrl “https://mail.o365info.com/Microsoft-Server-ActiveSync”
OWA Exchange web service
Display information about OWA Exchange web service
Example 1: display all of the available information about the OWA Exchange web
service on a specific Exchange CAS server.
PowerShell command:
Get-OWAVirtualDirectory -identity “EX01owa (default web site)”
Example 2: display information about the internal and external URL address of the
OWA Exchange web service on a specific Exchange CAS server.
Get-OWAVirtualDirectory -identity “EX01owa (default web site)” | Select
InternalUrl,ExternalUrl
Example 3: display all of the available information about the OWA Exchange web
service of all of the existing Exchange CAS servers.
Get-OwaVirtualDirectory | Select identity,InternalUrl,ExternalUrl
Set internal and external URL address for the OWA Exchange web service
Example 1: Set internal and external URL address for the OWA Exchange web
service on a specific Exchange CAS server
Set-OwaVirtualDirectory -Identity “ex01owa (default Web site)”
-InternalUrl “https://ex01.o365info.local/owa”
-ExternalUrl “https://mail.o365info.com/owa”
Display information about ECP Exchange web service
Example 1: display all of the available information about the ECP Exchange web
service on a specific Exchange CAS server.
PowerShell command:

Part 10#36
Get-EcpVirtualDirectory -server “EX01”
Example 2: display information about the internal and external URL address of the
ECP Exchange web service on a specific Exchange CAS server.
Get-EcpVirtualDirectory -server “EX01” | Select
identity,InternalUrl,ExternalUrl
Example 3: display all of the available information about the ECP Exchange web
service of all of the existing Exchange CAS servers.
Get-EcpVirtualDirectory | Select identity,InternalUrl,ExternalUrl | FL
Set internal and external URL address for the ECP Exchange web service
Example 1: Set internal and external URL address for the OWA Exchange web
service on a specific Exchange CAS server
Set-EcpVirtualDirectory -Identity “ex01ECP (Default Web Site)”
-InternalUrl “https://ex01.o365info.local/ecp”
-ExternalUrl “https://mail.o365info.com/ecp”
Outlook Anywhere Exchange web service
Example 1: display all of the available information about the Outlook Anywhere
Exchange web service on a specific Exchange CAS server.
PowerShell command:
Get-OutlookAnywhere -Identity “ex01*”
Example 2: display information about the External Host name URL address of the
Outlook Anywhere Exchange web service of a specific Exchange CAS server.
Get-OutlookAnywhere -Identity “ex01*”
Example 3: display all of the available information about the Outlook Anywhere
Exchange web service of all of the existing Exchange CAS servers.
Get-OutlookAnywhere | Select identity,ExternalHostname |FL

Part 10#36
Summery table
In case that you got a little bit confused from all of the different Exchange web
services management options, you can use the following table

Exchange web services manage the internal and external url address part 10#36

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (17)

Plus de Eyal Doron

Plus de Eyal Doron (20)

Dernier

Dernier (20)

Exchange web services manage the internal and external url address part 10#36