Outlook Web App (OWA) is installed automatically when you install the Client Access and Mailbox server roles for Exchange Server 2013. In your Exchange organization, you must install at least one Client Access server in each Active Directory site containing an Exchange 2013 Mailbox server. If users will be accessing Outlook Web App over the Internet, then one of the Client Access servers you install must be Internet facing. This server accepts connections from external clients on an external URL.

In most cases, you need to open only TCP port 443 on your organization’s firewall to allow users to access mailboxes and public folder data over the web. After that, you simply tell users the URL path that they need to type into their browser’s Address text box in order to access Outlook Web App when they’re off-site.

Outlook Web App for Exchange 2013 has a streamlined interface that is optimized for PCs, tablets, and mobile devices. The browser used to access Outlook Web App determines the experience and supported features. The following two versions are available:

Outlook Web App uses HTML 4.0 and JavaScript [European Computer Manufacturers Association (ECMA) script]. With desktop and server operating systems that support these browsers, the standard version of Outlook Web App is available with Internet Explorer 9.0, Internet Explorer 10.0 or later, Firefox 17 or later, and Chrome 24 or later. With other browsers on desktop and server operating systems, the client functionality remains the same, but some features might not be supported.

The standard version of Outlook Web App also is available for tablets and smartphones running Windows 8 or Windows 8.1 in addition to iOS 6 or later. With browsers on other tablets and smartphones, the client functionality remains the same, but the browsers likely will display the light version of Outlook Web App.

Outlook Web App for Exchange Server 2013 has many features, including:

At the time of this writing, Outlook Web App doesn’t support distribution list moderation options, reading pane, or the ability to reply to email messages sent as attachments. Additionally, Exchange 2013 doesn’t support S/MIME.

With Outlook Web App, you can easily access mailboxes and public folder data over the web and a corporate intranet. To access a user’s mailbox, type the Exchange Outlook Web App URL into your browser’s Address text box, and then enter the user name and password for the mailbox you want to access. The complete step-by-step procedure is as follows:

After a user has accessed his mailbox in OWA, he can access public folders data that is available as well as long as the public folders are hosted on Exchange 2013. To access public folders, follow these steps:

The public folders you’ve added are listed under the Favorites heading in the left pane. To access a folder and display its contents in the main pane, simply select it in the left pane.

After you enter the Outlook Web App URL into a browser’s Address text box and log in, you’ll see the view of Outlook Web App compatible with your browser. Figure 6-1 shows the full-featured view of Outlook Web App. Most users see this view of Outlook Web App automatically. If their browsers don’t support a necessary technology for the full-featured view, some features or options won’t be available, or they might see the Light view instead. If they can press and hold or right-click and see a shortcut menu, they have the full-featured view.

As shown in Figure 6-1, the latest version of Outlook Web App has a toolbar that provides quick access to the following key features:

Figure 6-1. Outlook Web App has nearly all of the features of Microsoft Outlook.

Outlook Web App can be configured to allow users to connect their OWA account to up to five other email accounts. This allows users to keep send, receive, and read email from other email services. Users also can forward email from their Outlook Web App to another account. If users want to add their contacts from Facebook and LinkedIn to Outlook Web App contacts, Outlook Web App can be configured to do this, too.

Outlook Web App can be configured to allow users to work offline. Users can continue to work when they are disconnected from the Internet when OWA is configured to cache mail items and other information on the users’ computers. When Offline mode is allowed in the OWA configuration, users can enable offline settings by completing the following steps:

Currently, a quick and easy way to determine whether a mailbox has already been configured to use offline mode is not available. That said, the primary offline data for Outlook Web App and the user’s mailbox is cached under %LocalAppData%MicrosoftWindowsWebCache on the computer. After offline access is enabled, the browser reads data from this cache, allowing users to continue to work with Outlook Web App and access mail, contacts, and other mail data when their computers aren’t connected to the Internet.

If offline mode has been enabled, you can turn this feature off by selecting Settings, choosing Turn Off Offline Access, and then selecting OK. Disabling offline access doesn’t remove the cached data, nor does clearing the browser cache. Because the cached mail data is persistent across browser sessions and independent of the browser’s local cache, you must manually remove this data if you want to be certain the data can no longer be accessed.

Exchange Server 2013 enables Outlook Web App for each user by default and applies the Default Outlook Web App Mailbox policy to each user. Outlook Web App Mailbox policy controls the features that are enabled for each user and allows users to:

If necessary, you can enable or disable Outlook Web App or set a new default policy for specific users by completing the following steps:

As discussed in Chapter 3 of Exchange Server 2013 Pocket Consultant: Configuration and Clients (Microsoft Press, 2013), sometimes users and administrators see a blank page or an error when they try to log on to Outlook Web App. This problem and other connection issues, such as those related to Exchange Control Panel (ECP), Offline Address Book (OAB), Autodiscover, and Windows PowerShell, can occur because of a wide variety of configuration issues, including:

