Saturday, May 31, 2014

Exchange 2013 (SP1) - Migration - Part 9 - Mailbox moves

Now we can move our mailboxes.

There are a number of options: EAC (Exchange Admin Center - GUI), EMS (Powershell cmdlets) and CSV file (with names of mailboxes to be migrated).

I'll illustrate the EAC and EMS options in the paragraphs that follow.


We manage the mailbox move from the Exchange 2013 server, EX13-1 in my case. We open the EAC and go to the "recipients" section, and then to the "migration" tab:

In the section below, we click on the plus sign "+" and select the "Move to a different database" option:

We then select the users to move:

Note: if we want to use a list in CSV format, we can navigate to the location of the file further down (not shown in the screenshot above).

We click on the plus sign (previous screenshot) to display the list of users:

Once highlighted, we can add the users we want with the "Add" button at the bottom of the list:

We'll then have something like this:

We then click "OK", then "Next", and proceed to the following screen:

We provide a name for the migration process, "Mailbox Move 1" in my case, and select either the primary mailbox, the archive mailbox, or both, and then the target database (and click "Next").

At this point, we have to designate a recipient for the report that will be sent. We can start the "batch" automatically (my choice) or manually later:

The status of the migration is summarized in the resulting page:

If we refresh the page a moment later, we should see the number 2 in the "Finalized" column (that was the case for me).


The PowerShell cmdlet for a mailbox move is quite concise. This is all we need:

New-MoveRequest -TargetDatabase EXDB-2

So, besides the New-MoveRequest cmdlet itself, we indicate the mailbox to be moved (designated here by the email address) and then the target database. We could place the "-identity" parameter just before the mailbox name but since it is "positional", this is not necessary.

Mailbox access after the move

Logging on as one of the users whose mailbox was moved, I was able to access the mailbox via OWA (Outlook Web App) without a problem...

On the other hand, access via Outlook (now the equivalent of Outlook Anywhere) was unsuccessful for one user.

I am prompted for credentials and informed that I need to restart Outlook:

Unfortunately, restarting Outlook changes nothing: I am still prompted for credentials and even after entering the same password that works with OWA, I cannot connect to Exchange.

In fact, Outlook does open but does not connect to Exchange. So I can see mail received before the migration but cannot interact with Exchange. If I hold down the Ctrl key and right-click on the Outlook icon (in task bar), the "Connection Status" indicates that Outlook is still trying to connect to EX1, the Exchange 2007 server (even though the mailbox has been moved):

I can open and close Outlook, and even restart the entire computer, but autodiscover seems unable to change the Exchange server it targets.

This only affected one migrated user.

I enabled some test mailboxes on the new Exchange 2013 server and these are accessible via Outlook and OWA.

Also, four other migrated users did not encounter the problem.

Furthermore, if I delete the entire profile (and therefore the Outlook profile) of the one migrated user on the Windows 7 client, they can access their mailbox via Outlook once again (in other words, once a new profile is created). This would also, presumably, be the case of a user that had never logged on to the client machine before the mailbox migration.


In conclusion, I was able to migrate the mailboxes from the Exchange 2007 server to the Exchange 2013 server. However, something, apparently in the Outlook profile, prevented one migrated user from accessing their mailbox via Outlook (unlike OWA which presented no problems).

I could not reproduce the problem with other users: four of them were able to access their mailbox without difficulty (although reopening Outlook was necessary - which is normal and expected).

Since I could not reproduce the problem, I am not sure if simply recreating the Outlook profile (rather than the entire user profile) would have resolved the problem.

Thursday, May 22, 2014

Exchange 2013 (SP1) - Migration - Part 8 - Mail flow

Send and Receive Connectors

We had already determined, in a previous post, that internal mail flow is functional. Users of my organization can send (and receive) mail to (and from) each other.

In fact, there are "implicit" connectors that manage mail flow that is internal to the organization. These connectors are not visible in the administrative interfaces and do not need to be configured.

