Monday, March 31, 2014

Exchange 2013 (SP1) - Migration - Part 1 - Documenting the existing environment


In this blog post, first of a series about migrating to Exchange 2013 (from 2007 in this case), I'll take a look at documenting the existing environment and also verifying the absence of any issue likely to complicate migration.

This will be a simple migration from a single Exchange 2007 (SP3) server to a single Exchange 2013 (SP1) server. This implies that both Exchange 2013 roles (Mailbox and Client Access) will be on the same single server.

First, we need to document the existing environment so we can configure the new Exchange 2013 server like the Exchange 2007 server (when appropriate). Some settings, those at the Organization level (in the Exchange Management Console, for example) should transfer automatically. On the other hand, at least some settings at the Server level will have to be configured manually (or with a script). These would include URLs, URIs and authentication methods of various services such as OWA, OAB, and ActiveSync.

Please note that I will concentrate on elements used in my test environment. For example, I use Outlook and OWA but not POP or IMAP. I happen to have a Cisco ASA firewall and no longer use ISA or TMG (products that Microsoft is abandonning for that matter).  My objective is not to present every conceivable scenario but to share knowledge acquired in certain areas.

For the areas not covered here, I would direct the reader to official Microsoft documentation or the multitude of other literature available on the Internet.

Second, it is also a good idea to confirm that the existing environment is healthy. If the existing environment is not functional, it is unlikely that adding another element of complexity (migration to Exchange 2013)  will make the system more efficient.

These are the tools that I will use:

  • Exchange Server Deployment Assistant
  • Exchange Best Practices Analyzer
  • Exchange Remote Connectivity Analyzer
  • Exchange Server Profile Analyzer
  • Powershell Get-* cmdlets (for information on the virtual directories)
  • Powershell Test-* cmdlets (Test-ServiceHealth, Test-OWAConnectivity, etc.)

There are a number of other tools that could be used as well but that I will only mention. Some require the creation of a entire test environment that would exceed, by far, the scope of this project and series of blog posts.

We can use Performance Monitor data to measure the requirements for the new server in this area. This data, as well as data from other sources (like the Exchange Profile Analyzer) can be entered into what is now called the Exchange (2013) Server Role Requirements Calculator.

The resulting data from the Calculator can be used with the JetStress and LoadGen tools to simulate the load on the Exchange server.

Warning ! JetStress and LoadGen should be used in a lab setting (that replicates the production environment) and not in the production environment itself. Please read the documentation if you intend to use these tools.


Exchange Server Deployment Assistant

This is a web-based tool that, based on the information provided by the user, provides a deployment plan. here is the presentation of the tool on the website itself:

"The Exchange Server Deployment Assistant is the IT pro’s source for Exchange deployment technical guidance. Tell us what kind of deployment you’re interested in, answer a few questions about your environment, and then view Exchange deployment instructions created just for you."

Microsoft Exchange Server Deployment Assistant

In our case, we are interested it an on-site migration from Exchange 2007 to Exchange 2013. Even in these circumstances, there are a multitude of deployment options depending on our particular environment or the features we intend to use. I'll only illustrate (and briefly) some of the primary steps:

So, I select the "On-Premises" option:

I select the Exchange 2013 option (the other option being Exchange 2010):

We will upgrade from Exchange 2007 (only):

There are a number of additional questions:

Do we intend to install the Mailbox and Client Access roles on the same server?

In my case, yes.

Are we running "disjoint namespaces"?

In my case, no.

Do we have an existing Edge Transport server?

In my case, no.

In other scenarios, different questions may be asked and the recommendations will be different.

In any case, the Assistant will produce a checklist that can be used to guide the deployment of Exchange 2013 (in this case).

Exchange Best Practices Analyzer

The ExBPA (Exchange Best Practices Analyzer) compares the configuration of the Exchange server to Microsoft's "best practices", or recommendations for (in this case) an Exchange server.

Note: it is not feasible to examine every component of each of these tools in detail. One could probably dedicate a blog post to each of them and even then, not cover everything. So I'll make some assumptions: the reader

- can find where these tools are located or...
- can find information online explaining the use of these tools in greater detail.

In other words, I will not necessarily provide step by step instructions .

In the EMC, Toolbox section, open the ExBPA:

You may search updates if you want. If you use the ExBPA often, it is probably not necessary to check every single time the tool is opened. Otherwise, go to the "Welcome Screen" and then "Select options for a new scan". Connect to Active Directory (indicate a domain controller, if one is already selected, that should be fine) and select a "New Best Practices" scan. There are several possible scans. I'll select the "Health Check" and click on "Start Scanning" (not shown on screenshot):