You resolve these issues by correcting the configuration problem as discussed in that chapter. Beyond configuration issues, Exchange servers can have connectivity, resource, and service issues. You can use Test-OwaConnectivity to test connectivity to Outlook Web Access as part of troubleshooting connectivity; however, this cmdlet is deprecated and will be removed in a future release of Exchange Server.

Exchange 2013 uses Active Monitoring to monitor essential services, connectivity, resources and the overall health of the messaging platform. Active Monitoring is performed by the Microsoft Exchange Health Manager service, which must be running on the Exchange server. As discussed in detail in Chapter 8 Active Monitoring is itself part of the Managed Availability feature.

The overall health of Outlook Web App is tracked by the OWA health set. A health set includes a probe that takes measurements on the server and collects data, and a monitor that uses the collected data to determine whether a resource is healthy. OWA relies on the OwaCtpProbe to measure the health of Outlook Web App and the OwaCtpMonitor to determine the status of Outlook Web App. The OWA health is dependent on Active Directory Domain Services (AD DS) and the Microsoft Exchange Information Store service.

Alerts related to resources are logged in the event logs. You also can manually check the status of resources by using the Get-HealthReport and Get-ServerHealth. Whereas Get-ServerHealth provides the exact state and health of every Exchange resource, monitor, and service, Get-HealthReport returns the state of monitored resources.

You can quickly check for unhealthy resources by entering the following command:

Get-ServerHealth -Identity ServerID | where ($_.AlertValue -eq
'Unhealthy')

ServerID is the host name or fully-qualified name of the Exchange server to check, such as:

Get-ServerHealth -Identity MailServer21.pocketonconsultant.com |
where ($_.AlertValue -eq 'Unhealthy')

Rather than check all resources and health sets, you can explicitly check the status of the OWA-related health sets by using the following command:

Get-ServerHealth ServerID | ?{$_.HealthSetName -match "OWA"}

ServerID is the host name or fully-qualified name of the Exchange server to check, such as:

Get-ServerHealth MailServer21.pocketonconsultant.com |
?{$_.HealthSetName -match "OWA"}

As discussed in Chapter 1 Client Access servers use IIS for front-end services, such as authentication and proxying, whereas Mailbox servers use IIS for back-end processing. On Client Access servers, you’ll find front-end apps for OWA, ECP, Windows PowerShell, OAB, and Autodiscover apps are configured on the default website. On Mailbox servers, you’ll find back-end apps for OWA, ECP, Windows PowerShell, OAB, and Autodiscover are configured on an Exchange Back End website.

If the OWA health set reports an unhealthy status, an issue is present that might prevent users from accessing their mailboxes in Outlook Web App. Such issues include:

Some of these problems can be resolved automatically by the responder engine, which is another Managed Availability component. When a problem exists with application pools or services on Exchange servers, the responder engine attempts to recover the resource by restarting the application pool or service that is causing the problem. The problem identification and recovery process can take several minutes. If you notice a problem with Outlook Web App that you suspect is related to application pools or services, you can, of course, perform the restart procedures yourself to try to restore access more quickly to Outlook Web App.

OWA.Proxy and OWA.Protocol also are related health sets. OWA.Proxy relies on OwaProxyTestProbe, OWAAnonymousCalendarProblem, and OwaProxyTestMonitor to track the status of proxy services and calendaring features. OWA.Protocol relies on:

As with the OWA health set, an unhealthy status for OWA.Proxy or OWA.Protocol means an issue exists that might prevent users from accessing their mailboxes in Outlook Web App. The common issues for the OWA.Protocol health set are the same as those for the OWA health set. With OWA.Proxy, common issues may be related to the OWA application pool not responding on the Client Access server providing front-end proxy services, a domain controller not responding, or the credentials for the monitoring account being incorrect.

You can diagnose a problem with OWA by using Get-HealthReport to check the status of an OWA-related health set. If the problem you are experiencing with Outlook Web App isn’t a configuration issue, use the following techniques to try to resolve the problem while verifying the issue still exists each time you take a corrective action:

After you complete the troubleshooting, you may want to examine the event logs and try to determine the cause of the problem. You may also want to check Exchange-specific logs, including the connectivity logs and the protocol logs. For more information, see Chapter 8.

IIS handles incoming requests to a website within the context of a web application. A web application is a software program that delivers content to users over HTTP or HTTPS. Each website has a default web application and one or more additional web applications associated with it. The default web application handles incoming requests that you haven’t assigned to other web applications. Additional web applications handle incoming requests that specifically reference the application.

When you install an Exchange server, virtual directories and web applications are installed to support various Exchange services. Each web application must have a root virtual directory associated with it. The root virtual directory sets the application’s name and maps the application to the physical directory that contains the application’s content. Typically, the default web application is associated with the root virtual directory of the website and any additional virtual directories you’ve created but haven’t mapped to other applications.