Inbound and outbound mail flow (to and from the rest of the world) requires some additional configuration.

Send Connecter (outbound messages)

Outbound mail flow is the most simple. One or more "send connectors" regulate mail flow in this direction. Send connectors exist at the "organizational level" and are stored in the Active Directory configuration partition (with other Exchange related settings). In other words, send connectors are not "server-specific" and do not need to be recreated when a new server is added or in the context of a migration.

I thought I could simply send a message to an external recipient without any additional configuration. The message never arrived.

In fact, we do need to make one adjustment to the send connector: add the new server (in our case, the Exchange 2013 server) to the "source servers" attribute.

This is the procedure if we prefer the Exchange Admin Center:

In the image above, only the Exchange 2007 server (EX1) is present.

So we click on the plus sign "+" and add the Exchange 2013 server (EX13-1):

That leaves us with this:

Now I can send a test message to an external recipient.

So this single adjustment was all that was required in my environment. Other situations may be different. For example, if the firewall blocks outbound SMTP traffic except for messages sent from the existing mail server (the Exchange 2007 server, for example), another exception would have to be made for the new Exchange 2013 server.

Otherwise, if we prefer the EMS, we could use this cmdlet:

Set-SendConnector MYNET-SendConn-1 -SourceTransportServers EX13-1

However, we then loose the Exchange 2007 server (EX1):

Get-SendConnector | fl SourceTransportServers

SourceTransportServers : {EX13-1}

What happened?

The cmdlet above overwrites the existing settings and only includes the servers indicated.

If I want both servers, I have to indicate both, even if one is already indicated:

Set-SendConnector MYNET-SendConn-1 -SourceTransportServers EX13-1,EX1

Get-SendConnector | fl SourceTransportServers

SourceTransportServers : {EX13-1, ex1}

Receive Connector (inbound messages)

In previous versions of Exchange, the default Receive Connector permissions did not allow mail from anonymous senders (users from another organization, for example). It was necessary to check the appropriate box as shown below:

That is the view in the Exchange 2007 EMC. We can see these settings from the Exchange 2013 EAC as well (remember to designate the Exchange 2007 server - EX1 in my case):