When the scan finishes, click on "View a report of this Best Practice scan":

I have two issues to examine. I can obtain more information by clicking on the item:

Of course, results will vary depending on each environment and the possible issues that may exist. The administrator in charge will have to act consequently.

Exchange Remote Connectivity Analzyer

This is another web-based tool. The URL is:

But a websearch for "Exchange Remote Connectivity Analzyer" will lead the reade rto the same location.

There is a prerequisite: a mailbox must be used for the test. It is recommended that a mailbox be created for the test and then disabled for security reasons.

Once again, I will not detail every possible test and all possible options. Not all are useful for all environments. As an example, I'll select the Outlook Autodiscover test:

I enter the credentials for the test mailbox:

The results of the test are displayed after a minute or so:

Details can be displayed by clicking on the errors.

Exchange Server Profile Analyzer

This tool must be downloaded and installed. The install process is short and simple. We execute the downloaded EPA.msi file and click "Next" or "Finish" as needed.

After installation, we can find the EPA in the Start Menu:

We open it, connect to Active Directory (a couple clicks here) and then select scan options:

We have a number of options (Save Configuration, Start Collect - not shown in screenshot). I'll simply start the collect of data. When the collect finishes, we have this screen:

At the end of the scan, we can view the results, saved to an HTML file:

Note: I encountered several problems with the EPA. These points should be retained:

  • A custom account must be created for the EPA. It should be a member of the Exchange View-Only Administrators group. It also needs Full Access permissions to all the mailboxes. While it was possible to grant this permission to the few mailboxes in my test environment manually, a combination of the Get-Mailbox and Add-MailboxPermission Powershell cmdlets would make more sense if the reader is managing hundreds (or thousands) of mailboxes.
  • I could not expand the headings in the results (by clicking on the + sign) on the Exchange server itself, perhaps because of settings particular to the browser (the file to open is an HTML file). I was able to open it on a Windows 7 machine however.

Powershell Get-* cmdlets

These cmdlets provide output for the documentation of the existing Exchange environment, including some parameters that will be configured on the new Exchange 2013 server.

There are a number of options here. We can concentrate on the urls and the authentication methods as follows. This is achieved by the format-list cmdlet (after the pipeline) and indicating the parameters we wish to display. I use the * before and after "url" for the internal and exernal values and then *auth* for any authentication information. In some cases, we need to indicate something else, *uri* or *host*.

I'll post the cmdlets here, but with the output for the first cmdlet only:

[PS] C:\>Get-AutoDiscoverVirtualDirectory | fl *url*,*auth*

InternalUrl                   :
ExternalUrl                   :
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True

[PS] C:\>Get-OwaVirtualDirectory "owa (default web site)" | fl *url*

[PS] C:\>Get-OabVirtualDirectory | fl *url*

[PS] C:\>Get-ActiveSyncVirtualDirectory | fl *url*

[PS] C:\>Get-WebServicesVirtualDirectory | fl *url*

[PS] C:\>Get-ClientAccessServer | fl *uri*

[PS] C:\>Get-OutlookAnywhere | fl *hostname*

We can also export the complete output to a text file, like this:

Get-ActiveSyncVirtualDirectory | fl | out-file C:\Scripts\EAS_vDir.txt

If we want only the urls and authentication methods, we can do this:

Get-AutoDiscoverVirtualDirectory | fl *url*,*auth* | out-file C:\Scripts\EAS_vDir.txt

We can use this information to configure the 2013 server with the corresponding Set-* cmdlets. We'll see that once the Exchange 2013 server is ready for configuration.

Powershell Test-* cmdlets

If mail can be sent and received, both to/from internal and external users, if users can use Outlook, OWA, ActiveSync, to communicate, one could conclude that the messaging system is functioning as it should. Otherwise, we can use a number of cmdlets to confirm this. I will not publish the output here (sometimes verbose and dependent on the environment) but the cmdlets themselves:

  • Test-ServiceHealth
  • Test-SystemHealth (essentially the command line equivalent of the ExBPA)
  • Test-MAPIConnectivity
  • Test-OWAConnectivity
  • Test-OutlookWebServices
  • Test-WebServicesConnectivity

The list is not complete. There are, for example, cmdlets for the Edge Transport synchronization, for POP and IMAP connectivity, or for Unified Messaging connectivity, which are all features that I do not use.

Get-Command Test-* will show the cmdlets available on the Exchange 2007 server.

You can select - and run - those that apply to your environment.

Saturday, March 15, 2014

Exchange 2013 (SP1) - prerequisites for installation

Exchange 2013 - SP1