In the default configuration, the default application handles an incoming request for the / directory of a website as well as other named virtual directories. IIS maps references to / and other virtual directories to the physical directory that contains the related content. For the / directory of the default website, the default physical directory is %SystemRoot%/inetpub/wwwroot.

In most cases, you only need to open port 443 on your organization’s firewall to allow users to access Exchange data hosted by IIS. Then you simply tell users the URL that they need to type into their browser’s Address field or in their smartphone’s browser. Users can then access Outlook Web App or Exchange ActiveSync when they’re off-site. The URLs for Outlook Web App and Exchange ActiveSync are different. The Outlook Web App URL is https://yourserver.yourdomain.com/owa, and the Exchange ActiveSync URL is https://yourserver.yourdomain.com/Microsoft-Server-ActiveSync. Generally, however, the address users enter for both matches the OWA address.

You can configure Outlook Web App and Exchange ActiveSync for single-server and multiserver environments. In a single-server environment, you use one Client Access server for all your web and mobile access needs. In a multiple server environment, you could instruct users to access different URLs to access different Client Access servers, or you could use a technique such as Round Robin Domain Name System (DNS) to load-balance between multiple servers automatically while giving all users the same access URLs. However, for optimal scalability and availability, you should configure a Client Access server (CAS) array and then use a software or hardware load balancer.

You can use Outlook Web App and Exchange ActiveSync with firewalls. You configure your network to use a perimeter network with firewalls in front of the designated Client Access servers and then open port 443 to your Client Access servers or to the URL for the CAS array.

When you install an Exchange server, Exchange Setup installs and configures virtual directories and Web applications for use. The virtual directories and web applications allow authenticated users to access their messaging data from the web. On Client Access servers, you’ll find a default website that provides front-end services. On a Mailbox server, you’ll find an Exchange Back End website that provides backend services. Apps on the front end have corresponding back-end apps, with connections being proxied from the front end to the back end for processing.

In the Exchange Management Shell, you can use the Get-OWAVirtualDirectory cmdlet to view information about OWA virtual directories, the New-OWAVirtualDirectory cmdlet to create an OWA directory if one does not exist, the Remove-OWAVirtualDirectory cmdlet to remove an OWA directory, and the Test-OWAConnectivity cmdlet to test OWA connectivity. There are similar sets of commands for ActiveSync, Autodiscover, ECP, OAB, Windows PowerShell, and web services. Exchange Server automatically configures these directories as appropriate when a server has only the Client Access Server or Mailbox Server role installed.

On the other hand, you’ll typically want to specify whether you want to work with the front-end virtual directory or back-end virtual directory when a server has both roles installed as this will ensure the directory you expect to be configured is the one created or modified. Whether you are working with virtual directories for OWA, Exchange ActiveSync, Autodiscover, ECP, OAB, Windows PowerShell, or web services, the parameter you use to specify explicitly the virtual directory you want to work with is the -Role parameter. Set -Role to ClientAccess when you want to configure the front-end virtual directory on a server with both the Client Access and Mailbox server roles installed. Set -Role to Mailbox when you want to configure the back-end virtual directory on a server with both the Client Access and Mailbox server roles installed.

If you examine the virtual directory structure for the default website or the Exchange Back End website, you’ll find several important virtual directories and web applications, including:

For troubleshooting configuration issues with virtual directories, you might need to remove and recreate the front-end virtual directory first, and then check to see if this resolves the problem before removing and recreating the back-end virtual directory. As an example, if you’ve determined the OWA virtual directory is misconfigured, you can remove it by using Remove-OwaVirtualDirectory, and then recreate it by using New-OwaVirtualDirectory. You could remove and then recreate the OWA virtual directory from the default website on MailServer21 by using the following commands:

remove-owavirtualdirectory -identity "mailserver21owa (Exchange Back End)"
new-owavirtualdirectory -server mailserver21
-websitename "Exchange Back End"

By default, the New-OwaVirtualDirectory and New-EcpVirtualDirectory commands enable basic authentication and forms authentication but do not enable Windows authentication. Because Windows authentication is required for OWA and ECP, you’ll want to use the Set-OwaVirtualDirectory and Set-EcpVirtualDirectory commands to modify the default authentication settings. In the following example, you enable Windows authentication and disable basic and forms authentication:

set-owavirtualdirectory -identity "mailserver21owa (Exchange Back End)"
-WindowsAuthentication $True -Basicauthentication $false
-Formsauthentication $false

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory
-ChangePassword $true

After you recreate a virtual directory you should restart IIS services. You can do this in IIS Manager or by entering the following command at an elevated command prompt or shell:

iisreset

You can diagnose non-configuration problems with a particular feature as well as any related proxy and protocol features by using Get-HealthReport to check the status of the related health sets. Try to resolve the problem by using the following techniques while verifying the issue still exists each time you take a corrective action:

After you complete the troubleshooting, you may want to examine the event logs and try to determine the cause of the problem. You may also want to check IIS-specific logs. For more information, see Chapter 8.

