Chapter 3. Exchange administration essentials
Whether you’re using Microsoft Exchange Server 2013 and Exchange Online for the first time or honing your skills, you’ll need to master many key concepts to work effectively. You’ll need to know the following:
How to access and work with Exchange Admin Center
How connections are authenticated and proxied
How Exchange uses virtual directories
Why Exchange requires SSL certificates
Which Windows processes are used with Exchange Server
You also need to know how to bypass Exchange Admin Center and Exchange Management Shell so that you can work directly with Exchange Server. These topics are all covered in this chapter.
Accessing and using Exchange Admin Center
Exchange Admin Center is a browser-based application designed for managing on-premises, online, and hybrid Exchange organizations. You access Exchange Admin Center through the Client Access servers deployed in your Exchange organization. Although the application can be configured with an internal access URL and an external access URL, only an internal access URL is configured by default. This means that by default you can access Exchange Admin Center only when you are on the corporate network.
Accessing Exchange Admin Center
Exchange Admin Center is designed to be used with many operating systems and browsers. However, to ensure all features are available you should use Exchange Admin Center only with the following browser and operating system combinations:
For Windows 7 and Windows Server 2008 R2 use Internet Explorer 9 or later, Firefox 17 or later, or Chrome 24 or later.
For Windows 8 or later and Windows Server 2012 RTM or R2 use Internet Explorer 10 or later, Firefox 17 or later, or Chrome 24 or later.
For Mac OS X 10.5 or later use Firefox 17 or later, Safari 6 or later, or Chrome 24 or later.
For Linux use Firefox 17 or later, or Chrome 24 or later.
Although Exchange Admin Center replaces Exchange Management Console and Exchange Control Panel (ECP), ECP continues to be the name for the related virtual directory. You access Exchange Admin Center by following these steps:
Open your web browser and enter the secure URL for Exchange Admin Center. If you are outside the corporate network, enter the external URL, such as https://mail.cpandl.com/ecp. If you are inside the corporate network, enter the internal URL, such as https://mailserver48/ecp.
The version of Exchange Admin Center you see depends on the version of Exchange running on the Mailbox server hosting your personal mailbox. Exchange 2010 runs version 14, and you can specify this version explicitly by appending ?ExchClientVer=14 to the internal or external URL.
Exchange 2013 runs version 15, and you can specify this version explicitly by appending ?ExchClientVer=15 to the internal or external URL. For example, if your external URL is https://mail.pocket-consultant.com, you could enter https://mail.pocket-consultant.com/ecp?ExchClientVer=15 as the URL.
If your browser displays a security alert stating there’s a problem with the site’s security certificate or that the connection is untrusted, proceed anyway. This alert is displayed because the browser does not trust the self-signed certificate that was automatically created when the Exchange server was installed.
With Internet Explorer, the error states “There’s a problem with this website’s security certificate.” Proceed by selecting the Continue To This Web Site (Not Recommended) link.
With Google Chrome, the error states “The site’s security certificate is not trusted.” Continue by clicking Proceed Anyway.
With Mozilla Firefox, the error states “This connection is untrusted.” Proceed by selecting I Understand The Risks and then selecting Add Exception. Finally, in the Add Security Exception dialog box, select Confirm Security Exception.
You’ll see the logon page for Exchange Admin Center. Enter your user name and password, and then tap or click Sign In.
Be sure to specify your user name in DOMAINusername format. The domain can either be the DNS domain, such as pocket-consultant.com, or the NetBIOS domain name, such as pocket-consulta. For example, the user AnneW could specify her logon name as pocket-consultant.comannew or pocket-consultaannew.
If you are logging on for the first time, select your preferred display language and time zone, and then tap or click Save.
After you log on to Exchange Admin Center, you’ll see the list view with manageable features listed in the feature pane (see Figure 3-1). When you select a feature in the feature pane, you’ll then see the related topics or “tabs” for that feature. The manageable items for a selected topic or tab are displayed in the main area of the browser window. For example, when you select Recipients in the feature pane, the topics or tabs that you can work with are: Mailboxes, Groups, Resources, Contacts, Shared, and Migration.
The navigation bar at the top of the window has several important options. You use the Enterprise and Office 365 options for cross-premises navigation. If there are notifications, tapping or clicking the Notification icon displays the notifications as shown in Figure 3-1. The User button shows the currently logged on user. Tapping or clicking the User button allows you to log out or sign in as another user.
Although ECP for Exchange 2010 would return only 500 recipients at a time, Exchange Admin Center doesn’t have this limitation since results are paged so that you can go through results one page at a time. Up to 20,000 recipients can be returned in the result set. When working with recipients, you can tap or click More to display options to:
Add or remove columns
Export data for the listed recipients to a .csv file
Perform advanced searches
If you customize the view by adding or removing columns, the settings are saved for the computer that you are using to access Exchange Admin Center. However, because the settings are saved as browser cookies, clearing the browser history will remove the custom settings.
When working with recipients, you typically can select multiple items and perform bulk editing as long as you select like items, such as mailbox users or mail-enabled contacts. Select multiple items using the Shift or Ctrl key and then use bulk editing options in the details pane to bulk edit the selected items.
Authenticating and proxying connections
When you access Exchange Admin Center in a browser, a lot is happening in the background that you don’t see. Although you access the application using a specific Client Access server in your organization, Client Access servers themselves only act as front-end proxies. They authenticate and proxy connections for Mailbox servers, and the Mailbox servers perform the actual back-end processing. To understand this process better, consider the following scenario:
You’re an administrator for Pocket-consultant.com, which has three Client Access servers (CAServer11, CAServer23, and CAServer42) and two Mailbox servers (MailServer18 and MailServer26). Your mailbox is located on MailServer26. When you log on to Exchange Admin Center using https://casserver23.pocket-consultant.com/ecp as the access URL, CAServer23 authenticates your request and proxies the connection to MailServer26. Any administration tasks you perform are processed on MailServer26 and the results are passed back to you via CAServer23.
As shown in Figure 3-2, you can examine the configuration settings for Exchange Admin Center and other applications using Internet Information Services (IIS) Manager. The Client Access server to which you connect processes your remote actions via the ECP application running on the default website. The physical directory for this application is %ExchangeInstallPath%ClientAccessEcp. This application runs in the context of an application pool named MSExchangeECPAppPool. In the %ExchangeInstallPath%ClientAccessEcp directory on your server, you’ll find a web.config file that defines the settings for the ECP application.
The Mailbox server where your mailbox resides performs its tasks and processing via the ECP application running on the Exchange Back End website. The physical directory for this application is %ExchangeInstallPath%ClientAccessEcp. This application runs in the context of an application pool named MSExchangeECPAppPool. In the %ExchangeInstallPath%ClientAccessEcp directory on your server, you’ll find a web.config file that defines the settings for the ECP application.
Because the Client Access role and the Mailbox role can be installed on the same server, the Client Access server to which you connect and the Mailbox server where your mailbox resides can actually be the same physical server. In this case, the proxying between front-end and back-end services uses the same technique but involves only a single server.
Working with Exchange Server certificates
When you install an Exchange server, the setup process creates several self-signed security certificates that are used for authentication. The default certificates available depend on whether the server has the Mailbox Server role, the Client Access Server role, or both installed and can include:
Microsoft Exchange. A self-signed certificate used by IMAP, POP, IIS, and SMTP. If Autodiscover is configured, this certificate is also used for Autodiscover. This is the primary certificate used by Exchange.
Microsoft Server Auth Certificate. A self-signed certificate for authenticating SMTP connections.
Exchange Delegation Federation. A self-signed certificate used when federated sharing is configured in the Exchange organization.
WMSVC. A self-signed certificate used by the Windows Management service.
As Figure 3-3 shows, you can view these certificates in Exchange Admin Center by selecting Servers in the feature pane and then selecting Certificates. Because the default certificates are not issued by a trusted authority, you see a related error message whenever you use HTTPS to access services hosted by your Client Access servers, including Exchange Admin Center, the PowerShell application, and Microsoft Outlook Web App.
The best way to eliminate this error message is to install a certificate from a trusted authority on your Client Access servers. Web browsers should already be configured to trust certificates issued by your organization’s certification authority (CA) or by a trusted third-party authority. Typically, browsers need additional configuration only when you use your own CA with non-domain-joined machines.
The services a certificate can be used with include Internet Message Access Protocol (IMAP), Post Office Protocol (POP), SMTP, Internet Information Services (IIS), and Unified Messaging (UM). The default self-signed certificates are assigned services automatically during setup based on the roles installed on the Exchange server.
When you work with certificates, it’s critical that you ensure the certificate is used for the right subject name and alternative names. As an example, the Microsoft Exchange certificate created by default has the Subject set as cn=ServerName, where ServerName is the name of the server, such as cn=MailServer21, and the Subject Alternative Names is set as DNS Name=ServerName, DNS NAME=FullyQualifiedServerName, and DNS Name=DomainName. If Autodiscover is configured, there’s also a Subject Alternative Name entry for DNS Name=Autodiscover.DomainName. For example, MailServer21 in the Pocket-consultant.com domain means the subject name is set as:
cn=MailServer21
and the Subject Alternative Name entries typically are:
DNS Name = MailServer21 DNS Name = MailServer21.pocket-consultant.com DNS Name = pocket-consultant.com DNS Name = Autodiscover.pocket-consultant.com
Real World
I caution against using Exchange Admin Center and Exchange Management Shell to work with Exchange certificates. You may prefer instead to access Exchange directly using the technique discussed in “Bypassing Exchange Admin Center and troubleshooting” later in this chapter. Anyone who has experienced problems after remotely managing Exchange certificates may agree—and I also have experienced related issues firsthand on multiple occasions. Specifically, if you modify certificates using either tool, you might find that Outlook Web App (OWA) and Exchange Admin Center are inaccessible as a result of a required SSL certificate becoming corrupted or being invalidated. If this happens, you will need to access Exchange directly and re-create the required certificate or certificates.
One way to safeguard yourself against this problem is to create copies of the original certificates using the Certificates snap-in. When you add this snap-in to a Microsoft Management Console, specify that you want to manage certificates for a computer account. You’ll then find the certificates under the Personal node. Export each certificate in turn using the Certificate Export Wizard. To start this wizard, press and hold or right-click a certificate, select All Tasks, and then select Export.
If your organization has a CA, have your security administrator issue a certificate. Generate the certificate by completing the following steps.
In a web browser, open Certificate Services by entering the appropriate URL, such as https://CertServer03/certsrv.
Specify that you want to create a new request and then choose the advanced creation option.
Submit a certificate request by using a base 64 encoded PKS #7 or PKS #12 file.
Once the certificate request file is generated, open the file in a text editor.
While you are working with Certificate Services in your browser, access the request. Copy the contents of the certificate request file and paste them into the request.
Select web server as the server type, and leave all other attributes blank.
Save the certificate.
After you create the certificate, you must make it available on the designated Exchange server. To do this, access the Exchange server and then import the certificate using Import-ExchangeCertificate. Next, use Enable-ExchangeCertificate to enable the certificate for specific Exchange services.
If you can purchase a certificate from a trusted third-party authority, you also must make the certificate available on the designated Exchange server. To do this, access the Exchange server and then import the certificate using Import-Exchange-Certificate. Next, use Enable-ExchangeCertificate to enable the certificate for specific Exchange services. Finally, ensure that the new certificate is in use and test web services by using Test-OutlookWebServices as shown in the following example:
test-outlookwebservices | fl
By default Test-OutlookWebServices verifies the Availability service, Autodiscover, Offline Address Book, and Exchange Web Services. You can test Outlook client connectivity and Outlook Anywhere using Test-OutlookConnectivity. You can test connectivity to the Outlook Web App and ECP virtual directories using Test-OwaConnectivity and Test-EcpConnectivity, respectively. However, before you can use any of the Test cmdlets, you must create a test account by running the ScriptsNew-TestCasConnectivityUser.ps1 script. You’ll find this script in the %ExchangeInstallPath%, which by default is C:Program FilesMicrosoftExchange ServerV15. The password you set for the test account is temporary and will be automatically changed every seven days.
Once you’ve imported and enabled the certificate, you can then view the certificate in Exchange Admin Center or by using Get-ExchangeCertificate to confirm it is configured as expected. You’ll want to ensure the status is valid, the expiration date is appropriate, the subject name is correct, the subject alternative names are correct, and that the assigned services are appropriate.
Configuring Exchange Admin Center
You can configure Exchange Admin Center for single-server and multiserver environments. In a single-server environment, you use one Client Access server for all of your remote management needs. In a multiple-server environment, you can instruct administrators to use different URLs to access different Client Access servers, or you can use Client Access arrays with multiple, load-balanced servers and give all administrators the same access URL.
Real World
If you have multiple Client Access servers in the same Active Directory site, you put them all in the same single CAS array, and then you point to the CAS array. Note that the load balancing performed by the array is automatically for RPC Client Access only. You need to use some other means to load balance the HTTPS requests against the array.
Note
You can use Exchange Admin Center 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 the IP addresses of your Client Access servers. If Secure Sockets Layer (SSL) is enabled and you want to use SSL exclusively, you only need port 443, and you don’t need to open port 80.
You can manage the Exchange Admin Center application using Internet Information Services (IIS) Manager or Exchange Management Shell. The related commands for Exchange Management Shell are as follows:
Get-ECPVirtualDirectory. Displays information about the ECP application running on the Web server providing services for Exchange. By default only front-end virtual directories are listed. Add -ShowMailboxVirtualDirectories to also display the back-end virtual directories.
Get-ECPVirtualDirectory [-Identity AppName] [-ADPropertiesOnly <$true | $false>] [-ShowMailboxVirtualDirectories <$true | $false>] [-DomainController DomainControllerName] Get-ECPVirtualDirectory -Server ExchangeServerName [-ADPropertiesOnly <$true | $false>] [-ShowMailboxVirtualDirectories <$true | $false>] [-DomainController DomainControllerName]
New-ECPVirtualDirectory. Creates a new ECP application running on the Web server providing services for Exchange. You should use this command only for troubleshooting scenarios where you are required to remove and re-create the ECP virtual directory.
New-ECPVirtualDirectory [-AppPoolId AppPoolName] [-DomainController DomainControllerName] [-ExternalUrl URL] [-InternalUrl URL] [-WebSiteName SiteName]
Remove-ECPVirtualDirectory. Use the Remove-ECPVirtualDirectory cmdlet to remove a specified ECP application providing services for Exchange.
Remove-ECPVirtualDirectory -Identity AppName [-DomainController DomainControllerName]
Set-ECPVirtualDirectory. Modifies the configuration settings for a specified ECP application providing services for Exchange. Set -AdminEnabled to $false to turn off Internet access to the Exchange Admin Center.
Set-ECPVirtualDirectory -Identity AppName [-AdminEnabled <$true | $false>] [-BasicAuthentication <$true | $false>] [-DomainController DomainControllerName] [-ExternalAuthenticationMethods Methods] [-DigestAuthentication <$true | $false>] [-FormsAuthentication <$true | $false>] [-ExternalUrl URL] [-GzipLevel <Off | Low | High | Error>] [-InternalUrl URL] [-LiveIdAuthentication <$true | $false>] [-WindowsAuthentication <$true | $false>]
Test-ECPConnectivity. Displays information about the ECP application running on the Web server providing services for Exchange.
Test-ECPConnectivity [-ClientAccessServer ServerName] [-MailboxServer ServerName] [-DomainController DomainControllerName] [-RTSEndPoint EndPointID] [-TestType <Internal | External>] [-MonitoringContext <$true | $false>] [-ResetTestAccountCredentials <$true | $false>] [-Timeout NumSeconds] [-TrustAnySSLCertificate <$true | $false>] [-VirtualDirectoryName DirectoryName]
At the Exchange Management Shell prompt, you can confirm the location of the Exchange Admin Center application by typing get-ecpvirtualdirectory.
Get-ECPVirtualDirectory lists the name of the application, the associated website, and the server on which the application is running, as shown in the following example:
Name Server ------- ------- ecp (Default Web Site) MailServer18
In this example, a standard configuration is being used, on which the application named ECP is running on the Default Web Site on MailServer18. You can use Set-ECPVirtualDirectory to specify the internal and external URL to use as well as the permitted authentication types. Authentication types you can enable or disable include basic authentication, Windows authentication, and Live ID basic authentication. You can use New-ECPVirtualDirectory to create or re-create an ECP application on a Web server providing services for Exchange and Remove-ECPVirtualDirectory to remove an ECP application. You can verify that Exchange Admin Center is working properly using Test-ECPConnectivity.
The PowerShell application has a similar set of commands. In Exchange Management Shell, the related commands are New-PowerShellVirtualDirectory, Get-PowerShellVirtualDirectory, Set-PowerShellVirtualDirectory, and Test-PowerShellConnectivity. If you enter Get-PowerShellVirtualDirectory | Format-List, you’ll get configuration details for each Client Access server in the Exchange organization. You can use SetPowerShellVirtualDirectory to enable or disable authentication mechanisms, including basic authentication, certificate authentication, Live ID basic authentication, Live ID NTLM negotiate authentication, and Windows authentication. You can also specify the internal and external URLs for the PowerShell virtual directory on a per-server basis. By default, servers have only internal URLs for PowerShell. For troubleshooting issues related to the PowerShell virtual directory, enter Test-PowerShellConnectivity followed by the URL to test, such as https://mailer1.cpandl.com/powershell.
You’ll also find commands for working with virtual directories related to:
Outlook Web Access, including New-OwaVirtualDirectory, Get-OwaVirtualDirectory, Set-OwaVirtualDirectory, and Remove-OwaVirtualDirectory
Offline Address Books, including New-OabVirtualDirectory, Get-OabVirtualDirectory, Set-OabVirtualDirectory, and Remove-OabVirtualDirectory
Autodiscover, including New-AutodiscoverVirtualDirectory, Get-AutodiscoverVirtualDirectory, Set-AutodiscoverVirtualDirectory, and Remove-AutodiscoverVirtualDirectory
Keep in mind that there are separate but interconnected virtual directories on both Client Access servers and Mailbox servers. Typically, front-end virtual directories are used for authentication and proxying while back-end virtual directories are used for actual processing. Although the front-end and back-end virtual directories have different components and configurations, the Exchange cmdlets for creating these virtual directories are designed to configure the appropriate settings and components for either front-end or back-end use as appropriate.
When an Exchange server has both the Client Access server and the Mailbox server role, you should specify explicitly whether you want to work with the front-end or back-end components. You do this by specifying the related website name. The Default Web Site is used by the front-end components and the Exchange Back End website is used by back-end components.
Bypassing Exchange Admin Center and troubleshooting
Exchange makes extensive use of IIS. Client Access servers use IIS for front-end services, such as authentication and proxying, while Mailbox servers use IIS for back-end processing. On Client Access servers, front-end apps for Outlook Web App, ECP, PowerShell, OAB, and Autodiscover apps are configured on the Default Web Site. On Mailbox servers, back-end apps for Outlook Web App, ECP, PowerShell, OAB, and Autodiscover are configured on the Exchange Back End website.
Understanding remote execution in Exchange Admin Center
When you access Outlook Web App in a web browser, you are performing remote operations via the PowerShell application running on the Web server providing Exchange services whether you are logged on locally to an Exchange server or working remotely. The same is true for ECP, but the process is a little more complex, as shown in the following high-level view of the login and workflow process:
Generally, Outlook Web App handles the initial login for ECP. Thus, when you access ECP using a URL such as https://mailserver17/ecp, the browser actually is redirected to Outlook Web App with a URL such as https://mailserver17/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fmailserver17%2fecp%2f.
Once you log on to Exchange, you are connected to the designated Client Access server using the ECP app running on the Default Web Site.
ECP performs authentication checks that validate your access to the Exchange 2013 server and determine the Exchange role groups and roles your account is a member of. You must be a member of at least one management role.
ECP creates a remote session with the Exchange 2013 server. A remote session is a runspace that establishes a common working environment for executing commands on remote computers.
The ECP app on the Client Access server acts as proxy for the ECP app on the Mailbox server. By default, you are connected to the Mailbox server on which your user mailbox resides.
As you perform tasks, these tasks are executed via the PowerShell app, which also has front-end and back-end components.
Important
Every step of the login and workflow process relies on properly configured SSL certificates. HTTPS uses SSL certificates to establish and encrypt connections. SSL certificates are also used to initialize and validate remote sessions. Although you could disable the requirement for HTTPS and allow HTTP to be used for connections, the remote sessions themselves would still rely on properly configured SSL certificates.
Thus, many interconnected components must be functioning correctly for you to connect to and work with Exchange Server.
Bypassing Exchange Admin Center and Exchange Management Shell
As discussed in Chapter 4 the Exchange Management Shell uses remote sessions that run via the PowerShell application running on IIS. Because of this, you often need a way to work directly with Exchange Server, especially when you are trying to diagnose and resolve problems. Intuitively, you might think that you should do this in the same way you establish a remote session with Exchange Online. For example, if you want to connect to MailServer18, you might want to use the following code:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mailserver18/powershell/ -Authentication Basic -Credential [email protected] -AllowRedirection Import-PSSession $Session
However, if there are any configuration problems, including issues with SSL certificates, you won’t be able to connect to or work with Exchange Server in this way. Instead, you’ll have to bypass the web-based management interfaces and connect directly to an Exchange server using the following technique:
Log on to the Client Access server or Mailbox server you want to work with—either at the console or using a remote desktop connection.
Open an administrative PowerShell window by pressing and holding or right-clicking Windows PowerShell and then tapping or clicking Run As Administrator.
Import all Exchange-related snapins for Windows PowerShell by entering Add-PSSnapin *exchange*. You’ll then be able to work directly with Exchange and any related cmdlets.
Because Exchange has a two-tier architecture, you’ll often need to perform troubleshooting tasks on both the front-end Client Access servers and back-end Mailbox servers. Rather than log on locally to each server, you may want to work remotely. You can invoke commands, establish direct remote sessions, or execute commands remotely using the -ComputerName parameter available with certain cmdlets. (For more information, see Chapter 4, “Using Sessions, Jobs, and Remoting” in Windows PowerShell 2.0 Administrator’s Pocket Consultant [Microsoft Press, 2009]).
To invoke commands on remote servers or establish a direct remote session, use the following technique:
Log on to any workstation or server where you’ve installed the Exchange management tools. (Doing so ensures the Exchange related snap-ins are available.)
Open an administrative PowerShell window by pressing and holding or right-clicking Windows PowerShell, and then tapping or clicking Run As Administrator.
Import all Exchange-related snapins for Windows PowerShell by entering Add-PSSnapin *exchange*.
Either invoke commands on the remote Exchange server or establish a remote session with the remote Exchange server. In your remote sessions, be sure to connect directly, as shown in the following example:
$Session = New-PSSession -computername mailserver18 -Credential pocket-consultawilliams Import-PSSession $Session
Important
When you work with Exchange in this way, you establish connections via the Windows Remote Management (WinRM) service. On an Exchange server, WinRM and related services are set up automatically. On your management computer, you need to install the required components and configure WinRM as discussed previously in “Using Exchange Management Shell” in Chapter 1. See also “Customizing remote management services” later in this chapter.
Troubleshooting Outlook Web App, ECP, PowerShell, and More
Sometimes users and administrators see a blank page or an error when they try to log on to Outlook Web App or ECP. This problem and other connection issues, such as those related to OAB, Autodiscover, and PowerShell, can occur because of a wide variety of configuration issues, including:
Invalid or missing TCP/IP settings
Corrupted or improperly configured virtual directories
Missing, expired, invalid, or improperly configured SSL certificates
However, before you look at specific issues, ensure required services are running as discussed in “Checking required services” later in this chapter. Be sure to examine the running services on both the front-end and back-end servers.
Typically, the next logical step is to validate the TCP/IP settings of the front-end and back-end servers. Not only do front-end and back-end servers need to communicate with each other, they also need to communicate with domain controllers.
If Exchange Server can’t communicate properly with a domain controller, you may see an error similar to the following when you open Exchange Admin Center or Exchange Management Shell:
The LDAP server is unavailable. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [LdapException: The LDAP server is unavailable.] System.DirectoryServices.Protocols.LdapConnection.Connect() +160015 System.DirectoryServices.Protocols.LdapConnection.BindHelper (NetworkCredential newCredential, Boolean needSetCredential) +264 Microsoft.Exchange.Data.Directory.PooledLdapConnection.BindWithRetry (Int32 maxRetries) +702
Resolve the problem by doing the following:
Ensure the server has the proper TCP/IP settings and is connected to the network.
Ensure a domain controller is available for the server to communicate with.
Users or administrators may see a blank page when they try to log on to Outlook Web App or ECP as a result of a configuration or certificate problem. If you’ve determined that required services are running and that the TCP/IP settings are correct, next try to isolate and identify the specific issue.
Try to log on to Outlook Web App or ECP in a browser. Sometimes when you log on to Outlook Web App or ECP, you’ll see a runtime error that indicates an improperly configured virtual directory or an application error due to misconfiguration in IIS (see Figure 3-4). Other times, the browser window may simply be empty or blank as mentioned previously.
For deeper troubleshooting, log on to the Client Access server where the problem is occurring and open Exchange Management Shell. Next, try to log on to the Mailbox server hosting the mailbox for the users or administrators experiencing the problem and open Exchange Management Shell. If there’s a problem with SSL certificates rather than virtual directory configuration, you’ll see an error similar to the following:
New-PSSession : [mailserver17] Connecting to remote server mailserver17
failed with the following error message : The server certificate on the
destination computer (mailserver17:443) has the following errors:
The SSL certificate is signed by an unknown certificate authority. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri ht …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError
(System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession],
PSRemotingTransportException
+ FullyQualifiedErrorId : 12175,PSSessionOpenFailedIf there’s a problem with virtual directory configuration, you may see another type of error, such as:
New-PSSession : [mailserver17.pocket-consultant.com] Processing data from
remote server mailserver17.pocket-consultant.com failed with the following
error message: The WinRM Shell client cannot process the request. The shell
handle passed to the WSMan Shell function is not valid. The shell handle is
valid only when WSManCreateShell function completes successfully. Change
the request including a valid shell handle and try again. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName
Microsoft.Excha … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError:
(System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession],
PSRemotingTransportException
+ FullyQualifiedErrorId : -2144108212,PSSessionOpenFailedTo help diagnose the problem, you can test services using Test-OutlookWebServices. By default, Test-OutlookWebServices verifies the Availability service, Outlook Anywhere, Offline Address Book, and Unified Messaging. You can test Outlook Web App, ECP, and PowerShell using Test-OwaConnectivity, Test-EcpConnectivity, and Test-PowerShellConnectivity respectively.
Resolving SSL certificate issues
To resolve a certificate issue, you’ll need to restore or re-create the primary SSL certificate on the Client Access server, the Mailbox server, or both. By default, the self-signed certificate named Microsoft Exchange is the certificate used for authentication and encrypting communications whenever you use Outlook Web App, ECP, or the management tools to work with Exchange. If you backed up the certificates on the server or exported the certificates as discussed previously in this chapter in “Working with Exchange Server certificates,” you can restore the original certificate to restore services.
If you don’t have a backup or an export of the primary SSL certificate, you’ll need to re-create the certificate. You can create a new self-signed certificate using New-ExchangeCertificate. The following example shows how to configure services, the subject name, and subject alternative names for MailServer21 in the Pocket-Consultant.com domain:
New-ExchangeCertificate -SubjectName "cn=MailServer21" -DomainName pocket-consultant.com -IncludeServerFQDN -Services IIS, IMAP, POP, SMTP
Important
If there’s a problem preventing you from using Exchange Admin Center and Exchange Management Shell, you’ll need to bypass the web-based management interfaces and connect directly to Exchange Server using the technique discussed earlier in the chapter.
With certificates issued by a local CA or a third-party CA, you can use the original certificate file. Import the certificate using Import-ExchangeCertificate and then use Enable-ExchangeCertificate to enable the certificate for IIS, IMAP, POP, and SMTP services. You can ensure that the certificate is in use and test services as discussed previously.
Resolving Outlook Web App, ECP, or other virtual directory issues
To resolve a virtual directory issue, you can remove and then re-create the virtual directory. You won’t always know whether the problem exists in the front-end configuration, the back-end configuration, or both, so you may need to remove and re-create the virtual directory on the related Client Access server and the related Mailbox server. I recommend removing and re-creating the front-end virtual directory first and then checking to see if this resolves the problem before removing and re-creating the back-end virtual directory.
As an example, if you’ve determined the Outlook Web App virtual directory is misconfigured, you can remove it using Remove-OwaVirtualDirectory and then re-create it using New-OwaVirtualDirectory. For example, the following commands remove and then re-create the Outlook Web App virtual directory from the Default Web Site on MailServer17:
remove-owavirtualdirectory -identity "mailserver17owa (Default Web Site)" new-owavirtualdirectory -server mailserver17 -websitename "Default Web Site"
Important
Keep in mind that if there’s a problem preventing you from using Exchange Admin Center and Exchange Management Shell, you’ll need to bypass the web-based management interfaces and connect directly to Exchange Server using the technique discussed earlier in the chapter. You’ll then be able to remove the virtual directory and then re-create it. When you are logged on to the server you are configuring, you don’t need to use the -Server parameter with New-OwaVirtualDirectory.
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 Outlook Web App and ECP, you must use the commands Set-OwaVirtualDirectory and Set-EcpVirtualDirectory to modify the default authentication settings. The following example enables Windows authentication and disables basic and forms authentication:
set-owavirtualdirectory -identity "mailserver17owa (Default Web Site)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false
After you re-create 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 then test the service using Test-OwaConnectivity, or you can try to log on to Outlook Web App. If this doesn’t resolve the problem, you can remove, re-create, and configure the Outlook Web App virtual directory on the back-end server, as shown in this example:
remove-owavirtualdirectory -identity "mailserver21owa (Exchange Back End)" new-owavirtualdirectory -server mailserver21 -websitename "Exchange Back End" set-owavirtualdirectory -identity "mailserver21owa (Exchange Back End)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false
Complete the process by restarting IIS services and then check to ensure the problem is resolved. If the problem isn’t resolved, look to related services. For example, remote PowerShell must be properly configured for Outlook Web App and ECP to work. If you suspect the PowerShell virtual directory is misconfigured, you can remove and re-create it as well.
Validating Exchange Server licensing
With Exchange Server 2013, you do not enter a product key during initial setup. Instead, you provide the product key after installation using Exchange Admin Center. Until you enter a product key, Exchange Server 2013 runs in trial mode.
The product key you provide determines which edition is established on an Exchange server. You can use a valid product key to go from a trial edition to Standard Edition or Enterprise Edition of Exchange Server 2013 without having to reinstall the program.
To determine the established edition and licensing for an Exchange server complete the following steps:
In Exchange Admin Center, select Servers in the feature pane.
In the main pane, select the server you want to work with.
Look in the details pane to see the server roles, version, established edition, and license details.
To enter a product key complete the following steps:
In Exchange Admin Center, select Servers in the feature pane.
In the main pane, select the server you want to work with.
In the details pane, select Enter Product Key. This opens the Exchange Server dialog box.
Enter the product key for the Exchange Server 2013 edition you want to establish, either Standard or Enterprise, and then tap or click Save.
You should see a dialog box stating the product key has been validated and the product ID has been created. If there’s a problem with the product key, you’ll see an invalid key warning. Tap or click OK. Re-enter or correct the product key and then tap or click Save again. Keep the following in mind:
Whenever you set or change the product key on a Mailbox server, you must restart the Microsoft Exchange Information Store service to apply the change.
While you can upgrade from Standard to Enterprise edition simply by entering a key for Enterprise edition, you cannot use product keys to downgrade editions. To downgrade editions, you must uninstall Exchange Server and then reinstall the older version.
Using Exchange Management Shell, you can enter a server’s product key using the Set-ExchangeServer cmdlet. Setting the Exchange product key syntax and usage shows the syntax and usage. For the identity parameter, use the server’s name, such as MailServer25.
Tip
By using a valid product key, you can change from the Standard to the Enterprise edition. You also can relicense an Exchange server by entering a new product key for the installed edition, which is useful if you accidentally used the same product key on multiple servers and want to correct the mistake. The best way to do this is to enter the product key using the Set-ExchangeServer cmdlet.
Using and managing Exchange services
Each Exchange server in the organization relies on a set of services for routing messages, processing transactions, replicating data, and much more. Table 1-1 in Chapter 1 lists these services.
Tip
Of all the Exchange services, the one service that relies on having a network connection at startup is the Microsoft Exchange Information Store service. If you start an Exchange server and the server doesn’t have a network connection, the Microsoft Exchange Information Store service might fail to start. As a result, you might have to manually start the service. Sometimes, you’ll find the service has a Stopping state. In this case, you have to wait until the server completely stops the service before you restart it.
Working with Exchange services
To manage Exchange services, use the Services node in the Computer Management console, which you start by completing the following steps:
Type compmgmt in the Apps Search box, and then select Computer Management. Or, on the Tools menu in Server Manager, select Computer Management.
To connect to a remote Exchange server, press and hold or right-click the Computer Management entry in the console tree, and then select Connect To Another Computer from the shortcut menu. You can now choose the Exchange server for which you want to manage services.
Expand the Services And Applications node, and then select Services.
Figure 3-5 shows the Services view in the Computer Management console. The key fields of this window are as follows:
Name. The name of the service.
Description. A short description of the service and its purpose.
Status. The status of the service as started, paused, or stopped. (Stopped is indicated by a blank entry.)
Startup Type. The startup setting for the service.
Log On As. The account the service logs on as. The default, in most cases, is the local system account.
Checking required services
You can use Test-ServiceHealth to determine whether all Windows services that Exchange requires are running. As shown in the following example and sample output, the command output lists required services that are running as well as required services that aren’t running for each configured Exchange role:
test-servicehealth
Role : Mailbox Server Role
RequiredServicesRunning : True
ServicesRunning : {IISAdmin, MSExchangeADTopology,
MSExchangeDelivery, MSExchangeIS, MSExchangeMailboxAssistants,
MSExchangeRepl, MSExchangeRPC, MSExchangeServiceHost,
MSExchangeSubmission, MSExchangeThrottling, MSExchangeTransportLogSearch,
W3Svc, WinRM}
ServicesNotRunning : {}
Role : Client Access Server Role
RequiredServicesRunning : True
ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeIMAP4,
MSExchangeMailboxReplication, MSExchangePOP3, MSExchangeRPC,
MSExchangeServiceHost, W3Svc, WinRM}
ServicesNotRunning : {}
Role : Unified Messaging Server Role
RequiredServicesRunning : True
ServicesRunning : {IISAdmin, MSExchangeADTopology,
MSExchangeServiceHost, MSExchangeUM, W3Svc, WinRM}
ServicesNotRunning : {}
Role : Hub Transport Server Role
RequiredServicesRunning : True
ServicesRunning : {IISAdmin, MSExchangeADTopology,
MSExchangeEdgeSync, MSExchangeServiceHost,
MSExchangeTransport, MSExchangeTransportLogSearch, W3Svc, WinRM}
ServicesNotRunning : {}Starting, stopping, and pausing Exchange Server services
As an administrator, you’ll often have to start, stop, or pause Exchange services. You manage Exchange services through the Computer Management console or through the Services console.
To start, stop, or pause services in the Computer Management console, follow these steps:
If necessary, connect to the remote Exchange server for which you want to manage services, as discussed earlier in this section.
Expand the Services And Applications node, and then select Services.
Press and hold or right-click the service you want to manipulate, and then select Start, Stop, or Pause, as appropriate. You can also choose Restart to have Windows stop and then start the service after a brief pause. Also, if you pause a service, use the Resume option to resume normal operation.
Tip
When services that are set to start automatically fail, the status is listed as blank, and you usually receive notification in a pop-up window. Service failures can also be logged to the system’s event logs. You can configure recovery actions to handle service failure automatically. For example, you can have Windows attempt to restart the service for you. See the section of this chapter titled “Configuring service recovery” for details.
Configuring service startup
Essential Exchange services are configured to start automatically and normally shouldn’t be configured with another startup option. That said, if you’re troubleshooting a problem, you might want a service to start manually or you might want to temporarily disable a service.
Configure service startup by completing the following steps:
In the Computer Management console, connect to the Exchange server for which you want to manage services.
Expand the Services And Applications node, and then select Services.
Press and hold or right-click the service you want to configure, and then select Properties.
On the General tab, use the Startup Type drop-down list to choose a startup option. Select Automatic to start a service when the computer starts. Select Manual to allow services to be started manually. Select Disabled to disable the service. Tap or click OK.
Configuring service recovery
You can configure Windows services to take specific actions when a service fails. For example, you can attempt to restart the service or reboot the server. To configure recovery options for a service, follow these steps:
In the Computer Management console, connect to the computer for which you want to manage services.
Expand the Services And Applications node, and then select Services.
Press and hold or right-click the service you want to configure, and then select Properties.
On the Recovery tab, you can configure recovery options for the first, second, and subsequent recovery attempts. The available options are as follows:
Take No Action
Restart The Service
Run A Program
Restart The Computer
Configure other options based on your previously selected recovery options. If you elected to restart the service, you need to specify the restart delay. After stopping the service, Windows Server waits for the specified delay period before trying to start the service. In most cases, a delay of one to two minutes should be sufficient. Tap or click OK.
When you configure recovery options for critical services, you might try to restart the service on the first and second attempts and then reboot the server on the third attempt. If you notice that a service keeps failing, do some troubleshooting to diagnose and resolve the underlying issue causing the failure.
Customizing Remote Management services
The Exchange management tools use the Microsoft .NET Framework, Windows Remote Management (WinRM), and Windows PowerShell for remote management. WinRM is implemented in the Windows Remote Management service, which is also referred to as the WS-Management Service or simply the Management Service. To remotely manage Exchange, your management computer must run this service and be configured to use the transports, ports, and authentication methods that your Exchange servers use. The Exchange server you want to connect to must also run this service. If this service isn’t running on your management computer and on the server, remote connections will fail. For remote management, you normally connect to the PowerShell virtual directory configured in IIS on a Client Access server.
By default, the Management Service connects to and listens on TCP port 80 for HTTP connections and on TCP port 443 for secure HTTP connections. Because firewalls and proxy servers might affect your ability to connect to remote locations over these ports, talk with your company’s network or security administrator to determine what steps need to be taken to allow administration over these ports. Typically, the network/security administrator will have to open these TCP ports to allow remote communication between your computer or network and the remote server or network.
The Management Service is preconfigured to share ports with IIS when it runs on the same computer, but it does not depend on IIS. To support remote management, you need to install basic authentication and Windows authentication for IIS on your Exchange servers. These authentication techniques are used when you work remotely.
When you are working with an elevated, administrator command prompt, you can use the WinRM command-line utility to view and manage the remote management configuration. Type winrm get winrm/config to display detailed information about the remote management configuration. As Sample configuration for WinRM shows, this lists the configuration details for every aspect of WinRM.
If you examine the listing, you’ll notice there is a hierarchy of information. The base of this hierarchy, the Config level, is referenced with the path winrm/config. Then there are sublevels for client, service, and WinRS, referenced as winrm/config/client, winrm/config/service, and winrm/config/winrs, respectively. You can change the value of most configuration parameters by using the following command:
winrm set ConfigPath @{ParameterName="Value"}
where ConfigPath is the configuration path, ParameterName is the name of the parameter you want to work with, and Value sets the value for the parameter, such as:
winrm set winrm/config/winrs @{MaxShellsPerUser="4"}In this example, the MaxShellsPerUser parameter is set under WinRM/Config/WinRS. Keep in mind that some parameters are read-only and cannot be set in this way.
WinRM requires at least one listener to indicate the transports and IP addresses on which management requests can be accepted. The transport must be HTTP, HTTPS, or both. With HTTP, messages can be encrypted only using NTLM or Kerberos encryption. With HTTPS, Secure Sockets Layer (SSL) is used for encryption. You can examine the configured listeners by typing winrm enumerate winrm/config/listener. As Sample configuration for listeners shows, this lists the configuration details for configured listeners.
By default, your computer is likely to be configured to listen on any IP address. If so, you won’t see any output. To limit WinRM to specific IP addresses, the computer’s local loopback address (127.0.01) and assigned IPv4 and IPv6 addresses can be explicitly configured for listening. You can configure a computer to listen for requests on HTTP on all configured IP addresses by typing:
winrm create winrm/config/listener?Address=*+Transport=HTTP
You can listen for requests on HTTPS on all IP addresses configured on the computer by typing:
winrm create winrm/config/listener?Address=*+Transport=HTTPS
In this case, the * indicates all configured IP addresses. Note that the CertificateThumbprint property must be empty for the SSL configuration to be shared with another service.
You can enable or disable a listener for a specific IP address by typing:
winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @{Enabled="true"}or
winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @{Enabled="false"}You can enable or disable basic authentication on the client by typing:
winrm set winrm/config/client/auth @{Basic="true"}or
winrm set winrm/config/client/auth @{Basic="false"}You can enable or disable Windows authentication using either NTLM or Kerberos (as appropriate) by typing:
winrm set winrm/config/client @{TrustedHosts="<local>"}or
winrm set winrm/config/client @{TrustedHosts=""}In addition to managing WinRM at the command line, you can manage the service by using Group Policy. Keep in mind that Group Policy settings might override any other settings you enter.