This will be my first blog post on Exchange 2013. I have considered blogging about aspects of Exchange 2013 for some time but a number of factors delayed my decision. First, reading the official Exchange blog, I noticed that there were a number of complaints about the product and "great expectations" for SP1 that would, readers hoped, correct some of the problems. Second, fewer and fewer organizations use Exchange onsite, preferring Office 365. Wouldn't it be a better investment to concentrate on Microsoft's Cloud products then?

There will still be a percentage of organizations that continue to use Exchange onsite, for various reasons: interaction with custom applications, extremely strict security regulations or something as basic as poor or unreliable connectivity to the Internet. This last factor is probably a rare circumstance now but I have interacted with someone on an online forum who managed IT in a health care setting and had to contend with Internet access that was simply not reliable. The last I heard, the ISP was going to add another line in the area for redundancy. Finally, there is always the possibility that we work for a hosting provider in the Cloud. In the end, Exchange has to be installed on a server, physical or virtual, somewhere.

Moreover, I have worked with Office 365 and what is advantageous, from a learning perspective, is that Exchange 2013 and Office 365 (Exchange Online) have a very similar interface. I hesitate to write "identical" since some components are missing from the latter.

So, in this first post, after a rather long introduction, I will present the "prerequisites" necessary for the installation of Exchange 2013. By "prerequisites", I mean not only various software, certain roles and features, but also the overall Active Directory environment: type of domain controllers and functional levels.

Note (important!): in this scenario, we are preparing a fresh installation of Exchange 2013. Some use the term “green-field”. In other words, there is no existing messaging system in place. This would be quite exceptional in the real world. However, the objective of this exercise is to familiarize myself (and the reader) with the Exchange 2013 installation prerequisites, without complicating the presentation with the multitude of factors that would need to be taken into account in the case of a migration (a more complex scenario that I may examine in another post or series of posts).

Prerequisites – presentation and installation

First of all, the server on which we will install Exchange must be a member of the domain. We might as well add it to the domain from the very start.

I will assume that the server already has an appropriate name and IP address (and other network parameters) and has been added to the domain. I will not detail configuration of these aspects here.

Active Directory preparation

If we prepare the schema and domain for Exchange 2013 SP1 on a domain controller, we have to install the following tools on that server. Otherwise, they can be installed on the (future) Exchange Server. In fact, these tools must be installed on the Exchange server itself at one point or another, so that is where I have run them with past versions of Exchange.

  • .NET Framework 4.5
  • WMF 4.0 (Windows Management Framework) - for SP1. WMF 3.0 was appropriate for Exchange 2013 RTM.

We can download this software and then install it in several clicks. I will not provide links (which may change) but simply state that I searched for these products using an Internet search engine, downloaded them and then installed them. I will make the assumption that if you intend to implement Exchange, version 2013 or any other, you can use a search engine, download software and install it. There will not be step-by-step screenshots for this.

Note: Windows Server 2012 includes .NET 4.5 and WMF 3.0. Windows Server 2012 R2 includes WMF 4.0. If we use Windows 2008 Server (R2 SP1), we need to download and install all this software manually.

  • RSAT (Remote Server Administration Tools) for Active Directory Domain Services (ADDS).

We can install these tools with the command: Add-WindowsFeature RSAT-ADDS

Note: with Windows Server 2012 we can use Install-WindowsFeature

Restart the server as needed.

Once this software is installed, we can prepare Active Directory.

Note: we have to have domain controllers that run at least Windows 2003 SP2. The same level is required for the global catalogs but if all domain controllers are at 2003 SP2 then the global catalog servers must be as well. Lastly, the forest functional level must be at least Windows 2003.

The commands for the preparation of the schema and the domain are below (in bold). They must be run at the command line, in the same location as the Exchange install files. These files are extracted from the following executable that can be downloaded from the Microsoft Download Center:


Note: you can search for “Exchange 2013 SP1 download”

This file will most likely be placed on the Exchange server and we can run the commands from this location (rather than on a domain controller) provided that the schema master is accessible from this server. Regardless, the following requirements must be met:

  • We must be member of Schema and Enterprise administrators to execute the command.
  • We must run the command on a 64 bit computer.
  • I operate in a small test environment where replication is almost instantaneous. In other environments, we should wait until replication of changes to the schema have completed.

At any rate, once downloaded, the files are extracted to a folder. Then, at the command line, we browse to that location and run the following commands:

setup /PrepareSchema or setup /ps (abbreviated form)

We prepare "Active Directory" (the schema is part of Active Directory in fact) with the following command:

setup /PrepareAD or setup /p

This will work in an existing Exchange envrionment. In a brand new installation, we would have to specify the "organization name":