Microsoft uses the term segmentation to refer to your ability to enable and disable the various features within Outlook Web App. Segmentation settings applied to the OWA virtual directory on Client Access servers control the features available to users. If a server has multiple OWA virtual directories or you have multiple Client Access servers, you must configure each directory and server separately. Table 6-1 provides a summary of the segmentation features that are enabled by default for use with Outlook Web App.

You manage segmentation features in several ways:

To enable or disable segmentation features for a particular virtual directory, complete the following steps:

To create an Outlook Web App policy, follow these steps:

In Exchange Management Shell, you can create Outlook Web App policies by using New-OwaMailboxPolicy and then set the properties of the policy by using Set-OwaMailboxPolicy. The following example creates a policy called AllUsers and then configures its settings:

New-OwaMailboxPolicy -Name AllUsers
Set-OwaMailboxPolicy -Identity AllUsers -AllAddressLists $false
-ChangePasswordEnabled $false -AllowOfflineOn "NoComputers"
-ContactsEnabled $false -LinkedInEnabled $false
-CalendarEnabled $true

Use Get-OwaMailboxPolicy to confirm that the properties of the policy are set as expected. Afterward, you can apply the policy to users by using the -OwaMailboxPolicy property of Set-CASMailbox. Techniques for applying OWA mailbox policies to mailbox users shows various ways you can apply the policy.

Apply the policy to the mailbox user named HenryJ
Set-CASMailboxPolicy -Identity HenryJ -OwaMailboxPolicy "AllUsers"

Apply the policy to every mailbox in the Exchange organization
Get-Mailbox -ResultSize Unlimited | Set-CASMailbox
-OwaMailboxPolicy "AllUsers"

Apply the policy to every mailbox in the Sales database
Get-MailboxDatabase "Sales" | Get-Mailbox -ResultSize Unlimited |
Set-CASMailbox -OwaMailboxPolicy "AllUsers"

Apply the policy to all mailboxes in every mailbox database on MailboxServer18
Get-Mailbox -Server MailboxServer18 -ResultSize Unlimited |
Set-CASMailbox -OwaMailboxPolicy "AllUsers"

Each website hosted by IIS has one or more bindings. A binding is a unique combination of ports, IP addresses, and host names that identifies a website. For unsecure connections, the default port is TCP port 80. For secure connections, the default port is TCP port 443. The default IP address setting is to use any available IP address. The default host name is the Client Access server’s DNS name.

Normally, you wouldn’t want to multihome a Client Access server; however, when the server is multihomed, or when you use it to provide Outlook Web App or Exchange ActiveSync services for multiple domains, the default configuration isn’t ideal. On a multihomed server, you’ll usually want messaging protocols to respond only on a specific IP address. To do this, you need to change the default settings. On a server that provides Outlook Web App and Exchange ActiveSync services for multiple domains, you’ll usually want to specify an additional host name for each domain

When you are working with IIS, you can change the identity of a website by completing the following steps:

SSL is a protocol for encrypting data that is transferred between a client and a server. Without SSL, servers pass data in readable, unencrypted text to clients, which could be a security risk in an enterprise environment. With SSL, servers pass data encoded using encryption.

Although websites are configured to use SSL on port 443 automatically, the server won’t use SSL unless you’ve created and installed a valid X.509 certificate. When you install an Exchange server, a default X.509 certificate is created for Exchange Server 2013 and registered with IIS. In IIS Manager, you can view the default X.509 certificate by completing the following steps:

For a long-term solution, you need to create a permanent certificate for the server. This certificate can be a certificate assigned by your organization’s certificate authority (CA) or a third-party certificate. To create a certificate for use with Exchange and IIS, use the features provided by the Exchange management tools. In the Exchange Admin Center, you can view available certificates for Exchange servers by selecting Servers in the Feature pane, and then selecting Certificates. Next, on the Select Server list, choose the server you want to work with. You’ll then see a list of available certificates for this server.

You can view the general settings for the certificate by selecting it and then selecting Edit. The subject alternative names associated with the certificate determine the names that can be used when establishing SSL connections. Typically, the subject alternative names include the host name and the fully-qualified domain name of the server (see Figure 6-6). On the Services page, each selected option represents a service assigned to the certificate. By assigning a service to a certificate, you are allowing the certificate to be used to secure the service. After you are done viewing a certificate’s properties, tap or click Cancel (you don’t want to inadvertently make any changes to a certificate).

Figure 6-6. View the properties of an SSL certificate in Exchange Admin Center.

To request and create a certificate from a certification authority, complete the following steps:

Send the certificate request file to a third-party certificate authority or your organization’s CA as appropriate. When you receive the certificate back from the CA, import the certificate. In the Certificates area, you’ll see an entry for the certificate with a status of Pending Request. Select this entry, and then select Complete in the details pane. Next, in the Complete Pending Request dialog box, specify the full file path for a network location where the certificate file is available to be imported, such as \MailServer92DataMyCertificate.cer. Tap or click OK.