Perhaps because this default setting complicated Exchange installations for less experienced administrators (I've seen it mentioned in more than one Technet forum discussion), Microsoft enabled the equivalent setting in Exchange 2013:

Yes, the equivalent connector in Exchange 2013 is called "Default Frontend (name of server)". There are more connectors in Exchange 2013 than in Exchange 2007. However, for a default installation, we do not have to know the specific details of each connector. In fact, we do not have anything to configure here (for a default installation, once again). The server will accept inbound mail from external sources as is, since "Anonymous users" is already checked:

As mentioned previously, I was able to send test messages between users in my organization even before configuring any send or receive connectors. Before sending to and from the Internet (using a Gmail or account, for example), I had to adjust settings on my firewall. In particular, I had to adjust IP addresses so mail traffic would be directed to the Exchange 2013 server (EX13-1) rather than the Exchange 2007 server (EX1). I will not provide details of those changes since they would be useless for anyone using a different type of firewall.

It might also be necessary to adjust external DNS settings, expecially if Exchange 2007 and 2013 coexist for a certain time. In my case, however, I will perform a rapid migration of all the mailboxes at once, without any coexistence between the two versions of Exchange. In that case, changing the DNS records so they point to the Exchange 2013 server should be enough. Otherwise, we would still change those records BUT ALSO add a so-called "legacy" entry for the Exchange 2007 server.

So, for internal DNS, we would have something like this:


- is the IP address of the Exchange 2013 server.

- is the IP address of the Exchange 2007 server.

The allows Exchange to proxy or redirect connections from the Exchange 2013 server to the Exchange 2007 server, notably for users whose mailbox is still located on the older server.

We would also adjust external DNS records (hosted by our ISP or a domain name registrar) but those entries would point to the external (Internet facing) IP address of our firewall.


So, in summary, we ensure mail flow in and out of the organization by configuring what follows:

  1. Send and Receive connectors (if they are not configured correctly by default).
  2. Firewall settings (1 to 1 NAT in particular).
  3. DNS records.

For testing, we can:

  1. Send a message TO an external email account (Gmail,
  2. Send a message FROM an external email account.

I have been able to do both consistently the last several days.

Friday, May 16, 2014

Exchange 2013 (SP1) - Migration - Part 7 - Outlook Anywhere

As mentioned in a previous post, Outlook Anywhere (RPC/HTTP) is the only access method for Outlook (legacy) clients with Exchange 2013. I specify "legacy" because Outlook 2013 can connect to Exchange 2013 with MAPI/HTTP.

Outlook Anywhere is installed (as a feature) and enabled by default with Exchange 2013 - unlike with Exchange 2007 and 2010.

We can verify that it is installed with the following cmdlet...


Note: look for the entry "RPC-over-HTTP-Proxy" and see if there is an "x" indicating that it is installed.

And verify that it is enabled with this cmdlet:

Get-ClientAccessServer EX13-1 | fl Name,OutlookAnywhereEnabled

Name                                : EX13-1
OutlookAnywhereEnabled : True

Note: change the name of the server as appropriate.

Next, we will configure Outlook Anywhere and the URL values in particular.

Note: as with the URLs for other virtual directories, we still need to adjust DNS records so clients will be directed to the Exchange 2013 server rather than the Exchange 2007 server. I will do this in a future blog post.

Here are some notable default settings for Outlook Anywhere. We can compare them with the modified settings we will configure in a moment:

Get-OutlookAnywhere -server EX13-1 | fl servername,*ssl*,*auth*,*hostname*

ServerName                              : EX13-1
SSLOffloading                           : True
ExternalClientsRequireSsl           : False
InternalClientsRequireSsl            : False
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods            : {Basic, Ntlm, Negotiate}
ExternalHostname                   :
InternalHostname                   : ex13-1.mynet.lan

Some remarks...

  • We will not use SSL offloading in my environment. This would entail the use of another device to encrypt and decrypt the SSL traffic (perhaps a specialized appliance).
  • We will require use of SSL for internal and external clients.
  • Authentication method will be NTLM for both internal and external clients.

This is the cmdlet that configures those (and some other) settings:

Set-OutlookAnywhere "EX13-1\Rpc (Default Web Site)" -ExternalHostname
-InternalHostname -ExternalClientAuthenticationMethod Ntlm
-ExternalClientsRequireSsl:$true -InternalClientAuthenticationMethod Ntlm
-InternalClientsRequireSsl:$true -IISAuthenticationMethods Ntlm -SSLOffloading:$false

This leaves us with the configuration as follows:

Get-OutlookAnywhere -server EX13-1 | fl servername,*ssl*,*auth*,*hostname*

ServerName                              : EX13-1
SSLOffloading                          : False
ExternalClientsRequireSsl          : True
InternalClientsRequireSsl           : True
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods           : {Ntlm}
ExternalHostname                   :
InternalHostname                   :

We can configure some of these settings (but not all) in the Exchange Admin Center: Server | Outlook Anywhere:

After executing the command above, we have these settings:

OK, but does this work?

It worked for me.

I was able to logon alternately as two test users and send internal messages back and forth. There were no errors or prompts about certificates. Please note that these test users were created on the Exchange 2013 server and both have mailboxes on this server. Migration of mailboxes on the Exchange 2007 server has yet to take place.

My Outlook version is 2010 SP2. Client settings for Outlook Anywhere were the default settings. No changes were made. For reference, here are those settings:

Note: I make the assumption that the reader knows where to find these settings in Outlook 2010. If not, one can find many articles conducting an online search with these terms:

outlook anywhere connect to microsoft exchange using http

Saturday, May 10, 2014

Exchange 2013 (SP1) - Migration - Part 6 - URL configuration for virtual directories

We'll now configure the URLs (or URIs) for the Client Access role.

We can do this with the GUI or at the command line. I'll have to become more familiar with the Exchange 2013 Exchange Admin Center (EAC) sooner or later but for now, I'll just use the EMS (which is similar to what it was in Exchange 2007 and 2010).


I'll start with autodiscover.

Here's a revealation: there is no need to configure the internal - or even external URL.

Why not? Because Exchange does not use them.

Busting The Set-AutodiscoverVirtualDirectory Myth

On the other hand, we should configure the "AutoDiscoverServiceInternalUri". Yes, that is URI (i) versus URL (l).

I'll use the following command to see the value on the Exchange 2007 server and then configure the same value on the Exchange 2013 server:

Get-Clientaccessserver | select Identity,AutoDiscoverServiceInternalUri | fl

Identity                                       : ex1
AutoDiscoverServiceInternalUri :

Identity                                      : EX13-1
AutoDiscoverServiceInternalUri : https://ex13-1.mynet.lan/Autodiscover/Autodiscover.xml

Note: remember, EX1 is the Exchange 2007 server.

So we use the domain name rather than the server FQDN ( rather than ex13-1.mynet.lan).

I'll copy the URI for EX1 and paste it into the cmdlet that configures the setting for EX13-1:

Set-Clientaccessserver EX13-1 -AutoDiscoverServiceInternalUri

Now we have this:

Get-Clientaccessserver | select Identity,AutoDiscoverServiceInternalUri | fl

Identity                       : ex1
AutoDiscoverServiceInternalUri :

Identity                       : EX13-1
AutoDiscoverServiceInternalUri :

OWA (Outlook Web App - formerly "Access")

Get-OwaVirtualDirectory "EX1\owa (default web site)" | fl identity,*ternalurl

Identity    : ex1\owa (Default Web Site)
InternalUrl :
ExternalUrl :

Note: we can "get" the OWA virtual directory and then "pipe" the result to the "set" cmdlet as I have done below. We could also use the "set" cmdlet directly.

Get-OwaVirtualDirectory "EX13-1\owa (default web site)" | Set-OWAVirtualDirectory -InternalURL

WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website.

Get-OwaVirtualDirectory "EX13-1\owa (default web site)" | Set-OWAVirtualDirectory -ExternalURL

WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website.

Heeding the warnings above, let's make the same change for ECP (unlike with Exchange 2010, the ECP virtual directory in Exchange 2013 opens the EAC - Exchange Admin Console). There is no ECP virtual directory in Exchange 2007, so we'll just use the URL from above, replacing "owa" with "ecp".

Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -InternalURL

Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -ExternalURL

This should produce the following result:

Get-OwaVirtualDirectory "owa (default web site)" | fl *ternalurl

InternalUrl     :
ExternalUrl     :

Get-EcpVirtualDirectory | fl *url

InternalUrl :
ExternalUrl :

OAB (Offline Address Book)

Here is the existing configuration of the OAB virtual directories:

Get-OabVirtualDirectory | fl identity,*url

Identity    : ex1\OAB (Default Web Site)
InternalUrl :
ExternalUrl :

Identity    : EX13-1\OAB (Default Web Site)
InternalUrl : https://ex13-1.mynet.lan/OAB
ExternalUrl :

Of course, we only need to change them on EX13-1.

As with the other virtual directories, we can do it this way:

Get-OabVirtualDirectory -id "EX13-1\OAB (Default Web Site)" | Set-OabVirtualDirectory -InternalUrl

Or directly with the Set cmdlet:

Set-OabVirtualDirectory -id "EX13-1\OAB (Default Web Site)" -InternalUrl

And likewise for the external URL:

Set-OabVirtualDirectory -id "EX13-1\OAB (Default Web Site)" -ExternalUrl

Note: remember to use quotes around the complete virtual directory name or else we will encounter an error message like this:

[PS] C:\>Get-OabVirtualDirectory -id EX13-1\OAB (Default Web Site)

Default : The term 'Default' is not recognized as the name of a cmdlet, function, script file, or operable program.


Get-ActiveSyncVirtualDirectory | fl server,*ternalurl

Server      : ex1
InternalUrl :
ExternalUrl :

Server      : EX13-1
InternalUrl : https://ex13-1.mynet.lan/Microsoft-Server-ActiveSync
ExternalUrl :

Set-ActiveSyncVirtualDirectory EX13-1\"Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl

Set-ActiveSyncVirtualDirectory EX13-1\"Microsoft-Server-ActiveSync (Default Web Site)" -ExternalUrl

Get-ActiveSyncVirtualDirectory | fl server,*ternalurl

Server      : ex1
InternalUrl :
ExternalUrl :

Server      : EX13-1
InternalUrl :
ExternalUrl :

Exchange Web Services

(for free/busy, calendar functions)

Get-WebServicesVirtualDirectory | fl identity,*ternalurl

Identity    : ex1\EWS (Default Web Site)
InternalUrl :
ExternalUrl :

Identity    : EX13-1\EWS (Default Web Site)
InternalUrl : https://ex13-1.mynet.lan/EWS/Exchange.asmx
ExternalUrl :

C:\>Set-WebServicesVirtualDirectory "EX13-1\EWS (Default Web Site)" -InternalUrl

Set-WebServicesVirtualDirectory "EX13-1\EWS (Default Web Site)" -ExternalUrl

Get-WebServicesVirtualDirectory | fl *ternalurl

InternalUrl :
ExternalUrl :

InternalUrl :
ExternalUrl :


There is a new virtual directory for remote Powershell connectivity in Exchange 2013:

Get-PowerShellVirtualDirectory | fl identity,*ternalurl

Identity    : EX13-1\PowerShell (Default Web Site)
InternalUrl : http://ex13-1.mynet.lan/powershell
ExternalUrl :

Set-PowerShellVirtualDirectory "EX13-1\PowerShell (Default Web Site)" -InternalUrl

Set-PowerShellVirtualDirectory "EX13-1\PowerShell (Default Web Site)" -ExternalUrl

>Get-PowerShellVirtualDirectory | fl identity,*ternalurl

Identity    : EX13-1\PowerShell (Default Web Site)
InternalUrl :
ExternalUrl :


This concludes the configuration of our virtual directories on the Exchange 2013 server.

Tuesday, May 6, 2014

Exchange 2013 (SP1) - Migration - Part 5 - Certificates

The Exchange Server Deployment Assistant (ESDA) has been my guide for much of this migration. On the subject of certificates, the ESDA explains how to request a certificate from a 3rd party certificate authority, install the certificate on the Exchange 2013 server, export it and finally import it on the Exchange 2007 server.

Since I already have a certificate for the Exchange 2007 server, I will proceed somewhate differently. I will leave the certificate enabled on the Exchange 2007 server but export it and then import it on the Exchange 2013 server.

At this point, I want to specify something important...

If the migration will be gradual, the mailboxes being moved from the Exchange 2007 server to the 2013 server over time, we need to create a DNS record such as and this name must be on the certificate (this was explained in greater detail in a previous post). In my case, the few mailboxes I have will be moved at once. There is no need then for a certificate including "".

So, in summary, I will use my existing certificate (exported from the Exchange 2007 server and imported to the Exchange 2013 server) and will not configure a DNS reocrd for or request a new certificate with this name.

So, having clarified my procedure, I will start with the export of the existing certificate, already installed on the Exchange 2007 server.

We identify the certificate by the thumbprint. We obtain the thumbprint with the command "Get-ExchangeCertificate". This command lists the Exchange certificates installed on the server. In my case, I believe the certificate with the thumbprint "EC523xxxxxxxx" (abbreviated for simplicity) is the one I want. Using the format-list cmdlet (below - slightly edited), I verify the dates and the names on the certificate.

[PS] C:\>Get-ExchangeCertificate EC523xxxxxxxx | fl

CertificateDomains : {,,,}
HasPrivateKey      : True
IsSelfSigned       : False
NotAfter           : 3/8/2015 10:32:06 PM
NotBefore          : 3/8/2014 9:32:06 PM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 2B5xxxxxxxxx
Services           : IMAP, POP, IIS, SMTP
Status             : Unknown
Subject            :, OU=Domain Control Validated
Thumbprint         : EC523xxxxxxxxx

Using the thumbprint above, I export the export with the following cmdlet:

[PS] C:\>Export-ExchangeCertificate -Thumbprint EC523xxxxxxxx -BinaryEncoded:$true -Path C:\Cert-Export\export2013.pfx -Password (Get-Credential).Password

I then move the file to the Exchange 2013 server (I will not explain how to do this, of course. You can use a mapped network drive, a flash drive, and external hard drive, or whatever method your prefer).

So now, the exported certificate should be available for import on the Exchange 2013 server.

Before importing the certificate however, I have to import an intermediate certificate into the machine store on the Exchange 2013 server. 

Let me attempt to explain this. Very often, the root certificate authority does not issue certificates to customers directly. Instead they issue intermediate certificates to intermediate authorities that in turn issue certificates to their clients, such as myself. When certificates are used to authenticate a website (and provide the basis for the encryption that secures communication with it), there must be a verifiable "certificate chain" from the certificate issued to the client, the intermediate certificate and then the root certificate.

So, in my case, this mean I need to install the intermediate certificate and then the certificate issued to me, or my organization.

Note: any more detail on this process would be beyond the scope of this post, and in particular the certificate revocation process implying some sort of connectivity with the certificate authorities involved and the caching of any certification revocation lists.

At this point, I have the certificate for my organization on the Exchange 2013 server as well as the intermediate certificate. From where did I obtain the intermediate certificate? It was downloaded to the Exchange 2007 server when I originally purchased the certificate for my organization. Like that certificate, I copied it to the Exchange 2013 server.

So, "with no further ado" (with no further delay), we'll now import the intermediate certificate and the certificate for my organization (

First, we open a Microsoft Management Console (MMC) and add the "Certificate Manager" snapin. Make sure it is for the "Local Computer" rather than the User. We then open the Certificate Manager and navigate to the "Intermediate Certification Authorities" folder:

Right click on the folder, select "All Tasks" and then "Import".

Note: in the following steps, click "Next" and "Finish" as needed.

Browse to the location of the intermediate certificate:

Place the intermediate certificate in the corresponding store:

Once the intermediate certificate has been installed, we can import the certificate for the organization, exported from the Exchange 2007 server earlier.

This is the command we use to import the certificate exported from the Exchange 2007 server:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certs\export2013.pfx
-Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

I use the Get-ExchangeCertificate cmdlet to identity the various certificates (expired and current) that I have on the server and then, locating the one I intend to use (looking at the expiration dates), I enable it with the following cmdlet:

[PS] C:\>Enable-ExchangeCertificate -thumbprint EC523xxxx -Services "IIS,SMTP"

Overwrite the existing default SMTP certificate?

Current certificate: '3366Axxxxxx' (expires 4/28/2019 7:31:12 PM)
Replace it with certificate: 'EC523xxxxx' (expires 3/8/2015 10:32:06 PM)

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): A

Saturday, May 3, 2014

Exchange 2013 (SP1) - Migration - Part 4 - Installation

This may be one of my shorter blog posts.

I've opted to use the command line to install Exchange 2013. Once we have navigated to the location of the Exchange installation files, one line is all that is necessary:

setup /mode:install /roles:ClientAccess,Mailbox /IAcceptExchangeServerLicenseTerms

It is possible to abbreviate some of the terms:

setup /m:install /r:ClientAccess,Mailbox /IAcceptExchangeServerLicenseTerms

That is, in fact, the command that I used.

In previous versions of Exchange, we could abbreviate even further in the selection of roles:


I did not go to that extent so I'm not even sure it would work with Exchange 2013. At any rate, we save little time by typing some letters less - and hardly compensate the long /IAcceptExchangeServerLicenseTerms.

If we use the GUI for the installation, there are a number of choices, such as enabling error reporting (or not), that the administrator is not required to make when using the command line. The command will execute without these parameters. However, these parameters, as well as several others, can be specified if desired.

For example:




We could indicate "false" as well but in that case, we might just as well omit the parameter.

This Technet article lists these optional parameters.

Install Exchange 2013 Using Unattended Mode

But once again, we could just use the command indicated above, which would produce this output:


Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup
Copying Files...
File copy complete. Setup will now collect additional information needed for installation.
Management tools
Mailbox role: Transport service
Mailbox role: Client Access service
Mailbox role: Unified Messaging service
Mailbox role: Mailbox service
Client Access role: Front End Transport service
Client Access role: Client Access Front End service

Performing Microsoft Exchange Server Prerequisite Check

    Configuring Prerequisites                                                                         COMPLETED
    Prerequisite Analysis                                                                               COMPLETED

Configuring Microsoft Exchange Server

    Preparing Setup                                                                                        COMPLETED
    Stopping Services                                                                                     COMPLETED
    Copying Exchange Files                                                                            COMPLETED
    Language Files                                                                                         COMPLETED
    Restoring Services                                                                                    COMPLETED
    Language Configuration                                                                            COMPLETED
    Exchange Management Tools                                                                   COMPLETED
    Mailbox role: Transport service                                                                 COMPLETED
    Mailbox role: Client Access service                                                            COMPLETED
    Mailbox role: Unified Messaging service                                                     COMPLETED
    Mailbox role: Mailbox service                                                                     COMPLETED
    Client Access role: Front End Transport service                                          COMPLETED
    Client Access role: Client Access Front End service                                    COMPLETED
    Finalizing Setup                                                                                          COMPLETED

The Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.


And that's all.

The Exchange Server Deployment Assistant suggests that we enter the Get-ExchangeServer cmdlet to verify that the installation worked. In my case, I was most interested in the following details (the roles installed and the version):

[PS] C:\>Get-ExchangeServer | fl name,ServerRole,AdminDisplayVersion

Name                : ex1
ServerRole        : Mailbox, ClientAccess, HubTransport
AdminDisplayVersion : Version 8.3 (Build 83.6)

Name                : EX13-1
ServerRole        : 16439
AdminDisplayVersion : Version 15.0 (Build 847.32)

If you want more details, you can enter the command like this:

[PS] C:\>Get-ExchangeServer | fl

As with previous versions of Exchange, we can also consult the installation log file, located here:

<system drive>\ExchangeSetupLogs\ExchangeSetup.log

In a production environment, we would do well to make some verifications before continuing but if there are no error messages, the chances are good that the installation was successful.


Once we have installed Exchange 2013, we will probably want to take a look at the new web-based "Exchange Administrative Center" (EAC). If we attempt to connect with "https://localhost/ecp", we will encounter an error:

No, this is not the typical certificate error message (which we might expect, not having configured certificates yet).

This happens because we have attempted to open the EAC with an account that does not have an Exchange 2013 mailbox. The Exchange Server Deployment Assistant recommends that we create a mailbox for a user that is added to the Organization Management role and then use that user to connect.

Otherwise, we can use the following URL:


Yes, if we indicate the version of Exchange 2013 (15), we gain access to the EAC:

I created a shortcut with that URL, and saved it to the desktop, so I would not have to enter it manually each time I want to access the EAC.


Now that Exchange 2013 is installed, we will use the information gathered in the previous posts to configure it. In particular, we will concentrate on:
  • Certificates
  • Internal and external URLs
  • Outlook Anywhere
These will be the subjects of my next posts.