setup /PrepareAD / or setup /p /

If we only have one domain, we have finished. There is no more domain preparation required. The PrepareAD command prepares the local domain. If there were other domains, they would be prepared with the following command:

setup /PrepareDomain or setup /pd

There are a couple more options, if, for example, you had a number of domains and wanted to prepare them all at once.


Here is an example. Note that there are a number of “obstacles” that must be overcome before the command will run.

PS C:\E2K13SP1> setup /ps

setup : The term 'setup' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Suggestion [3,General]: The command setup was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type ".\setup".

If we do what is suggested, the command will run, but...

PS C:\E2K13SP1> .\setup /ps

Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup
You need to accept the license terms to install Microsoft Exchange Server 2013. To read the license agreement, visit To accept the license agreement, add the /IAcceptExchangeServerLicenseTerms parameter to the command you're running. For more information, run setup /?.

OK, we also have to consent to Microsoft’s license terms. Yes, this is different from previous versions of Exchange for which there was no such parameter:

PS C:\E2K13SP1> .\setup /ps /IAcceptExchangeServerLicenseTerms

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.

At this point, on the first attempt, the process stopped, apparently because of a pending reboot. I had to restart the server. Now aware of the need to add .\ before setup, and /IacceptExchangeServerLicenseTerms at the end, I did so - and also performed the upgrade of Active Directory.

This is what the output should look like:

PS C:\E2K13SP1> .\setup /ps /IAcceptExchangeServerLicenseTerms

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.
Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis                                                                             COMPLETED
Configuring Microsoft Exchange Server
Extending Active Directory schema                                                       COMPLETED
The Exchange Server setup operation completed successfully.

PS C:\E2K13SP1>
PS C:\E2K13SP1> .\setup /p /on:myvmlab /IAcceptExchangeServerLicenseTerms

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.
Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis                                                                   COMPLETED

Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.
For more information, visit:

Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.
For more information, visit:
Configuring Microsoft Exchange Server
Organization Preparation                                                              COMPLETED

The Exchange Server setup operation completed successfully.

Among the points to retain, concerning the "small print" above (actually the result of my editing), we should remember that once we install Exchange 2013 (SP1), we cannot install additional Exchange 2007 or 2010 servers. On the other hand, existing Exchange 2007 and 2010 servers can coexist with Exchange 2013.

Otherwise, we have prepared the schema and Active Directory for Exchange 2013. Remember that the two commands executed above suffice in a single domain. If there are multiple domains, we would have to prepare them as well with the setup /PrepareDomain or setup /pd command.


Prepare Active Directory and Domains

Install required Windows Features

I'm going to install both the Mailbox and Client Access Server role. Therefore, we need to install the following features:

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

Note: instead of installing these features manually, we can paste the above script in Powershell.

Run this command *before* the command above, if necessary: Import-Module ServerManager 

Some versions of Windows (Server 2012) will import the necessary modules automatically.

Installation of other prerequisite software