If you have a certificate to install but don’t have a pending request, you can import the certificate while working with the Certificates area in the Exchange Admin Center as well. To do this, complete the following steps:

After you’ve installed the certificate, you should test the certificate with an external client by accessing OWA from a remote computer. Clients won’t automatically trust self-signed certificates or certificates issued by your CA; therefore, you might see an error stating that there is a problem with the website’s security certificate. In Internet Explorer, follow these steps to have the client trust the certificate:

You also can test services supported by the certificate. Test web services by using Test-OutlookWebServices as shown in the following example:

test-outlookwebservices | fl

By default Test-OutlookWebServices, verifies the Availability service, Outlook Anywhere, Offline Address Book, and Unified Messaging. You can test OWA and ECP by using Test-OwaConnectivity and Test-EcpConnectivity respectively.

Another way to test connectivity is to use the Remote Connectivity Analyzer. In a web browser, enter the following URL: https://testexchangeconnectivity.com.

You can control incoming connections to a website in several ways including setting a maximum limit on the bandwidth used, setting a limit on the number of simultaneous connections, and setting a connection time-out value. However, you typically wouldn’t want to perform any of these actions for an Exchange server or OWA. OWA has its own timers based on whether the end user is on a public/shared or a private computer. These values are fixed and not affected by any restrictions or settings discussed in this section.

Normally, websites do not have maximum bandwidth limits and accept an unlimited number of connections, which is an optimal setting in most environments. However, when you’re trying to prevent the underlying server hardware from becoming overloaded or you want to ensure other websites on the same computer have enough bandwidth, you might want to limit the bandwidth available to the site and the number of simultaneous connections. When either limit is reached, no other clients are permitted to access the server. The clients must wait until the connection load on the server decreases.

The connection time-out value determines when idle user sessions are disconnected. With the default website, sessions time out after they’ve been idle for 120 seconds (2 minutes). It’s a sound security practice to disconnect idle sessions and force users to log back on to the server. If you don’t disconnect idle sessions within a reasonable amount of time, unauthorized persons could gain access to your messaging system through a browser window left unattended on a remote terminal.

You can modify connection limits and time-outs by completing the following steps:

You might occasionally find that you want to redirect users to alternate URLs. For example, you might want users to type http://mail.cpandl.com and get redirected to https://mail.cpandl.com/owa.

You can redirect users from one URL to another by completing the following steps:

IIS supports several authentication methods, including the following:

When you install IIS on a Client Access server, you are required to enable basic authentication, digest authentication, and Windows authentication. These authentication methods, along with anonymous authentication, are used to control access to the server’s virtual directories. A virtual directory is simply a folder path that is accessible by a URL. For example, you could create a virtual directory called Data that is physically located on C:CorpDataData and accessible by using the URL https://myserver.mydomain.com/Data.

Table 6-2 summarizes the default authentication settings for important virtual directories on a Client Access server. You should rarely change the default settings; however, if your organization has special needs, you can change the authentication settings at the virtual directory level.

Table 6-3 summarizes the default authentication settings for important virtual directories on a Mailbox server. Again, you should rarely change the default settings.

The authentication settings on virtual directories are different from authentication settings on the default website and Exchange Back End website. By default, these websites allow anonymous access. This means that anyone can access the server’s home page without authenticating themselves. If you disable anonymous access at the server level and enable some other type of authentication, users need to authenticate themselves twice: once for the server and once for the virtual directory they want to access.

The preferred way to manage authentication settings is to use the appropriate cmdlet in the Exchange Management Shell:

As an example, to disable basic authentication on the default ActiveSync directory, you would enter:

Set-ActiveSyncVirtualDirectory –Identity "Default Web Sitemicrosoft-server-activesync" –BasicAuthEnabled $false

You can change the authentication settings for an entire site or for a particular virtual directory by completing the following steps:

Every Client Access server in your organization is subject to the default client throttling policy. Client throttling policies are designed to ensure that users aren’t intentionally or unintentionally overloading Exchange. Exchange tracks the resources that each user consumes and applies throttling policy to enforce connection bandwidth limits as necessary.

The default policy is set in place when you install your first Exchange 2013 Client Access server. In Exchange 2013, there is a single default throttling policy for the organization. You can customize the default policy or add additional policies as necessary.

To manage throttling policy, you use Exchange Management Shell and the Get-ThrottlingPolicy, Set-ThrottlingPolicy, New-ThrottlingPolicy, and Remove-ThrottlingPolicy cmdlets. Throttling policy applies to:

With all of these features except Windows PowerShell, you can specify separate settings for the following:

With Windows PowerShell you can specify:

You can get the default throttling policy by entering: Get-ThrottlingPolicy default* or Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}. You can get the throttling policy applied to a particular user by entering (Get-Mailbox UserAlias).ThrottlingPolicy where UserAlias is the alias for a user, such as:

