Connecting email clients to Microsoft Exchange Server. Microsoft's approach to setting up OWA
www.microsoft.com
Exchange 2013 internal and external URLs are needed to access certain services from different locations - from a local network or the Internet. By default, when installing a server, only internal URLs are specified and they link to the server fqdn, and external URLs are completely absent. .
This article is the fifth in a series that covers the required tasks for configuring Exchange 2013 immediately after installation. If you are interested in other tasks, I recommend turning to the main article on configuration - or the main article on the subject -.
Let's move on to the main goal of this article - changing internal and external URLs.
Settings
To do this, go to the directory EAC - Servers\Servers- select with the mouse required server(for me this is exch02)\ Change(pencil icon) - Mobile Outlook.
In the field Provide an external host name (for example, contoso.com) to connect users to your organization. We register the external address we need. For me it will be mail.bissquit.com. It would also be a good idea to change the name of the internal node to something similar. It's up to you to decide whether the external and internal names or different, but making them identical seems more than logical.
If you have not changed the authentication type, a warning will appear:
I don't have earlier versions of Exchange, so I ignore the warning.
You can do this through Powershell using the cmdlet Set-OutlookAnywhere:
PowerShell
Let's check the result:
Next, let's change the settings of the virtual directories by adding an external URL to them (it is missing by default) and setting a similar address for internal connections. Through the EAC web interface you can perform the corresponding actions in the catalog Servers\Virtual Directories- select the desired directory with the mouse, click Change(pencil icon), set the required internal and external URLs.
Repeat the steps for each virtual directory except Autodiscover (Default Web Site). Example of changing virtual directory properties ecp (Default Web Site):
There will be quite a few commands to change settings via PowerShell, since there is a separate set of cmdlets for each type of virtual directory:
To change the control panel virtual directory - Set-EcpVirtualDirectory.
To change the Exchange Web Services virtual directory - Set-WebServicesVirtualDirectory.
To change the Microsoft Exchange ActiveSync services virtual directory - Set-ActiveSyncVirtualDirectory.
To change the OAB virtual directory − Set-OabVirtualDirectory.
To change virtual Outlook - Set-OwaVirtualDirectory.
To change the PowerShell virtual directory − Set-PowerShellVirtualDirectory.
So, closer to the point:
PowerShell
Set-EcpVirtualDirectory "exch02\ecp (Default Web Site)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS (Default Web Site) )" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB (Default Web Site)" -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA (Default Web Site)" -InternalUrl https://mail.bissquit.com /owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail.bissquit .com/PowerShell
Set -EcpVirtualDirectory "exch02\ecp (Default Web Site)"-InternalUrl https://mail. bisquit. com/ecp -ExternalUrl https://mail. bisquit. com/ecp Set -WebServicesVirtualDirectory "exch02\EWS (Default Web Site)"-InternalUrl https://mail. bisquit. com/EWS/Exchange. asmx -ExternalUrl https: / / mail . bisquit. com/EWS/Exchange. asmx Set -ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)"-InternalUrl https://mail. bisquit. com/Microsoft-Server -ActiveSync -ExternalUrl https: //mail. bisquit. com/Microsoft-Server-ActiveSync Set -OabVirtualDirectory "exch02\OAB (Default Web Site)"-InternalUrl https://mail. bisquit. com/OAB -ExternalUrl https: //mail. bisquit. com/OAB Set -OwaVirtualDirectory "exch02\OWA (Default Web Site)"-InternalUrl https://mail. bisquit. com/owa -ExternalUrl https://mail. bisquit. com/owa Set -PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)"-InternalUrl https://mail. bisquit. com/PowerShell -ExternalUrl https://mail. bisquit. com/PowerShell |
Let's move on to the next chapter.
Local DNS server settings
Since we have specified the same internal and external URLs for Exchange 2013 services, we need to figure out how to properly configure the local DNS server records (looking ahead, I will say that this is called Split DNS).
Note: the fact is that the domain mail.bissquit.com will be resolved to the external address of the gateway and thus sent outside and, when it reaches the gateway, turned back to local network. There is nothing terrible about this, but it is clearly an extra route that will take all traffic heading to your Exchange 2013 from the local network.
On the domain controller, you need to go to the “DNS” snap-in and create a new forward lookup zone:
We leave all the settings as default, just specify the required name, for me it is bissquit.com. After creating a zone, you need to add one CNAME record. We need mail.bissquit.com to resolve to the internal address of the Exchange 2013 server:
Note: Please note that adding a second-level domain to your service may be an extremely bad idea if this domain (or its subdomains) is tied to some external resources. In this case, your local DNS server will consider itself responsible for this entire zone and return a response that, for example, the site domain does not exist.
The record has been created, let’s check how it works:
The name mail.bissquit.com resolves to an internal address, everything is fine, as we need. However, when we try to “ping” another subdomain, for which we did not create entries in the new zone, we cannot resolve the name. This happens because our DNS server considers itself responsible (authoritative) for the entire bisquit domain. You can send DNS queries for a site record externally using delegation:
Specify the required domain in the name:
Next, register one (or better yet, several) of the NS servers of your provider, whose DNS records you administer. If you don't know any NS servers, run nslookup in command line, set the record type (set type=ns), enter the required domain name(mine is bissquit.com):
Let's check it again:
As you can see, everything works. Thanks to the article on Alexey's blog. A small drawback of this method is that you need to manually register all external subdomains. True, I don’t have many of them yet, just one.
So, this completes the DNS setup. In general, DNS server administration is only indirectly related to configuring internal and external URLs, but this is an important point to consider because the documentation on Technet when performing URL configuration only gives general information about what DNS records need to be created, but how to do this and what nuances there are are not explained:
After you configure the internal URL in the Client Access server virtual directories, you must configure private DNS records for Outlook Web App and other connectivity options. Depending on your configuration, you will need to configure private DNS records to point to the internal or external IP address or FQDN of the Client Access server. Below are examples of recommended DNS records that you need to create to connect internal clients.
FQDN DNS record type Meaning Mail.contoso.com CNAME Ex2013CAS.corp.contoso.com www.contoso.com CNAME Ex2013CAS.corp.contoso.com
The first Exchange role that needs to be switched to the new servers is Client Access. The reason is that CAS 2007 is the connection point for clients (except for MAPI RPC) and if user mailboxes are moved to new servers, clients will lose access to OWA, Anywhere, ActiveSync, POP, IMAP. In an organization running Exchange 2010, the Client Access server can proxy and redirect user requests to other Exchange CAS 2010/2007 and Exchange 2003 servers. When users connect to CAS, if the mailbox is on Exchange Mailbox 2010, the user gains access if the mailbox is on Exchange Mailbox 2007, CAS 2010 redirects or proxies the connection to other CAS servers.
Proxying
In the case of proxying, the client accesses the CAS 2007 server by connecting to CAS 2010. CAS 2010 is a proxy server.
Proxying is supported by the following clients:
- Outlook Web App
- Exchange ActiveSync(EAS)
- Exchange Control Panel (ECP)
- POP3, IMAP4
- Exchange Web Services
Redirection
In the case of redirection, the client receives a response from the server with an error in accessing the resource and a new URL for re-access. The client re-attempts to access the URL specified in the response from the server. Redirection is supported both between CAS servers in the same site and between sites.
Redirection is supported by the following clients:
During migration, how does the client determine which server the user's mailbox is located on?
When a client requests access to a CAS server, Exchange queries the Directory Services to determine the following parameters:
- HomeDB(mailbox location)
- msExchangeVersion (Exchange version where the mailbox is located)
- MSExchServerSite (my guess is that it is for this attribute that Microsoft Exchange Active Directory Topology determines whether Exchange belongs to sites)
- Authentication Token
- InternalUrl and ExternalUrl (if exist)
This example only covers Exchange 2007 and Exchange 2010 in the same AD site.
If the mailbox is located on Mail01-srv and the ExternalUrl value exists, the request will be redirected to CAS 2007.
If the mailbox is located on Mail01-srv and the ExternalUrl and InternalUrl values exist, several options are possible:
1. Clients do not support autodiscovery
If the client does not support the Autodiscover feature, the CAS 2010 server proxies connections to the CAS 2007 server(Internal URL)\Microsoft-Server-ActiveSync\Proxy
2. Clients support auto-detection
If the client supports Autodiscover and the ExtrenalUrl value exists, the CAS 2010 server responds to the client (HTTP error code 451) with a message where the new connection name is located, pointing to CAS 2007.
POST /Microsoft-Server-ActiveSync/default.eas User=user&DeviceId=foo&DeviceType=PocketPC&Cmd=Settings&Log=
RdirTo:https%3a%2f%2flegacy.mailmig.com%2fMicrosoft-Server-ActiveSync_Error:MisconfiguredDevice_ 443 mailmig\user xxx.xxx.xxx,xxx MSFT-PPC/5.2.5082 451 0 0 17
In case the client supports Autodiscover and the ExtrenalUrl value does not exist ($null) happens proxying.
There is the following nuance with the Autodiscover function - some devices support Autodiscover, but cannot correctly handle 451 errors and update the ActiveSync profile. If there are not many such devices, you can advise users to manually change the URL to the server to CAS 2007 (legacy.mailmig.com)
The infrastructure in question had approximately 600-700 devices from different manufacturers, and I decided to use only proxying to avoid this situation.
Exchange 2007 does not have such a virtual directory, so this question was not relevant in my case.
P.S When configuring ECP, you need to pay attention to the fact that the authentication types for ECP and OWA are the same.
The autodiscover service provides Exchange Web Services clients with a URL. For clients with mailboxes on Mailbox 2007, a link to EWS CAS 2007 will be returned; for clients with mailboxes on Mailbox 2010, a link to EWS CAS 2010 will be returned.
Proxying occurs only if the mailbox is located on Mailbox 2010 in another Active Directory site. For example, if a user connects to CAS-1 in Site-1 and his mailbox is located on mail server hosted in Site-2, the CAS-1 server will proxy the connection to the CAS-2 server in Site-2 in accordance with the EWS InternalUrl settings on CAS-2. Proxying occurs regardless of whether the ExternalUrl value exists or not.
POP/IMAP
If the user's mailbox is on Exchange 2007, the CAS 2010 server proxies connections to CAS 2007.
OutlookAnywhere
CAS 2010 always proxies connections to the Exchange 2007 Mailbox role. Outlook Anywhere on Exchange 2007 must be disabled.
As a result, after switching to the new CAS servers, all user connections (except for MAPI Exchange 2007) were switched to CAS 2010. The connection diagram is shown in the figure below.
Setting up Exchange CAS 2010
- NLB cluster
The process of creating a cluster is described in the article Creating Network Load Balancing Clusters
Propertiescluster(Cluster Properties)
Full Internet Name: Outlook.mailmig.com
Cluster Operation Mode: Multicast
Rulesports (Port Rules)
| IPaddress cluster |
Elementaryport | Finiteport | Type | Affinity | Description |
| IP10 | 80 | 80 | Tcp | single | Switching clients from port 80 to port 443 |
| IP10 | 110 | 110 | Tcp | Single | POP3 |
| IP10 | 995 | 995 | Tcp | Single | POP3 SSL |
| IP10 | 135 | 135 | Tcp | Single | MAPI RPC |
| IP10 | 143 | 143 | Tcp | Single | IMAP |
| IP10 | 993 | 993 | Tcp | Single | IMAP SSL |
| IP10 | 443 | 443 | Tcp | single | HTTPS OWA |
| IP10 | 1024 | 65535 | Tcp | Single | MAPI RPC |
Single Affinity— traffic from the client is transmitted only to one cluster node. (Exchange 2013 supports a mode where traffic from one client can be directed to different cluster nodes)
Example of configuration on a CISCO switch:
arp IP10 MAC#1 ARPA
mac address-table static MAC#1 vlan 3 interface Po1 Po2
- Certificates
Certificate for external publications
Only one IP has been added to the ISA server and various services have already been published on port 443, so in my case the entire certificate will have to be replaced with Listener. The new certificate must contain the following names:
- Mail.mailmig.com
- Legacy.mailmig.com
- Autodiscover.mailmig.com
- Names of other published services
Certificates for CAS 2010
In this example, one certificate is created for two CAS nodes. The created certificate is exported with the private key to the second CAS server.
$data = New-ExchangeCertificate –GenerateRequest –SubjectName “C=com, O=MAILMIG Organization, CN=mail.mailmig.com” –DomainName mail.mailmig.com, srv-mx03.mailmig.com, srv-mx04.mailmig. com, pop.mailmig.ru, autodiscover.mailmig.com –FriendlyName “CAS Certificate” –KeySize 1024 –PrivateKeyExportable:$true
Set-Content -path "c:\CAS_SAN_cert.req" -Value $Data
Certreq -submit -attrib "CertificateTemplate:Webserver" -config "srv-dc01\MailmigCA" CAS_SAN_cert.req CAS_SAN_cert.cer
Certreq –accept C:\CAS_SAN_cert.cer
Enable-ExchangeCertificate –thumbprint(certificate stamp) –services IIS, POP, SMTP
Certificates for CAS 2007
If the certificate contains the FQDN name of the CAS 2007 server, there is no need to change the certificate.
CreationarrayCAS
New-ClientAccessArray -Fqdn "outlook.mailmig.com" -Site "Default-First-Site-Name"
DNS Settings
Creating new entries:
- Outlook.mailmig.com - IP10, internal DNS zone
- autodiscover.mailmig.com - IP10, internal DNS zone
- legacy.mailmig.com - IP1, internal DNS zone
- legacy.mailmig.com - IP3, external DNS zone
Changes to current
- mail.mailmig.com - IP10, internal DNS zone
In this case, all publications are configured on one IP3, but if new rules are published on new IPs, you will need to change the mail and autodiscover records in the external mailmig.com zone.
Setting up Outlook Anywhere
Enable-OutlookAnywhere -Server:srv-MX03.mailmig.com -ExternalHostName:mail.mailmig.com -SSLOffloading $false –Defaultauthenticationmethod basic
Enable-OutlookAnywhere -Server:srv-MX04.mailmig.com -ExternalHostName:mail.mailmig.com -SSLOffloading $false –Defaultauthenticationmethod basic
SettingsURL toCAS 2010srv-mx03.mailmig.com
The same settings will need to be made on srv-mx04.mailmig.com. In fact, the ExternalUrl parameter does not need to be specified in these cmdlets, since it was added during the CAS 2010 installation phase( ExternalCASServerDomain) and the ExtrenalUrl values are already configured.
https://mail.mailmig.com/OAB - InternalURL https://mail.mailmig.com/OAB
https://mail.mailmig.com/EWS/Exchange.asmx -InternalURL https://mail.mailmig.com/EWS/Exchange.asmx -BasicAuthentication $True –WindowsAuthentication $True
https://mail.mailmig.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.mailmig.com/Microsoft-Server-ActiveSync
https://mail.mailmig.com/OWA -InternalUrl https://mail.mailmig.com/OWA
Set-ECPVirtualDirectory srv-MX03\ECP* -ExternalUrl https://mail.mailmig.com/ecp -InternalUrl https://mail.mailmig.com/ecp -WindowsAuthentication $True –FormsAuthentication $False
URL settings on CAS 2007
Set-OABVirtualDirectory srv-MX03\OAB* -ExternalURL https://legacy.mailmig.com/OAB — -InternalURL https://mail01-srv.mailmig.com/OAB -BasicAuthentication $True –WindowsAuthentication $True
Set-WebServicesVirtualDirectory srv-MX03\EWS* -ExternalURL https://legacy.mailmig.com/EWS/Exchange.asmx -InternalURL https://mail01-srv.mailmig.com/EWS/Exchange.asmx -BasicAuthentication $True – WindowsAuthentication $True
Set-ActiveSyncVirtualDirectory –ExternalUrl https://legacy.mailmig.com/Microsoft-Server-ActiveSync -InternalUrl https://mail01-srv.mailmig.com/Microsoft-Server-ActiveSync -Identity srv-MX03\Microsoft-Server-ActiveSync * -BasicAuth $True –WindowsAuth $True
Set-OWAVirtualDirectory srv-MX03\OWA* -ExternalUrl https://legacy.mailmig.com/OWA -InternalUrl https://mail01-srv.mailmig.com/OWA -WindowsAuthentication $True –FormsAuthentication $False
After all the settings have been made on the Exchange servers, all that remains is to change the rules to ISA Proxy01-srv
The rules are described “as is”; perhaps they could be optimized, for example, removing unnecessary paths in the CAS 2010 OutlookAnywhere rule.
The sequence of rules is as follows:
- Exch2010OutlookAnywhere
- Exch2007OWA
- Exch2010ActiveSync
- Exch2010OWA
Listener used in all publishing rules of mail systems.
Rule for OWA CAS 2007
Rule for OWA CAS 2010
OutlookAnywhere rule
Rule for EAS
When switching to new CAS servers, I had one nuance - it is related to the fact that SSO when redirecting from CAS 2010 to CAS 2007 only works if FBA is authorized. Since ISA has only one IP on the “external” adapter and a listener has already been made for it with FBA authorization and NTLM authorization delegation, internal OWA users will have to re-enter their login and password when redirected to legacy. In this case, you can do the following:
Specify mail.mailmig.com in the internal DNS zone to the “internal” adapter of the ISA server (IP2), and in the OWA rule specify to accept connections from the network object where the users are located (in my case it is Internal). After the settings were changed, two problems arose, the first was due to the fact that the technical service. Users began to contact support with the problem that they did not have access to the Internet, the second problem arose among Outlook users, when starting Outlook, after a short time a login sign appeared, while messages were sent and received. The first problem was due to the fact that the wpad service was configured on port 80 and the same port was enabled on the lister. The second problem was that in CAS 2007 the default setting for Autodiscover was changed, which instead of the server's FQDN pointed to mail.mailmig.com in this case the connection went through ISA using FBA rather than Integrated Windows. Therefore, it is better to carry out this kind of settings on dedicated IPs, and it is also necessary to think through all the little details, based on this, the customer and I decided that since migration mailboxes on new server will not last long, those few OWA users who connect from internal networks will enter their login and password several times.
Greetings to all readers of our Blog! Today I will tell you how to set up in a few minutes publication mail server Exchange Server 2013/2016 by using IIS ARR (Application Request Routing). But first, a little about what publication is and why it is needed.The main task of publication is to protect the server from external negative influences. Publishing server Reverse Proxy (RP), is located in the perimeter network ( DMZ) and transmits (proxy) requests to mail servers if the requests match certain patterns. Component-based RP logic ARR next: if a request arrives with the host name mail.contoso.com over the protocol HTTPS, then redirect the request to the mail.contoso.com server farm. Everything is simple and clear. The web server is used for the simple reason that in Exchange 2013/2016 ALL connections (except POP And IMAP of course!) go through HTTPS and it doesn’t matter what you use, browser or thick client Outlook.
Some features R.P. servers based IIS ARR:
- Server R.P. may not be a domain member.
- The server must have access to the organization's internal network (specifically, mail servers) and the external Internet. One of the implementation options is two network adapters.
- RP must allow FQDN(full domain name ex1-srv.contoso.com, ex2-srv.contoso.com, etc.) of the mail server to its IP address. If the perimeter network does not use a DNS server, you must enter the server names and IP in the file C:\Windows\System32\Drivers\etc\hosts.
- Make sure you have configured it correctly internal And external URLs for virtual directories on the mail server and configured the servers correctly. Before you start publishing, check that everything is functioning perfectly within the local network.
- DNS suffix servers R.P.(if it is not included in the domain) you needconfigure manually
so that it is identical to the domain one (RP. contoso.com
).
- Make sure the virtual directories ( OWA, ECP, EWS etc.) published for external connections with namespace mail.contoso.com
Let's start the installation.
1 ) Run PowerShell with privileges Administrator and execute
Import-Module ServerManagerAdd-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web- Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-Win-CFAC,NET-Non-HTTP-Activ,NET-HTTP-Activation,RSAT-Web-ServerLet's check that everything worked out by entering in the server browser R.P.
http://127.0.0.12 ) InstallMicrosoft Web Platform Installer . In the search for Microsoft Web Platform Installer we type ARR and install the package Application Request Routing 3.0+ additional components suggested by the installer.
4 ) Go to Server Farms and create a new server farm. Let's call herContoso.com
Let's add servers to the farm (If the roles are separated, then add only the CAS servers). Enter FQDN server and click ADD
Click Finish, then YES to the proposal to create rules.
5) It is necessary to configure the farm to which we added our mail servers.Opening a farm contoso.com and go to the section Caching. Removing the checkbox Enable Disk Cache and press Apply
Go to the section Health Test. As a URL to check the availability of servers, I will specify:
- https://autodiscover.contoso.com/Autodiscover/HealthCheck.htm
The URL for checking accessibility is: https://
- https://mail.contoso.com/EWS/HealthCheck.htm
- https://mail.contoso.com/OAB/HealthCheck.htm
- https://mail.contoso.com/OWA/HealthCheck.htm
Settings for the section Health Test(after making changes, do not forget to click Apply)
After making all the settings, you need to check that everything works. Let's click Verify URL Test and make sure that all servers have passed the test by responding Pass. If the server is not available, then requests from external clients will not be sent to it. Component ARR will take it out of balancing until it is “seen” by the Client Access server again.
Let's move on to the section Proxy, set the settings:
- Time-Out: 200 seconds
- Response Buffer threshold: 0
don't forget to click Apply after making changes.
Load Balance, Monitoring and Management and Server Affinity don't touch.
6 ) Let's move on to creating rules for redirecting requests.
In the snap IIS open URL Rewrite
Create a rule for Autodiscover
To add a template in a tab "Conditions" press "Add" and enter the parameters:
Enter in the same way “(HTTPS) ON”
At the very bottom, select the action that needs to be performed if the request matches the template. In our case, this is a redirect to the server farm (don't forget to select https) and a checkbox prohibiting execution of the following (lower) rules.
Ready.
In a similar way, we create a rule for mail.contoso.com and, if desired, for activesync.contoso.com .
In the resulting list, the rule should come first Autodiscover, then activesync, after mail. The rules are worked out one by one, one after another. You can move rules in the list using the up and down arrows on the left.
Finishing touch. Go to “Request Filtering”
and set the value 2147483648 for parameter “Maximum allowed content length.”
Everything is ready! Now you need to configure external DNS servers to resolve names Autodiscover And mail(and if you set it up, then activesync) to IP IIS ARR.
At the request of workers, we are closing ECP
In Part 5 of this article series, we looked at creating a Client Access array in each Active Directory site. We then enabled Outlook Anywhere and also configured the Outlook Provider settings so that Outlook Anywhere clients could connect when an emergency occurred.
In this part of the series we will continue from where we left off in the previous part. We'll start by setting up the internal and external URL address and for CAS services on each Exchange 2010 server in both Active Directory sites. Next, we'll create a DAG and do some basic DAG setup.
Changing internal and external Exchange 2010 CAS URLs to point to HLB
Now it's time to configure the internal and external URLs for the Exchange 2010 CAS services in each datacenter to point to each load balancing solution respectively.
To briefly summarize the previous parts of this series, we can say that the address ‘ mail.exchangeonline.dk‘ points to the VIP address configured on the load balancing solution in the primary data center, and ‘ failover.exchangeonline.dk‘ points to the VIP address configured on the load balancing solution in the failover data center. This means that the URLs must be configured differently for each datacenter.
Outlook Web App (OWA)
Let's start with URLs for Outlook Web App (OWA). To do this we use the following commands:
Main data center:
Set-OwaVirtualDirectory -Identity "EX01\OWA (Default Web Site)" -InternalURL /OWA -ExternalURL https://mail.exchangeonline.dk/OWA
Set-OwaVirtualDirectory -Identity "EX03\OWA (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA
Emergency Data Center:
Set-OwaVirtualDirectory -Identity "EX02\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA
Set-OwaVirtualDirectory -Identity "EX04\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA
Figure 1: Configuring URLs for OWA Virtual Directory
Exchange Control Panel (ECP)
For the Exchange Control Panel (ECP) we use the following commands:
Main data center:
Set-EcpVirtualDirectory -Identity "EX01\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP
Set-EcpVirtualDirectory -Identity "EX03\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP
Emergency Data Center:
Set-EcpVirtualDirectory -Identity "EX02\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP
Set-EcpVirtualDirectory -Identity "EX04\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP
Figure 2: Configuring URLs for ECP Virtual Directory
Exchange ActiveSync (EAS)
For Exchange ActiveSync (EAS) we use the following commands:
Main data center:
Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server -Activesync
Set-ActivesyncVirtualDirectory -Identity "EX03\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft- Server-Activesync
Emergency Data Center:
Set-ActivesyncVirtualDirectory -Identity "EX02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft- Server-Activesync
Set-ActivesyncVirtualDirectory -Identity "EX04\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft- Server-Activesync
Figure 3: Configuring URLs for EAS Virtual Directory
Offline Address Book (OAB)
For Offline Address Book we use the following commands:
Main data center:
Set-OABVirtualDirectory -Identity "EX01\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab
Set-OABVirtualDirectory -Identity "EX03\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab
Emergency Data Center:
Set-OABVirtualDirectory -Identity "EX02\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab
Set-OABVirtualDirectory -Identity "EX04\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab
Figure 4: Configuring URLs for OAB Virtual Directory
Exchange Web Services (EWS)
For Exchange Web Services (EWS) we use the following commands:
Main data center:
Set-WebServicesVirtualDirectory -Identity "EX01\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx
Set-WebServicesVirtualDirectory -Identity "EX03\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx
Emergency Data Center:
Set-WebServicesVirtualDirectory -Identity "EX02\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx
Set-WebServicesVirtualDirectory -Identity "EX04\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx
Figure 5: Configuring URLs for EWS Virtual Directory
Unified Messaging (UM)
In this test environment we are not using Unified Messaging (UM), but if you have other plans, you will need to configure a URL for it using the following commands:
Main data center:
Set-UMVirtualDirectory -Identity "EX01\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx
Set-UMVirtualDirectory -Identity "EX03\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx
Emergency Data Center:
Set-UMVirtualDirectory -Identity "EX02\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx
Set-UMVirtualDirectory -Identity "EX04\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx
Internal Autodiscover URI
Finally, we need to point the internal URI of the Autodiscover Service to the FQDN of the HLB solution. This can be done using the following commands:
Main data center:
Set-ClientAccessServer ‘Identity EX01 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk
Set-ClientAccessServer ‘Identity EX03 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml
Emergency Data Center:
Set-ClientAccessServer ‘Identity EX02 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml
Set-ClientAccessServer ‘Identity EX04 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml
Figure 6: Internal Autodiscover URI Options
Note that we directed the Exchange 2010 servers in both datacenters to the same autodiscover URI. It is also possible to point the AutoDiscoverInternalUri on CAS servers in the disaster data center to ‘https://failover.exchangelabs.dk/autodiscover/autodiscover.xml’ so you may end up in a situation where SCPs are not available during a disaster. Also, cross-site traffic generated by the Autodiscover service will have less impact on the WAN link, since autodiscover requests consist of small text files XML.
Creating and configuring mailbox databases
Now that we're done with the CAS side, we can now concentrate on creating mailbox databases and creating and configuring a Database Availability Group (DAG).
In the test environment used in this article series, I created 12 mailbox databases distributed across two Exchange 2010 servers in the primary datacenter, as shown in Figure 7.
Figure 7: Exchange 2010 mailbox databases
Note: Because Outlook 2003 clients are not used in this environment and public folders are not used as data repositories, there are no public folder databases. If your situation is different, be aware that you cannot use the DAG feature to protect public folder data (as was the case with CCR in Exchange 2007). Instead, you must create at least one public folder database in each datacenter and add the corresponding servers that contain those databases to the copy list for each public folder.
As you can see, I named the databases DAG01-MDB001, DAG01-MDB002, etc. Not because I'm lazy, but because there's simply no need to use long and complex names for these databases. For databases that are part of a DAG, it is best to use naming standards in which the database name is preceded by the name of the DAG to which the database belongs. As for the paths to the database and log folders, it is better to use something like E:\DAG_name\Database_name.edb and F:\Dag_name\Database_name.
Note: When you have multiple copies of a database, you don't necessarily need to use dedicated LUNs for log files, you can simply use the same path as specified for the .edb file (in our example it's 'E:\DAG_name\Database_name'). This is fully supported and is the recommended method if you are not using hardware solution VSS backup to create backup copies their Exchange databases. Needless to say, you need to use mount points because otherwise you'll quickly run out of drive letters.
Adding an Exchange Trusted Subsystem group to Non-Exchange servers
For those of you who have deployed Exchange 2007 CCR or Exchange 2010 Mailbox DAG-based Mailbox servers, you should know that it is better to use a Hub Transport server in the same Active Directory site as a witness server for CCR cluster or DAG.
Since this environment consists of Exchange 2010 servers with multiple roles that are part of the same DAG, we cannot use the Exchange 2010 Hub Transport server as a witness server, but must use a traditional file server Windows Server 2008/R2 for this purpose. For this reason we need to add ‘ Exchange Trusted Subsystem‘ group created by the Exchange 2010 installation to the local administrators group on the corresponding file server. This is to ensure that the correct permissions are granted to Exchange. For this purpose, log into the file server and open the server manager ‘ Server Manager‘. Expand ‘ Configuration‘ > ‘Local users and groups (Local Users and Groups)‘ and open Properties groups Administrators.
Figure 8: Finding the local administrators group on file Windows server Server 2008 R2
Now enter ‘ Exchange Trusted Subsystem' into the text field as shown in Figure 9, and press OK.
Figure 9: Entering the Exchange Trusted Subsystem group
Click again OK.
Figure 10: Administrators Group Properties Page
As already stated, this step is only necessary when using a non-Exchange server as a witness server.
Creating and Configuring a DAG
Since our active users are constantly located in one data center (active/passive user distribution model), one extended DAG will be sufficient for this scenario.
To create a simple DAG group, run the group creation wizard ‘‘. To do this, expand the ‘Organization Configuration’ work center and right-click on ‘ Mailbox', then select the option to create new group ‘New Database Availability Group' V context menu. In the wizard, you need to specify the name of the DAG and enter the name of the witness server. Finally, we need to specify the path of the witness directory. I'll call the group DAG' DAG01‘ and will use a domain-joined file server (FS01) as a witness server. When ready, click ‘ New‘.
Figure 11: Creating a DAG
At the final (Completion) page we have a warning that the group ‘ Exchange Trusted Subsystem‘ is not a member of the group ‘ Local Administrators‘ on the specified witness server. This error can be ignored since we have already added this group.
Click Finish to exit the wizard ( Figure 12).
Figure 12: DAG Wizard ' final page
Setting up an alternate witness server
When it comes to using a DAG extended between two data centers (AD sites), it is recommended to first configure an alternative witness server, which this scenario there will be a file server (FS02) in the disaster data center.
To do this, we first need to add ‘ Exchange Trusted Subsystem‘ group to local administrators group ‘ (Local Administrators)‘ in the same way as described above. Then you need to specify FS02 as an alternate witness server on the DAG object itself. To do this, open the DAG properties page ‘ DAG01‘. In the tab ‘ General‘ we see the primary witness server FS01 and the witness directory for this server. Below we have the option to enter an alternative witness server ( Figure 13). We do this and press ‘ Apply‘. Leave the properties page open.
Figure 13: Specifying an alternate witness server
Assigning static IP addresses to a DAG group
Although it is possible to use DHCP assigned IP addresses for the DAG, I prefer to use static addresses, so the next step is to assign a static IP address for the DAG in each data center (in each subnet).
Note: If you want to use DHCP assigned IP addresses, you can skip this step.
To set a static IP address, go to the ‘ tab IP Addresses‘. In the tab ‘ IP Addresses‘ Set the IP address in each subnet for the DAG. Then click ‘ OK‘ to exit the properties page.
Figure 14: Assigning a Static IP Address to a DAG
So, we have created and configured a simple DAG.
As you all know that the service connectivity for a mail server is the main concern to all of us. In Exchange server 2010, the connectivity is as same as Exchange server 2007. Once you migrate or install the new version, this should be tested with the proper credentials and certificate..or else, you will end up with your mail server IP going to the blacklist, because of the wrong pointers and configurations. First of all, do the internal test. Go to your computer start bar, right side where Date and time is showing, you will find the Outlook icon, hold Ctrl + right click on the outlook icon and click “Test Email Auto Configuration...”
Select the “Use AutoDiscover” and click Test..
Above one is a success one..If failed, do the below. The Exchange Web Service (EWS) is the web service that allows access to the Out of Office service. If either the internal or external URL for the EWS is missing or incorrect, OOF will fail and other services may not work as expected. Using Exchange Management Shell, check the URLs assigned to the web service virtual directory using the Get-WebServicesVirtualDirectory command
First goto CAS server
Type the following Power Shell command for EWS (Exchange Web Service)
Copy code Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
You will get the result like below
InternalUrl:
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx
InternalUrl: https://mailv.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx
If this is not correct, you need to fix it.. This has to be done on Powershell command on the CAS server.
To do that...Copy code
C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS1\EWS (Default Web Site)” -InternalUrl -BasicAuthentication:$true
C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS2\EWS (Default Web Site)” -InternalUrl https://mail.domain.com/EWS/Exchange.asmx -BasicAuthentication:$true
C:\Windows\system32>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
Identity: ECAS1\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx
Identity: ECAS2\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx
Now you can see that the URL has been fixed. This is for Web Services.
Now for Autodiscovery….
C:\Windows\system32>Get-AutodiscoverVirtualDirectory
To see the settings
C:\Windows\system32>
C:\Windows\system32>Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Identity:ECAS1
https://mailv.domain.com/Autodiscover/Autodiscover.xml
Identity:ECAS2
AutoDiscoverServiceInternalUri: https://mailv.domain.com/Autodiscover/Autodiscover.xml
C:\Windows\system32>Set-ClientAccessServer -Identity ECAS1 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
C:\Windows\system32>Set-ClientAccessServer -Identity ECAS2 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
Now for the Outlook Web Apps, Exchange Control Panel, Exchange ActiveSync, Offline Address book…you have to go to Exchange Management Console (EMC)
- Goto one of the CAS server
- Open EMC
- Goto Server Configuration
- Select Client Access
- On the Middle top panel, you can see the CAS server listed.
- Select one, on the bottom panel, you will see like below.
Select each tab and then right click on the object and change the path as required. Once you are done with the first CAS servr, do the same for the second as well.
Thats it…you are good to go for production.