If we have not already installed .NET Framework 4.5.1 and WMF 4.0 (and RSAT) for the preparation of Active Directory, we need to install this software now. I’ll mention them again so we have a complete list, but if they have been installed on the Exchange server earlier they can be ignored (that’s right, no need to install them again).

  • .NET Framework 4.5
  • WMF 4.0
  • Microsoft Unified Communications Managed API (UCMA) 4.0, Core Runtime 64-bit
  • Microsoft Knowledge Base article KB974405 (Windows Identity Foundation)
  • Knowledge Base article KB2619234 (Enable the Association Cookie/GUID that is used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
  • Knowledge Base article KB2533623 (Insecure library loading could allow remote code execution)

Note: some of these may already be installed via Microsoft Updates.

Note: installation of these files is essentially a matter of double-clicking on the executable and following the prompts, clicking “Next”, “I accept” and “Finish” as needed. It may be necessary to reboot the server for some.

Note for Windows 2012 R2

The software listed above is for Windows 2008 R2. Windows 2012 R2 includes most of them. In fact, there are only two steps:

1. Install the following Windows Features.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

2. Install UCMA 4.0.


At this point, we should be ready to install Exchange itself.

Wednesday, March 12, 2014

Windows Server 2012 - Active Directory - Recycle Bin - limitations

What would happen if someone accidently removed a significant number of  members from an Active Directory security group? Could the Active Directory Recycle Bin be used to restore those members?

This question was recently asked in the Microsoft Technet Directory Services forum.

The answer is no.

We must distingush between two cases:

  1. Restoring the properties (attributes) of a deleted object, with the object itself, upon recovery.
  2. Reverting changes to properties of an undeleted object to a previous state.

The Active Directory Recycle Bin does not have the ability to track simple changes to objects.

If the object itself is not deleted, no element is moved to the Recycle Bin for possible recovery in the future.

In other words, there is no rollback capacity for changes to object properties, or, in other words, to the values of these properties.

I would like to illustrate this distinction with the examples below.


First, I will delete a group object - "Group1" - in Active Directory Users and Computers. Note that Group1 has three members: Valerie, Vik and Yvette.

So I delete the group...

Suddenly, I realize that this was not the group I was supposed to delete. Or Management informs me that there was a mistake: in fact, they really wanted me to delete Group2.

Now what?

We have at least two options, provided that...

  1. We schedule regular backups.
  2. We have enabled the Active Directory Recycle Bin (yes, it must be enabled first, and some conditions must be met. Essentially, we must be at what is called the "Windows 2008 R2 Forest Functional Level").

In this blog post, I'm interested in the Recycle Bin option so I open another Active Directory interface, the "Active Directory Administrative Center" (ADAC) and go the "Deleted Items" container:

I open the container and...

There is Group1! Just waiting to be restored! I right-click on the item, select "Restore" and we should be "all set".

Note: the Recycle Bin indicates that last known parent. If we select the simple "Restore" option, the object will be restored to that container. Even if the parent container has been deleted since, we can choose to restore to a different location. Either way, we can recover the object.

But that's not all. Group objects will be recovered with their members:

Here, even if group membership was not re-established automatically, it would be easy enough to re-add the members manually, But that would be infinitely more difficult if a group contained hundreds of members and perhaps numerous nested groups as well.

So we have restored a deleted Active Directory object, a group object in this case, and restored certain properties of the object (its membership) as well. We can consider membership to be a "multivalued" property of the group since more than one value (member) can be indicated.


Now I will delete not the group itself but remove one of its members: Valerie Owen.

Will I be able to see this member in the Recycle Bin and restore it?

No. There is nothing to restore. And yes, I waited long enough for replication and so forth to complete. On that subject, the two domain controllers in my virtual network are connected to the same virtual switch. So, no, latency has nothing to do with this. There is simply nothing to restore.

There is nothing to restore because we did not delete the user object representing Valerie Owen. Instead, we removed one of the values of the Group1 membership property that designated this user as a member.


At this point, I am quite confident that my assertions above (the first lines of this post) are correct,

But let's perform the same experiment with some user object properties.

Here, among others,  we can see the "Description" and the "Office" properties of the Alison Lindsay user object.

I will modify the values of these attributes (synonomous with properties here) as follows:

Does the Recycle Bin track these changes? Can I perform a rollback to the previous values?



In conclusion, one should be aware of what the Recycle Bin can and cannot do. If we perform massive changes to group membership, thinking we can always "rollback" if something stops working, we will have a very big surprise!

Moreover, there is still a market for third-party products for Active Directory that do track such changes and can rollback the attributes of an object to a previous state. I cannot recommend one product over another but if you are interested in such a product, you can search for "Active Directory" and "NetIQ" or "Quest".


Monday, March 10, 2014

Exchange 2007 (SP3) - Certificates - 3rd party - management

Installing a third-party certificate on Exchange (2007 - SP3)

In messaging systems, such as Exchange, certificates validate a mail server's identity and constitute a foundation for the encryption of communications between the mail server, other mail servers, and clients.

The subject is both vast and complex so before a very brief introduction below, I will refer those unfamiliar with certificates to these articles:

Introduction to Digital Certificates (Verisign Australia)

Introduction to Digital Certificates (Comodo)

Since links can change, the reader might do as well to use the terms above in an online search using Bing or Google or another search engine.


Certificates exist in several forms and can come from many sources.

Some certificates are "self-signed". This means that the server hosting the application in question, Exchange in our case, signs them. This provides basic functionality when setting up an Exchange server but is very limited because other entities (other mail servers, clients accessing mail via a web browser) have no reason to trust a unknown certificate from an unknown server that has just been installed.

We can obtain a certificate from our organization's certificate server, if we have one of course. This is what we could call "a step in the right direction". In the Microsoft Active Directory domain, domain member client machines will trust certificates issued by a "certificate authority" that is part of the domain. On the other hand, other companies would have no reason to trust these certificates, nor would computers that are not members of a domain, such as laptops or tablets being used to access email from home.

The best option is to obtain a certificate from a "third-party" certificate authority, that is, a company like Verisign, Comodo, Digicert, GoDaddy or Thawte. Such certificates are trusted by practically all web browsers.

In this blog post, I will present a step-by-step process for obtaining a certificate from a third-party provider and installing the certificate on the Exchange server.

I'll organize the process in 4 steps:

Step 1 : Create a certificate request at the Exchange server.
Step 2 : Submit the content of the resulting file to the Certification Authority
Step 3 : Download the certificate
Step 4 : Import and Enable the certificate for Exchange services.


Create a certificate request at the Exchange server.

We can create the certificate request in the Exchange Management Shell (EMS) using the Powershell "New-CertificateRequest" cmdlet. This is the only option in Exchange 2007. In Exchange 2010 and 2013, we can use a graphical interface as well.

There are a number of possible variations but the cmdlet and parameters shown below work with the third-party certificate authority to which I will submit the request in a later step.

New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=us, s=MyState, l=MyCity, o=My Name," -DomainName, -Keysize 2048 -privatekeyExportable:$true -path "C:\Scripts\mitserv.csr"

Let's dissect this rather long command...

  • New-ExchangeCertificate: this is the cmdlet itself. Without the parameters and values that follow, however, it would not produce any results.
  • GenerateRequest: the value of this parameter must be set to "true" for the creation of an actual request.
  • subjectName: here, we must enter, from left to right, the code of our country, our state (or province), our location (we can name our city), our organization (or name, if we are an individual) and the name of our domain. I use the name of a fictitious organization that I use for tests, just as Microsoft has a number of fictitious organization names such as Constoso and Trey Research. Note: instead of "", I used the name that would be used most often - "" -, which was recommended at one point, for some reason, by someone, from the certificate authority. In any case, if you want to use a name with any Exchange service (POP, IMAP, IIS, SMTP), and if that service may need to be validated, the name should be on the certificate.
  • DomainName: one of the roles of the certificate is to validate our website (or webmail, Outlook Web Access in the case of Exchange). Therefore, the domain name of our website must be indicated on the certificate. With Exchange, we may have several other names, such as those indicated above, for webmail, for autodiscover and perhaps the name of the mail server itself (or themselves if we have several). What names should be on the certificate? This is a subject in itself, but the most common recommendation is to add the name used for webmail and the name used for autodiscover.
  • Keysize: validation is one role of the certificate and encryption is another (even though the certificate does not encrypt anything by itself). The size (or length) of the encryption keys is one element that determines the strength of the encryption. At this time (2014), the minimum recommended key size is 2048 bits.
  • privatekeyExportable: if we ever want to export the private key, and then import it on a second mail server or a security appliance like ISA or TMG, we should set the value of this parameter to "true".
  • path: this is simply where we want to create the certificate request file and where we can find it when we want to upload it to the website of the certificate authority for ordering.
I realize that this information may not be entirely clear to some readers. Private key? As opposed to... public key? I prefer not to provide a more detailed explanation for a number of reasons. First, encryption is not the subject of this post. I would recommend that those interested in more details refer to the multitude of resources online. Second, what I have provided above is a simple example. The general configuration of the cmdlet is valid for all certificate requests but details may vary with different certificate authorities. Some may accept a smaller keysize or, by the time you read this, require a larger keysize. Another example: the file extension of the request is .csr above but can also be .req.

If the command line option seems too obscure, despite my attempt to explain the process, the reader may use a web-based assistant, such as the tool provided by Digicert, one of the best known certificate authorities:

It is still necessary to copy and paste the resulting command in the EMS to produce the request but the wizard will help you construct it.

Submit the content of the request file to the Certificate Authority

The New-ExchangeCertificate cmdlet creates what is in fact a text file. If we open it, we will see something like this (abbreviated for concision):



We must copy and paste this content (including the header and footer - the BEGIN NEW CERTIFICATE REQUEST and END NEW CERTIFICATE REQUEST) into a text box of the certificate authority's website.

I will use the website of "Certificates for Exchange" in this example. Of course, the process outlined by the certificate authority you select may be different.

Note: some CAs apparently allow the requestor to uphold the entire file, no copy and paste required.


I will not include step-by-step instructions for creating an account, logging on and purchasing (the rights to) a certificate. Each certificate (or certification) authority is different. If these steps prove challenging, there is usually a contact number for technical assistance.

So we logon and arrive at the "My Account" page:

We expand SSL Certificates and arrive here:

Further to the right, on the same page, there is a "Launch" button:

Click on the "Launch" button. We should then have a screen like this:

Copy and paste the content of the .csr file (you can open it with Notepad, for example), into the text block. Be sure to include "BEGIN NEW CERTIFICATE REQUEST-- and --END CERTIFICATE REQUEST----"

In the area below, enter your subject alternate names (SAN - not to be confused with a storage area network):

The selection of these names is a subject in itself (we already saw them in the creation of the certificate request file), but it is most common to use something like or for OWA (Outlook Web Access) and then for the autodiscover functionality.

Click on "Next" (off the screenshot, to the right).

I was instructed to enter all the names I wanted on the certificate, even though it appears that the domain name is "".

I click on "Next" once more and a message displays stating that my certificate will be ready shortly.

If I continue, I should arrive at the following page, where I can see that the request status is "Pending":

There should be some sort of confirmation process, usually an email sent by the certificate authority to validate the request. So check your email. In my case, the message body was like this (excerpt):

"Dear Secure Certificate Customer,

We have received a Certificate Signing Request for the following domain(s) : 

Our query of the Whois database returned your name as the administrator for the domain in the certificate request.

In order to verify the validity of this request and that it was submitted by the entity to which the domain in the request is registered, please signify your final approval or disapproval of the certificate request by clicking the link below [...]."

So I click on the link and confirm the validity of the request:

Download the certificate

When I return to the web interface and "Launch" the certificate management tool, the page that displays reflects the fact that the certificate has been approved. This is a screenshot of a portion of that page where, among other options, I can download the certificate. Note that in the screenshot above, the download option was not enabled.

I download the certificate. In fact, I download a zip file from which I extract the certificate for my domain and an intermediate certificate. The website alerts us about this:

So we have a zip file named with the serial number of the certificate (not the thumbprint - which is something else we will see later):

We extract the two files from the zip file by right-clicking on it and selecting the "Extract" option (at least on current Windows operating systems). We then have these files that must be imported into the Exchange server's local certificate store:

Import and Enable the certificate(s) for Exchange services.

So we have two certificates to import: the intermediate certificate first and the certificate for our domain second.

And how do we proceed?

I've followed the directions provided by the certificate authority, using the "Certificates (Local Computer)" MMC for the intermediate certificate and the EMS to import my organization's certificate.

I've already created a custom MMC (Microsoft Management Console) for the intermediate certificate import. I'll assume that the reader either knows how to create such a console or at least knows how to perform an online search for directions. I will point out that the "Certificates" snap-in should target the local computer rather than the user.

1. Open the console, go to "Intermediate Certification Authority", right-click on this folder, select "All Tasks, "Import".

2. The "Welcome to the Certificate Import Wizard" window displays. Click "Next".

3. Browse to the location of the downloaded files.

As shown below, it will be necessary to change the file extension type to "PKCS #7" so the intermediate certificate, with a .p7b extension, is visible:

4. We should have something like this:

5. Make sure the certificate is imported into the "Intermediate Certification Authority" folder.

6. We click on "Next" or "Finish". If all goes well, we should see this:

7. The certificate should now be visible in the certificate store, perhaps above a previous certificate.

Note: I asked the vendor if previous (expired) certificates should be removed. The technical support representative stated that this was not necessary.


At this point, we can import the certificate requested for our organization with the EMS. It's just as matter of entering the cmdlets (with various parameters and values) as shown below.

1. Open the EMS and browse to the location of the certificate. Import the certificate with this cmdlet:

[PS] C:\>Import-ExchangeCertificate -path C:\\2b515b90\2b515b90.crt

Thumbprint                                Services     Subject
----------                                   --------     -------
EC523--ABC9  ....., OU=Domain Control Validated

Note: of course, your serial number and thumbprint (abbreviated here) will be different.

2. Enable the certificate (you can copy and paste the thumbprint from above):

C:\>Enable-ExchangeCertificate -Thumbprint EC523--ABC -Services "IMAP, IIS, POP, SMTP"

Note: after the "services" parameter, we must enter the services that will be used: POP, IMAP, IIS, SMTP and UC are the options.

We will be asked if we want to overwrite the previous certificate (if we have one):

Overwrite existing default SMTP certificate '605033---D774B' (expires 12/13/2013 8:24:04 PM)
with certificate 'EC523F----------ABC9BDC' (expires 3/8/2015 10:32:06 PM)?

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

I enter "A"... and press enter.

We can use the Get-ExchangeCertificate cmdlet to see the properties of the certificate (the thumbprint can be used to concentrate on the certificate in question). Use the cmdlet with no parameters to see all certificates - and their thumbprints - first. Then re-enter the cmdlet with the thumbprint.


Now users should no longer be confronted with a warning everytime they attempt to connect to Outlook Web Access (OWA) or be prompted for a password when they open Outlook (although password prompts in Outlook can have other causes as well).

Thursday, March 6, 2014

Exchange 2007 (SP3) - Public Folders - permissions - recurse parameter

I was working with a user who wanted to rearrange public folders, moving some and deleting others as needed. He could do neither. I had not worked with public folders for a while, and even then, mostly for practice (certification exams), so it took me a while to solve the problem. This is what I did...

First, I checked his permissions:

[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | fl

Identity     : \Sales Email
User         : mynet.lan/staff/John Smith
AccessRights : {PublishingEditor}

Note the syntax:

- We can abbreviate -identity with -id or simply omit this parameter, since it is positional.
- The name of the folder, in quotes, must be preceded by a backslash.

Note: for confidentiality, I am replacing the real names with fictitious names.

I thought that the problem could be resolved by granting him "Owner" permissions.

[PS] C:\>Get-PublicFolder "\Sales Email" | Add-PublicFolderClientPermission -user jsmith -AccessRights Owner

First obstacle for this solution:

Add-PublicFolderClientPermission : The user,mynet.lan/staff/John Smith , already has some of the permissions (ReadItems, CreateItems, [...]) specified to be added on the public folder \Sales Email.  You cannot add a right that the user already has.

The current permission for mynet.lan/staff/John Smith is "ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, EditAllItems, DeleteAllItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible".

After some unsuccessful attempts, I concluded that the best solution would be to remove the current permissions ("Publishing Editor") and then add the desired permissions ("Owner").

Of course, I do this after communicating with the user so I do not remove their permissions exactly when they might be working with the folders.

Here are the commands to remove permissions:

[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | Remove-PublicFolderClientPermission

There is a confirmation prompt and I confirm the operation.

Of course, this leaves the user in a worse situation than before, since they now have no permissions at all. We need to assign the new permissions immediately after, so it's a good idea to have our commands ready.

[PS] C:\>Add-PublicFolderClientPermission -id "\Sales Email" -user jsmith -AccessRights Owner

I verify the new permissions:

[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | fl identity,user,AccessRights

Identity  : \Sales Email
User      : mynet.lan/staff/John Smith
AccessRights : {Owner}

That should do the trick... or so I think.

Consulting the user, I learn that he can still not move and delete certain folders.

I suspect that public subfolders, unlike folders in the Windows file system, do not automatically inherit the permissions of their parent folder.

I run the "Get-PublicFolderClientPermission" on some of these subfolders and see that the user also has Owner permissions. But there are quite a few subfolders and it is possible he was granted Owner permissions to some subfolders and not to others.

I want a fresh start. But... how can I grant the user "Owner" permissions on all these subfolders if, indeed, permissions are not inherited?

This is where I use the -recurse parameter... with some effort.

I first try this:

[PS] C:\>Add-PublicFolderClientPermission "\Sales Email" -user jsmith -AccessRights Owner -recurse


Add-PublicFolderClientPermission : A parameter cannot be found that matches parameter name 'recurse'.

What's the problem?

Well, there is no -recurse parameter for the "Add-PublicFolderClientPermission" cmdlet:

[PS] C:\>get-command Add-PublicFolderClientPermission | fl

Name             : Add-PublicFolderClientPermission
CommandType      : Cmdlet
Definition       : Add-PublicFolderClientPermission [-Identity] <PublicFolderIdParameter> -User 
<PublicFolderUserIdParameter> -AccessRights <Collection`1> [-Server <ServerIdParameter>] [-DomainController <Fqdn>] [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>] [-WhatIf] [-Confirm]

On the other hand, the cmdlet get-publicfolder does have such a parameter:

[PS] C:\>get-command get-publicfolder | fl

Name                     : Get-PublicFolder
CommandType      : Cmdlet
Get-PublicFolder [[-Identity] <PublicFolderIdParameter>] -Recurse [-ResultSize <Unlimited`1>] [-Server <ServerIdParameter>] [-DomainController <Fqdn>] [-Verbose] [-Debug] [-ErrorAction><ActionPreference>] [-WarningAction<ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer<Int32>]

So let's try this:

[PS] C:\>Get-PublicFolder "\Sales Email" -recurse | Get-PublicFolderClientPermission -user jsmith | Remove-PublicFolderClientPermission

I confirm the operation (I've edited out the verbiage here) and the permission changes on the folder and each of the subfolders displays on the screen:

Identity                         User              AccessRights
--------                         ----              ------------
\Sales Email             mynet.lan/staff/John Smith {Owner}
\Sales Email\2005 Email  mynet.lan/staff/John Smith {Owner}

This solved the problem... for the most part. There were still some subfolders that, for some strange reason, could not be moved. For those, I created comparable subfolders in the target location, copied the content (emails) from the old to the new location, and then, after confirming with the user, deleted the original subfolders.