(Get-Mailbox jimj).ThrottlingPolicy | Get-ThrottlingPolicy

(Get-Mailbox jimj).RetentionPolicy | Get-RetentionPolicy
(Get-Mailbox jimj).SharingPolicy | Get-SharingPolicy
(Get-Mailbox jimj).AddressBookPolicy | Get-AddressBookPolicy
(Get-Mailbox jimj).RoleAssignmentPolicy | Get-RoleAssignmentPolicy

You can create a nondefault throttling policy by using the New-ThrottlingPolicy cmdlet. You can then assign the policy to a mailbox by using the -ThrottlingPolicy parameter of the Set-Mailbox and New-Mailbox cmdlets. In the following example, you apply TempUserThrottlingPolicy to AmyG:

Set-Mailbox –Identity amyg –ThrottlingPolicy (Get-ThrottlingPolicy
TempUserThrottlingPolicy)

By using Set-ThrottlingPolicy, you can modify default and nondefault throttling policies. To have a user go back to the default policy, set the -ThrottlingPolicy parameter to $null as shown in this example:

Set-Mailbox –Identity amyg –ThrottlingPolicy $null

You can find all user mailboxes that currently have a particular policy applied by using Get-Mailbox with a where-object filter. In the following example, you look for all user mailboxes that have the TempUserThrottlingPolicy:

$p = Get-ThrottlingPolicy TempUserThrottlingPolicy
Get-Mailbox | where-object {$_.ThrottlingPolicy -eq $p.Identity}

To switch multiple users from one policy to another, you can do the following:

$op = Get-ThrottlingPolicy TempUserThrottlingPolicy
$ms = Get-Mailbox | where-object {$_.ThrottlingPolicy -eq $op.Identity}
$np = Get-ThrottlingPolicy RestrictedUserThrottlingPolicy
foreach ($m in $ms) {Set-Mailbox $m.Identity –ThrottlingPolicy $np;}

You can remove nondefault policies that aren’t currently being applied by using Remove-ThrottlingPolicy. Simply enter Remove-ThrottlingPolicy followed by the name of the policy as shown in this example:

Remove-ThrottlingPolicy TempUserThrottlingPolicy

Websites run under a server process that you can start, stop, and pause, much like other server processes. For example, if you’re changing the configuration of a website or performing other maintenance tasks, you might need to stop the website, make the changes, and then restart it. When a website is stopped, it doesn’t accept connections from users and can’t be used to deliver or retrieve mail.

The master process for all websites is the World Wide Web Publishing Service. Stopping this service stops all websites using the process, and all connections are disconnected immediately. Starting this service restarts all websites that were running when you stopped the World Wide Web Publishing Service.

You can start, stop, or restart a website by completing the following steps:

If you suspect there’s a problem with the World Wide Web Publishing Service or other related IIS services, you can use the following technique to restart all IIS services:

Outlook 2007 and later clients can retrieve the offline address book (OAB) from a web distribution point. The default distribution point is the OAB virtual directory on the default website. Each distribution point has the following three associated properties:

You can configure web distribution points by completing the following steps:

After you make changes to the OAB directory, you should verify that you can still access the OAB. If you can’t access OAB or suspect there is a configuration problem, you can reset the OAB virtual directory by selecting it in the list of virtual directories, selecting Reset, and then confirming the reset by selecting Reset in the warning dialog box. When you reset a virtual directory, Exchange deletes the virtual directory and then recreates it with its default settings. Resetting a directory means any custom settings will be lost.

When you install a Client Access server, the server is configured with a default website and the virtual directories discussed previously. Through the OWA virtual directory, you can specify different URLs for internal access and external access to OWA. You can also configure various authentication options.

You can configure OWA virtual directory URLs and authentication options by completing the following steps:

After you make changes to the OWA directory, you should verify that you can still access Outlook Web App. If you can’t access Outlook Web App or suspect there is a configuration problem, you can reset the OWA virtual directory by selecting it in the list of virtual directories, selecting Reset, and then confirming the reset by selecting Reset in the warning dialog box. When you reset a virtual directory, Exchange deletes the virtual directory and then recreates it with its default settings. Resetting a directory means any custom settings will be lost.

When you install a Client Access server, the server is configured with a default website that has a virtual directory for Exchange ActiveSync. Through this virtual directory, you can specify different URLs for internal access and external access to Exchange ActiveSync. You also can configure various authentication options.

You can configure the Exchange ActiveSync URLs and authentication options by completing the following steps:

After you make changes to the ActiveSync directory, you should verify that you can still access Exchange ActiveSync. If you can’t access Exchange ActiveSync or suspect there is a configuration problem, you can reset the ActiveSync virtual directory by selecting it in the list of virtual directories, selecting Reset, and then confirming the reset by selecting Reset in the warning dialog box. When you reset a virtual directory, Exchange deletes the virtual directory and then recreates it with its default settings. Resetting a directory means any custom settings will be lost.

When you install a Client Access server, the server is configured with a default website and the virtual directories discussed previously. Through the ECP virtual directory, you can specify different URLs for internal and external access to Exchange Admin Center. You can also configure various authentication options.

You can configure ECP virtual directory URLs and authentication options by completing the following steps:

After you make changes to the ECP directory, you should verify that you can still access the Exchange Admin Center. If you can’t access Exchange Admin Center or suspect there is a configuration problem, you can reset the ECP virtual directory by selecting it in the list of virtual directories, selecting Reset, and then confirming the reset by selecting Reset in the warning dialog box. When you reset a virtual directory, Exchange deletes the virtual directory and then recreates it with its default settings. Resetting a directory means any custom settings will be lost.

Clients that retrieve mail by using POP3 or IMAP4 send mail by using SMTP. SMTP is the default mail transport in Exchange Server 2013. To enable POP3 and IMAP4, you must first start the POP3 and IMAP4 services on the Exchange servers that will provide these services. You must then configure these services to start automatically in the future. You should also review the related settings for each service and make changes as necessary to optimize the way these services are used in your Exchange organization.

Because the Client Access infrastructure has two-layers and Client Access servers proxy connections to Mailbox servers, there’s a front-end component and a back-end component for both POP3 and IMAP4. On a Client Access server, you can enable and configure the POP3 service for automatic startup by completing these steps:

The corresponding service on Mailbox servers is the POP3 Backend service. On a Mailbox server, you can enable and configure the POP3 Backend service for automatic startup by completing the following steps:

If you want to enable IMAP4, configure the Microsoft Exchange IMAP4 service on your Client Access servers and the Microsoft Exchange IMAP4 Backend service on your Mailbox servers by selecting the respective services in the Service utility and configuring the services according to steps 3 and 4 in the previous procedure.

You can use Set-Service to enable and configure POP3 and IMAP4 as well. Use the –StartupType parameter to set the startup type as Automatic, Manual, or Disabled. Use the –Status parameter to set the status as Running, Paused, or Stopped. The following examples enable POP3 and IMAP4 for automatic startup and then start the services:

Set-Service –Name MSExchangePop3 –StartupType Automatic –Status Running
Set-Service –Name MSExchangeImap4 –StartupType Automatic –Status Running

The following examples enable the POP3 and IMAP4 Backend services for automatic startup, and then start the services:

Set-Service –Name MSExchangePop3BE –StartupType Automatic –Status Running
Set-Service –Name MSExchangeImap4BE –StartupType Automatic –Status Running

POP3 and IMAP4 have related IP address and TCP port configuration settings. The default IP address setting is to use any available IP address. On a multihomed server, however, you’ll usually want messaging protocols to respond on a specific IP address, in which case you need to change the default setting.

The default port setting depends on the messaging protocol being used and whether SSL is enabled or disabled. For users to be able to retrieve mail using POP3 and IMAP4, you must open the related messaging ports on your organization’s firewalls. Table 6-4 shows the default port settings for key protocols used by Exchange Server 2013.

In the Exchange Management Shell, you can manage POP3 and IMAP4 by using the following cmdlets:

The bindings for POP3 and IMAP4 use a unique combination of an IP address and a TCP port. To change the IP address or port number for POP3 or IMAP4, complete the following steps:

By default, POP3 and IMAP4 clients pass connection information and message data through a secure TLS connection. A secure TLS connection requires the Exchange servers to have properly configured SSL certificates with POP3, IMAP4, or both as assigned services.

Secure TLS connections are the best option to use when corporate security is a high priority and secure communication channels are required. That said, you have two other options for configuring communications: plain-text authentication and logon using integrated Windows authentication.

You configure communications by using plain-text authentication logon with or without integrated Windows authentication by completing the following steps:

You can configure an Outlook client to use TLS by completing the following steps:

You can control incoming connections to POP3 and IMAP4 in two ways. You can set a limit on the number of simultaneous connections, and you can set a connection time-out value.

POP3 and IMAP4 normally accept a maximum of 2,147,483,467 connections each and a maximum of 16 connections from a single user, and in most environments these are acceptable settings. However, when you’re trying to prevent the underlying server hardware from becoming overloaded or you want to ensure resources are available for other features, you might want to restrict the number of simultaneous connections to a much smaller value. When the limit is reached, no other clients are permitted to access the server. The clients must wait until the connection load on the server decreases.

The connection time-out value determines when idle connections are disconnected. Normally, unauthenticated connections time out after they’ve been idle for 60 seconds and authenticated connections time out after they’ve been idle for 1,800 seconds (30 minutes). In most situations, these time-out values are sufficient. Still, at times you’ll want to increase the time-out values, and this primarily relates to clients who get disconnected when downloading large files. If you discover that clients are being disconnected during large downloads, the time-out values are one area to examine. You’ll also want to look at the maximum command size. By default, the maximum command size is restricted to 512 bytes.

You can modify connection limits and time-outs by completing the following steps:

Message retrieval settings for POP3 and IMAP4 control the following options:

You can modify message retrieval settings by completing the following steps:

The only requirement for Outlook Anywhere is that Exchange servers have properly configured SSL certificates. Because Outlook Anywhere requests use HTTPS, you must allow port 443 through your firewall. If you already use Outlook Web App with SSL or Exchange ActiveSync with SSL, port 443 should already be open and you do not have to open any additional ports.

As with other services, Outlook Anywhere has front-end components on Client Access servers and back-end components on Mailbox servers. Specifically, Outlook Anywhere uses the RPC virtual directory on Client Access servers and the RPC and RPCWithCert virtual directories on Mailbox servers. To customize the environment for users, you can configure the front-end settings on your Client Access servers.

You can use the Get-OutlookAnywhere cmdlet to list configuration details for Outlook Anywhere. If you use the –Server parameter, you can limit the results to a specific server. If you use the –Identity parameter, you can examine a particular virtual directory on a server. Get-OutlookAnywhere cmdlet syntax and usage provides the syntax, usage, and sample output.

Syntax
Get-OutlookAnywhere [-Server ServerName] [-DomainController DCName]
Get-OutlookAnywhere [-Identity VirtualDirId] [-DomainController DCName]

Usage
Get-OutlookAnywhere
Get-OutlookAnywhere -Server "MailServer42"
Get-OutlookAnywhere -Identity "MailServer42Rpc (Default Web Site)"

Output
ServerName                         : MAILSERVER42
SSLOffloading                      : True
ExternalHostname                   :
InternalHostname                   : mailserver42.pocket-consultant.com
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
XropUrl                            :
ExternalClientsRequireSsl          : False
InternalClientsRequireSsl          : False
MetabasePath                       : IIS://MAILSERVER42.pocket-consultant.com/W3SVC/1/ROOT/Rpc
Path                               : C:Program FilesMicrosoftExchange
ServerV15FrontEndHttpProxy
pc
ExtendedProtectionTokenChecking    : None
ExtendedProtectionFlags            : {}
ExtendedProtectionSPNList          : {}
AdminDisplayVersion                : Version 15.0 (Build 620.29)
Server                             : MAILSERVER42
AdminDisplayName                   :
ExchangeVersion                    : 0.20 (15.0.0.0)
Name                               : Rpc (Default Web Site)
DistinguishedName                  : CN=Rpc (Default Web
Site),CN=HTTP,CN=Protocols,CN=MAILSERVER42,CN=Servers,CN=Exchange
Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First
Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,
C=pocket-consultant,DC=com
Identity                           : MAILSERVER42Rpc (Default Web Site)
Guid                               :
ObjectCategory                     : pocket-consultant.com/Configuration/
Schema/ms-Exch-Rpc-Http-Virtual-Directory
ObjectClass                        : {top, msExchVirtualDirectory,
msExchRpcHttpVirtualDirectory}
WhenChanged                        : 9/18/2013 7:15:43 PM
WhenCreated                        : 9/18/2013 7:15:43 PM
WhenChangedUTC                     : 9/19/2013 2:15:43 AM
WhenCreatedUTC                     : 9/19/2013 2:15:43 AM
OrganizationId                     :
OriginatingServer                  : CorpServer27.pocket-consultant.com
IsValid                            : True
ObjectState                        : Changed

When you install a Client Access server, the server is configured with a default website and the virtual directories discussed previously. Through the RPC virtual directory, you can specify different URLs for internal and external access to Outlook Anywhere. You can also configure various authentication options.

You can configure RPC virtual directory URLs and authentication options by completing the following steps:

If you want to modify the Outlook Anywhere configuration, you can use the Set-OutlookAnywhere cmdlet to do this. Set-OutlookAnywhere cmdlet syntax and usage provides the syntax and usage. The –IISAuthenticationMethods parameter sets the authentication method for the /rpc virtual directory as either Basic, NTLM, or Negotiate and disables all other methods.

Syntax
Set-OutlookAnywhere -Identity VirtualDirId
 [-DefaultAuthenticationMethod {AuthMethod}]
 [-ExternalHostName ExternalHostName]
 [-IISAuthenticationMethods <Basic | NTLM | Negotiate>]
 [-InternalHostName InternalHostName]
 [-Name Name]
 [-SSLOffloading <$true | $false>]
{AuthMethod}
<Basic | Digest | NTLM | Fba | WindowsIntegrated | LiveIdFba |
LiveIdBasic | WSSecurity | Certificate | NegoEx | OAuth | Adfs | Kerberos
| Negotiate | LiveIdNegotiate | Misconfigured>

Usage
Set-OutlookAnywhere -Identity "CorpSvr127Rpc (Default Web Site)"
 -ExternalHostName "mail.cpandl.com"
 -InternalHostName "mailserer21.cpandl.com"
 -ExternalClientAuthenticationMethod "Negotiate"
 -SSLOffloading $true