Friday, May 24, 2013

Exchange 2010 - migration from 2007 - moving mailboxes

Moving mailboxes from one server to another is a crucial part of an Exchange 2007 - Exchange 2010 migration.


Exchange 2010 offers "online" migration which allows the user to work in their mailbox while the migration is taking place. However, this only works going from an Exchange 2007 to Exchange 2010 server (not for a possible rollback in the other direction) and the migration must be initiated in the EMC (or EMS) on the Exchange 2010 side.


The process includes 3 main steps:
1. Create a mailbox database on the Exchange 2010 server.
2. Mount the database.
3. Move the mailboxes.
Once all mailboxes have been migrated, we can also remove the Exchange 2007 mailbox database itself.

1.Create a mailbox database on the Exchange 2010 server

Yes, we could use (or rename and modify) the default mailbox database created at the installation of Exchange 2010 but I will opt to create a new database with the desired database and log file paths as well as a more user friendly name. We can create the database using either the EMC or the EMS (command line). I will use the EMS.

This is the command for creating a new mailbox database:

New-MailboxDatabase -Name "MBDB1" -Server EX10C -EdbFilePath C:\EXDB1\MBDB1.edb -LogFolderPath C:\EXLOGS1
Note: the folders for the database file and the logs files should be created beforehand, either in Window Explorer (not Internet Explorer!) or with the appropriate PowerShell cmdlet, for example:

C:\>New-Item -type Directory -name EXDB1

2. Mount the database.

We then must mount the database:

Mount-Database MBDB1

And there we go!

Note that the "RPCClientAccess" parameter designates the CAS Array created in an earlier post (Wednesday, May 1, 2013).
Get-Mailboxdatabase mbdb1 | fl *rpc*

RpcClientAccessServer : casarray-s1.mynet.lan

3. Move mailboxes to the new Exchange 2010 mailbox database (MBDB1)

We can move all mailboxes in a database with the New-MoveRequest cmdlet:

Get-Mailbox -Database OLD-MBXDB1 | New-MoveRequest -TargetDatabase MBDB1

We can move individual users as follows:

New-MoveRequest aisha.bhari@mynet.lan -TargetDatabase MBDB1

New-MoveRequest -TargetDatabase MBDB1

Another option:

'mynet.lan/Users/Alex.Heyne' | New-MoveRequest -TargetDatabase MBDB1

We can also designate a particular source mailbox

Get-Mailbox | where { $_.Servername -eq "EX1" } | New-MoveRequest -TargetDatabase MBDB1

This would move all mailboxes (still) on the Exchange 2007 server (EX1).

We can even observe the progression of the mailbox move with the Get-MoveRequest cmdlet:


DisplayName    Status                  TargetDatabase
-----------               ------                     --------------
Alan Reid       InProgress                   MBDB1
Alex Heyne    CompletionInProgress MBDB1
Aisha Bhari    Completed                   MBDB1

Once the mailboxes have been migrated, we can remove the mailbox database on the Exchange 2007 server. But how can we be sure that all the mailboxes have been migrated? With the Get-Mailbox cmdlet.

Note: EX10C is the Exchange 2010 server (EX1 is the Exchange 2007 server).

Get-Mailbox | ft servername,name -auto

 ServerName       Name
----------               ----
ex10c      Alex.Heyne
ex10c      Aisha.Bhari
ex10c      Alan.Reid
ex10c      Alannah.Shaw
ex10c      Conference Room X
ex10c      John.Smith
ex10c      Conference Room A

But first, let's verify the name of the mailbox database to remove.:

Name       Server       StorageGroup       Recovery
----             ------            ------------               --------
MBXDB1   ex1                SG1                   False


Then we can remove the mailbox database with the Remove-MailboxDatabase cmdlet:

Remove-MailboxDatabase MBXDB1


Are you sure you want to perform this action?

Removing Mailbox Database "ex1.mynet.lan\MBXDB1".

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

WARNING: The specified database has been removed. You must remove the database file located in C:\SG1DB1\MBXDB1.edb from your computer manually if it exists. Specified database: MBXDB1

This would mark the end of the mailbox migration process.


Wednesday, May 22, 2013

Exchange 2007 (SP3) - ISA - Publish OWA - Export/Import SSL certificates

Someone asked how to install certificates acquired for Exchange 2007 on an ISA 2006 server when publishing services such as Outlook Web Access.

Although ISA is growing old, and though Microsoft intends to discontinue the ISA/TMG product line altogether, there are still organizations that may use the Exchange 2007 - ISA 2006 combination for yet a while.

So, if for some reason the installation of the certificate(s) on the ISA server has not been completed, or needs to be redone, I'll share the procedure I followed below. This post is based notes taken so I could reproduce the same operations if needed a second time, or somewhere else.

First of all, I'm going to set the context for this task.

  • Besides the certificate delivered for my organization, there was an "intermediate certificate" that I had to install on the Exchange server first. Therefore, we have to install two certificates on the ISA server: a) the intermediate certificate and the b) certificate issued to the organization. It is possible that other certificate authorities operate differently, in which case there may only be one certificate to install.
  • Since I saved the intermediate certificate obtained from the certificate authority, I do not need to export it from the Exchange server. In the process described below, I will simply import it as I did on the Exchange server.
  • Although the external domain name on my certificate ( ) is that of a domain used solely for practice, I have proceeded as I usually would when posting "private" information on the Internet: the name has been erased.
  • Lastly, the operations described below take place in the CERTMGR console. You access this console by typing "mmc" (without quotes) in the Start | Run box. You then add the Certificate Manager console, making sure to use the "Local Computer" option. The certificates in question should be placed in the local computer certificate store and not in the personal user store. I will make the assumption that the reader either knows how to perform this operation or is able to find the information online or elsewhere.

Assuming that the intermediate certificate is still available (we could export it from the Exchange server otherwise) there are 3 steps to the process:

  1. Export the organization's certificate from the Exchange 2007 server
  2. Import the intermediate certificate on the ISA 2006 server.
  3. Import the organization's certificate from the Exchange 2007 server

1. Export certificate from Exchange 2007 server

1.a - Export your certificate from the Exchange 2007 server (in the certificate manager console).

On the "Welcome" page, click "Next".

1.b Export the private key. Click "Next" (and on the following screens as appropriate).

1.c Export extended properties.

1.d Enter a password to protect the private key. Click "Next" and "Finish" as needed.

2. Import the intermediate cert on the ISA 2006 server.

2.a On the ISA server, in the CERTMGR.MSC, browse to the "Certificates" subfolder of the "Intermediate Certification Authorities" parent folder. Select "All Tasks", then "Import":

2.b Browse to the location where you placed the intermediate certificate provided by the third party certification authority. You may have to select the "PKCS #7" option to see the certificate.

2.c Add the selected certificate to the Intermediate Certification Authorities store:

Click "Next" or "Finish" as needed.

3. Import the organization's certificate.

3.1 On the ISA server, in the CERTMGR.MSC, go to the Console Root | Certificates (Local Computer) | Personal and right-click on the "Certificates" folder. Select "Import".

3.2 Click "Next" at the Welcome Screen. Browse to the location of the .pfx file (the exported certificate) created in Step 1. Click "Open" and "Next" as needed to import the certificate. 

3.3 Enter the password (entered above when the certificate was exported to the .pfx file in Step 1) and check the "Mark the key as exportable" option. Read the détails to see why this can be useful.

3.4 Place the certificate in the proper store. If you followed the path correctly above, this should be the Certificates store for the "Local Computer" as opposed to a local user (person). Click "Next" and "Finish" as needed.

3.5 The imported certificate should now appear in the folder.

 But does it work? Well, following this procedure, I was able to provide published OWA services (published on ISA) for the initial Exchange 2007 installation and then the Exchange 2010 server after the practice migration.
Of course, a complete ISA or TMG installation is more than just importing certificates. There would be much more to configure for such a project.

Thursday, May 16, 2013

Exchange 2010 - migration from 2007 - Public Folders - PART 1

In Exchange 2013, Public Folders are now part of mailbox databases. I think that's a good thing. I've practiced migrating Public Folders several times, most often manually, using the EMC (create a public folder database on the target server, create replicas, allow replication to take place, remove public folder items on the source server to be decommissioned). In this post, I'll relate my experiences using some of the scripts meant to facilitate Public Folder migration... to an extent.
Here is the procedure followed. And here are the problems encountered.

Preliminary Steps: creating a Public Folder database on the Exchange 2010 server

1. Create a folder (or "directory") for the Public Folder database and log files.

New-Item -type directory -path C:\EXPFDB10

In production, it may be preferable to store the database file and the log files on separate disk arrays. However, improvements in IOPS (disk performance) in Exchange 2010 may make this unnecessary, especially if Public Folders are not heavily used.

2. Create a new Public Folder database

New-PublicFolderDatabase "EXPFDB10" -Server EX10C -EdbFilePath "C:\EXPFDB10\EXPFDB10.edb" -LogFolderPath "C:\EXPFDB10"

3. Mount the Public Folder database

The Public Folder database is not mounted by default at the time of its creation:

Get-PublicFolderDatabase EXPFDB10 -status | fl *mounted*
Mounted         : False

So we need to run the following command:

Mount-Database EXPFDB10

This mounts the Public Folder database:

Get-PublicFolderDatabase EXPFDB10 -status | fl *mounted*
Mounted         : True

Note that in the EMC, it is not necessary to mount the Public Folder database separately provided that you leave the "Mount this database" box checked (it is by default).
At this point, we can see the existing Public Folders by running the following commands on either server (EX1 - E2K7 or EX10C - E2K10). However, only EX1 has a replica of each of the public folders at this time. If we want to migrate to EX10C, we need replicas on both servers for the duration of the migration process.

Get-PublicFolder -Recurse | fl name,replicas

Replicas : {}

Name : PF1-Mail
Replicas : {ex1\SG1\PFDB1}

Name : PF-Contacts
Replicas : {ex1\SG1\PFDB1}

Get-PublicFolder \Non_IPM_Subtree -Recurse | fl name,replicas

Replicas : {}

Replicas : {}
Name : Events Root
Replicas : {ex1\SG1\PFDB1}

Replicas : {}

Name : /o=MYNET/cn=addrlists/cn=oabs/cn=Default Offline Address Book
Replicas : {ex1\SG1\PFDB1}

Name : OAB Version 2
Replicas : {ex1\SG1\PFDB1}

Name : OAB Version 3a
Replicas : {ex1\SG1\PFDB1}

Name : OAB Version 4
Replicas : {ex1\SG1\PFDB1}

Name : EX:/o=MYNET/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)
Replicas : {ex1\SG1\PFDB1}

Name : OWAScratchPad{D8D68C82-417C-4E72-8222-E10945235D4A}
Replicas : {ex1\SG1\PFDB1}

Replicas : {}

Name : EX:/o=MYNET/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)
Replicas : {ex1\SG1\PFDB1}

Name : schema-root
Replicas : {ex1\SG1\PFDB1}

Name : microsoft
Replicas : {ex1\SG1\PFDB1}

Name : StoreEvents{D8D68C82-417C-4E72-8222-E10945235D4A}
Replicas : {ex1\SG1\PFDB1}

Name : globalevents
Replicas : {ex1\SG1\PFDB1}

Name : internal
Replicas : {ex1\SG1\PFDB1}

One comment: I created two test Public Folders, PF1-Mail (mail-enabled) and PF-Contacts. These are Public Folders with content for use by company staff. They are located in the "IPM_SUBTREE". In the Public Folder Management Console (EMC), they are located under the "Default Public Folders" parent folder. The other Public Folders are system folders and are located in the "NON_IPM_SUBTREE". In the PFMC, there are the "System Public Folders".

Most of these folders do not need to be migrated to the Exchange 2010 server. Even if your OAB is distributed by Public Folders, only these folders need to be migrated:

That is, in addition to the public folders that you've created and that contain your data.
Of course, if you do not use Public Folders for OAB distribution, these folders may not even exist (before I selected the Public Folder option for OAB, the "OAB version x" folders did not exist).
Therefore, when showing Powershell output, I will not reproduce the entire System Public Folder structure from now on.
Moving Public Folders with the MoveAllReplicas.ps1 script
This is where I encountered problems.
4. Execute the MoveAllReplicas.ps1 script - to move replicas from EX1 to EX10C 
I executed the following scripts after browsing to the "Scripts" subfolders here:
C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\MoveAllReplicas.ps1 -Server EX1 -NewServer EX10C
5. Change mailbox database settings so the EX10C public folder database is selected:

Set-MailboxDatabase -PublicFolderDatabase 'EXPFDB10' -Identity 'MBDB1'

This associates the new public folder database on the Exchange 2010 server - EX10C - with the mailbox database used by migrated users.

  • A copy of the Public Folder structure is created on EX10C.
  • On each server (EX1 and EX10c), in the properties of each public folder, only the server in question appears to have a replica (EX1 on EX1 and EX10C on EX10C). Note: this is under the replication tab.
  • The content is not moved (mail and contacts in public folders created for this operation).

On EX1:

Get-PublicFolder -Recurse | fl name,replicas

Replicas : {}

Name : PF1-Mail
Replicas : {PFDB1}

Name : PF-Contacts
Replicas : {PFDB1}

On EX10C:

Get-PublicFolder -Recurse | fl name,replicas

Replicas : {}

Name : PF1-Mail
Replicas : {EXPFDB10}

Name : PF-Contacts
Replicas : {EXPFDB10}

This is also the case for the NON_IPM_SUBTREE folders. For concision, I will not reproduce the rather lengthy output here.

But in case you prefer the EMC/GUI, here is what you would see:

There is no replica for EX10C (Exchange 2010) on the EX1 server (Exchange 2007). Therefore, it appears that replication cannot take place. Indeed, as far as I could see, replication was not taking place. Likewise, on the Exchange 2010 server, there was no replica for EX1.

I updated hierarchies, refreshed, waited... nothing seemed to work.


6. Add the Exchange 2010 server as a replica

After a number of attempts with other scripts and cmdlets, I end up adding replicas manually in the EMC on the E2K7 server. Like this:

That worked (and allowed replication to take place).

Get-PublicFolder -Recurse | fl name,replicas

Replicas : {}

Name : PF1-Mail
Replicas : {EXPFDB10, PFDB1}

Name : PF-Contacts
Replicas : {EXPFDB10, PFDB1}
It also worked for the NON_IPM_SUBTREE folders as well.
7. Remove the Exchange 2007 as a Public Folder replica
So now we can remove EX1 as a Public Folder replica for the IPM_SUBTREE folders with this script:
[PS] C:\Program Files\Microsoft\Exchange Server\Scripts>.\RemoveReplicaFromPFRecursive.ps1 -TopPublicFolder "\" -ServerToRemove "EX1"

Note: this script only removes EX1 from the default folders, not the System Folders...
After more problems with scripts and cmdlets, I finally removed those manually in the EMC as well.

Repeat as needed to remove the EX1\SG1\PFDB1 replica on the other public folders.
Now we are ready to remove the Public Folder database on the Exchange 2007 server - EX1 in our example.

At this point, the Public Folder database could not be removed because the "Events Root" subfolder of "System Public Folders" could not be deleted.

The problem is similar to the one discussed here:

I am considering the best way to proceed. Deleting the public folder database in ADSIEdit may resolve the issue in the short term but can also leave traces in Active Directory, something that should be avoided if possible according to others (including an Exchange MVP).


Friday, May 10, 2013

Exchange 2010 - migration from 2007 - Hub Transport - configuration

Here are a number of elements to take into consideration concerning Hub Transport settings.

Send Connector

Although Send-Connector properties exist at the Organizational Level (versus Server Level) and are stored in the configuration partition of Active Directory, it is necessary to modify one Send-Connector setting manually.
I noticed that users whose mailbox was moved to the E2K10 server could not send to external recipients. This was because the E2K10 server must be listed as one of the source servers in the Send-Connector properties. In the EMC, this can be configured under the "Source Server" tab.


In the EMS, this is what displays before the E2K10 server is added to the list of source servers:

Get-SendConnector | fl sourcetransportservers

SourceTransportServers : {ex1}

This is the cmdlet that will add the E2K10 server to the list:

Set-SendConnector -Identity 'MYNET-SendConn-1' -SourceTransportServers 'ex1','EX10C'

Now both servers are in the list:

Get-SendConnector | fl sourcetransportservers

SourceTransportServers : {EX10C, ex1}

Receive Connector

In Exchange 2010, by default, the default Receive-Connector will refuse messages from anonymous senders. Since most or all users outside the Exchange organization qualify as "anonymous", this setting must be modified if we want users to receive mail from external or outside senders.

Let's compare the Receive Connector settings on the E2K7 and the E2K10 servers:

Exchange 2007 server

Get-ReceiveConnector "ex1\Default EX1" | fl *permission*

PermissionGroups : AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers

Exchange 2010 server

Get-ReceiveConnector "Ex10C\Default EX10C" | fl *permission*

PermissionGroups : ExchangeUsers, ExchangeServers, ExchangeLegacyServers

In the EMC, we would see this:

The E2K10 server lacks the "AnonymousUsers" permission group. We can correct this with the following command:

Set-ReceiveConnector "EX10C\Default EX10C" -PermissionGroups "AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers"

Now the E2K10 server has the correct Receive-Connector permissions:

Get-ReceiveConnector "Ex10C\Default EX10C" | fl *permission*

PermissionGroups : AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers

Monday, May 6, 2013

Exchange 2010 - migration from 2007 - Offline Address Book

The Offline Address Book - from Exchange 2007 to Exchange 2010

The Offline Address Book (OAB) contains address lists that Outlook users can access when they are "offline" (not able to access the Exchange mail server). The OAB usually contains an offline copy of the Global Address List (GAL) or various custom address lists organized by city, region or some other criteria.
If we intend to remove the Exchange 2007 server(s) after a transition to Exchange 2010, we will have to move the OAB generation process to the new Exchange 2010 server.

Note: the OAB generation and distribution process includes the creation of the OAB on the Mailbox server and then its distribution to clients via the Client Access Server by either Public Folder distribution, web-based distribution or both. Since Exchange 2007, web-based distribution is the preferred method. Outlook versions 2007 and above use the web-based method. It is only necessary to retain the Public Folder method if there are (still) Office 2003 clients in the organization.

1. Change the OAB generation server.

I'll perform this as the first step of the move although it could be performed later. It is necessary if we plan to remove the Exchange 2007 server.

1.a Note the existing location:

Get-OfflineAddressBook | fl *server*
Server : ex1

[output edited]

1.b Execute the following command to change the OAB generation server:

Move-OfflineAddressBook "Default Offline Address Book" -Server EX10C
Note: EX10C is the name of the Exchange 2010 server.

1.c We can update the Offline Address Book as well:

Update-OfflineAddressBook "Default Offline Address Book"

Now there's one more step: although the Exchange 2010 server is now the "OAB generation server". We still need to configure it as a "distribution point" for the OAB.

2. Designate the Exchange 2010 server as a distribution point for the OAB.

Set-OfflineAddressBook "\Default Offline Address Book" -VirtualDirectories "EX10C\OAB (Default Web Site)"

Note: this command, as entered above, will remove the Exchange 2007 server as a OAB distribution point. If we want to maintain this server as a distribution point we can add the following at the end of the command (where "ex1" is the name of the Exchange 2007 server):

,"ex1\OAB (Default Web Site)"

Please note the comma separating the two entries.

One last remark: remember to designate an Offline Address Book for the mailbox database on the Exchange 2010 server if none already is.

I noticed that one of my test users could not download the OAB in Outlook 2010.

If this happens, first verify that the mailbox database holding the mailbox of the user is associated with an Offline Address Book. In the EMS, we can execute the following command:

Get-mailboxdatabase MBDB1 | fl *off*

OfflineAddressBook :

There is no OAB listed!

Note, in comparison, that the Exchange 2007 mailbox database (named MBXDB1 - note the "X" - that's simply how I named them...) has an OAB associated with it:

Get-mailboxdatabase MBXDB1 | fl *off*

OfflineAddressBook : \Default Offline Address Book

If you prefer the EMC, the parameter can be configured in the mailbox database properties, under the "Client Settings" tab.

Otherwise, the problem can be corrected in the EMS with the following command:

Set-mailboxdatabase MBDB1 -OfflineAddressBook "Default Offline Address Book"

Here is the result:

Get-mailboxdatabase MBDB1 | fl *off*

OfflineAddressBook : \Default Offline Address Book

Note: even after correcting the configuration, the OAB could not be downloaded the very same day. However, it could be downloaded the following day. This is most likely because the OAB distribution and publishing process had not yet completed at the mail server. The complete process can require approximately 24 hours.


Saturday, May 4, 2013

Exchange 2010 - migration from 2007 - SSL certificates

 Preliminary remarks
Certificates play a key role in authenticating and securing user access to Exchange via HTTPS. When we configure the Client Access Server (CAS), it is generally recommended to obtain a SSL certificate from a 3rd party certificate authority like Comodo, Digicert, GoDaddy, or Verisign. The certificate obtained from the certificate authority is 1) imported and 2) enabled on the Exchange server for the appropriate services, "IIS" and "SMTP" for example.

Often, the certificate for the organization comes with an intermediate certificate that must be imported into the local computer certificate store of the server before the organization certificate will function.
Many sources available on the Internet explain this process. In particular, certificate authorities usually provide directions for the installation of their certificates.
Note: in Exchange 2007, certificate operations (import, enable, etc.) could only be performed at the command line (in the "EMS"). Exchange 2010 and 2013 also provide a GUI for this type of operation.
When moving from one Exchange server to another, in the context of a migration to a newer version or simply the replacement of a server, it can be advantageous to move the certificates from one to other.
Yes, an organization could always request another certificate from the certificate authority using a brand new certificate request created on the new server. However, this would entail a brand new invoice from the certificate authority as well.
In fact, depending on the certificate authority and type of certificate issued, the certificate originally acquired may not function on any other server than the one on which the original request was created. In other cases, though, this is possible. One common scenario is exporting the certificate from the Exchange server so it can be imported on an ISA or TMG server that pre-authenticates Exchange users at the perimeter of the network.
So, in the following lines, I'll concentrate on the procedure to follow when migrating from Exchange 2007 to Exchange 2010.

Export the existing certificate(s) from the first server

I have both an intermediate certificate provided by the certificate authority as well as the certificate delivered for my organization. Since I kept a copy of the original intermediate certificate, I will not need to export it from the Exchange 2007 server. So I'll focus on exporting the certificate for my organization and then the import operations on the Exchange 2010 server.

Exporting the Exchange certificate (Exchange 2007 server)

The organization's certificate is exported using this command in the EMC:

Export-ExchangeCertificate -Thumbprint 11111a22222222b33333 -BinaryEncoded:$True -Path C:\E2K10-Cert-Export\export-for-e2k10.pfx -Password (Get-Credential).Password

Note: yes, I modified the thumbprint for both security and concision. You might also be wondering "But wait! Where did you find that thumbprint?". I executed the Get-ExchangeCertificate cmdlet and located the proper certificate among those listed. In my case, there were only two certificates (one was the "self-signed" certificate). So I selected the other.
Useful trick: if you use OWA, you can find the thumbprint of the current certificate by examining the certificate properties. In Internet Explorer, for example, there is a padlock icon near the URL bar. If you click on this padlock, you can display the certificate properties.

Otherwise, if you want détails on each of the parameters, you can consult the Micosoft documentation on the Export-ExchangeCertificate cmdlet:


Import the certificates into the second server

Intermediate certificate

Note: I have created a custom MMC named CERTMGR.msc that targets the computer certificate store of the local computer. Normally, when you open the CERTMGR.msc MMC, it targets the user certificate store.

I have also, for this example, placed the necessary files in the C:\Certs folder.

1. Click on the Start Menu and open CERTMGR.msc

Start | All Programs | Administrative Tools | CERTMGR.msc

2. Go to the "Intermediate Certification Authorities" folder and then to the "Certificates" subfolder. Right-click and select "All Tasks, Import".

3. Click "Next" on the "Welcome" page to proceed to the screen where you can browse to the certificate file to be imported. Select the file type PKCS #7 (for .p7b files) and select the certificate.

Click "Next". Make sure the "Intermediate Certification Authorities" store is targeted.

Click "Next", confirm the operation and then "Finish". You can confirm the success (or failure) of the operation by verifying the certificate has been added to the local computer certificate store:


Exchange certificate (provided specifically for your organization)

Finally, we must import and enable the Exchange certificate with the domain names used by our organization, provided by the 3rd party certificate authority. Since I'm most familiar with the command line for this type of operation, that's what I'll use.
Note: the files mentioned in the examples must be placed in the indicated locations for the cmdlets to function. Otherwise, change the commands to reflect the location of your files.

1. Import the certificate.

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

2. Enable the certificate.

Enable-ExchangeCertificate -Thumbprint 11111a22222222b33333 -Services "IMAP, IIS, POP, SMTP"

Well, does it work?

It did for me. I was able to login as two different test users whose mailboxes were moved to the Exchange 2010 server, was able to open both OWA and Outlook without any prompts or error messages about certificates.

Wednesday, May 1, 2013

Exchange 2010 - CAS Array

OK. First blog. Subject: the CAS Array or "Client Access Server Array".

Questions about the CAS Array appear quite frequently on the Microsoft Exchange (2010) Technet forums. I emphasize "2010" because the CAS Array is unique to Exchange 2010. Exchange 2007 had no such concept and with Exchange 2013 it has simply been eliminated.

So what is the CAS Array? Contrary to something like a "RAID Array" composed of tangible physical objects - hard drives - the CAS Array is an object in Active Directory, comparable in that respect to a user, contact, group or site.

I had to dissect this concept before understanding it myself:

1. CAS Array = Active Directory object

2. This object links two elements: the "RPC CAS Service" with a DNS name.

3. The DNS name, in turn, is associated with an IP address.

  • As a simple Active Directory object, the CAS Array can be the foundation for a RPC ( = Outlook connections) load-balancing or high availibilty solution but cannot provide any sort of load-balancing or high availability in and by itself.

  • However, the IP address associated with the DNS record can designate a Windows NLB cluster or a hardware load-balancing device. It is this cluster or device that would actually provide the load-balancing.

  • It is considered best practice to configure a CAS Array even when you only have a single Exchange 2010 server. This can facilitate the replacement of one Exchange server by another, since Outlook client settings, configured by Autodiscover, designate an object in Active Directory rather than a specific physical server.

It seems to me that this is quite similar to DFS (Distributed File System) in the file server world where one can map drives to an object in Active Directory rather than to the name of a particular server.  

  • Note that unlike DAGs (Database Availability Groups), a CAS Array cannot span two or more sites.

  • The CAS Array has to do with Outlook, not OWA, not ActiveSync and not Outlook Anywhere (that uses HTTPS - in which the RPC data is encapsulated).

  • The name of the CAS array does NOT have to be included among the names on any SSL certificate. SSL has to do with IIS. Outlook RPC connections have nothing to do with IIS and SSL. This comes up in the Technet forums quite often... and the answer is always NO

Now, my objective is not to provide an exhaustive presentation on the CAS Array. There are plenty of existing resources on the subject and I'll provide some links below. So I'll just present in the most simple and concise manner I can, the procedure for creating a CAS Array.

How to create a CAS array

A CAS Array can be configured in a minimum of three steps - or even two!

1. We create CAS Array object in Active Directory

New-ClientAccessArray -Name CasArray-S1 -Fqdn casarray-s1.mynet.lan -Site Default-First-Site-Name

The command above names the CAS Array "CASArray-S1" and sets its FQDN to casarray-s1.mynet.lan. MYNET.LAN is fictional domain name used for practice.

Currently we have only one Active Directory Site. However, since CAS arrays cannot span sites, and since my network might have more sites in the future, I will create a site-specific CAS Array from the very start.

2. We create a DNS record for the CAS Array pointing to the IP address of my CAS server.

dnscmd dc2.mynet.lan /recordadd mynet.lan casarray-s1 A

Note: this is for the present network configuration. If I had - or add - a load balancer, then I would have the record point to the IP address of the load balancer. I used the command line to create the DNS A record in question but it is, of course, possible to use the dnsmgmt.msc GUI. DC2 is the name of the domain controller / DNS server.


3. Configure the RPCClientAccessServer attribute on mailbox databases.

If we configure the CAS Array before creating a mailbox database, the RPCClientAccessServer attribute of the database should be configured correctly and automatically without further action.

Note: if no CAS Array is configured, the attribute is set to the FQDN of the CAS (in a single CAS scenario).

If we need to adjust the attribute on an existing database, we can execute the following command in the EMS:

Set-MailboxDatabase MBDB1 -RpcClientAccessServer casarray-s1.mynet.lan

Here is an example of settings before and after the reconfiguration of the attribute:

[PS] C:\>Get-MailboxDatabase MBDB1 | fl *rpc*

RpcClientAccessServer : EX10C.mynet.lan

[PS] C:\>Get-MailboxDatabase MBDB1 | Set-MailboxDatabase -RpcClientAccessServer casarray-s1.mynet.lan

[PS] C:\>Get-MailboxDatabase MBDB1 | fl *rpc*

RpcClientAccessServer : casarray-s1.mynet.lan


There we go! In the future, the CAS can be changed and Outlook client settings will not have to be adjusted individually - on one condition: that the CAS Array is created before the mailbox database.

Further configuration, such as establishing a static IP endpoint, is possible if desired.


Understanding RPC Client Access - Technet.

Exploring Exchange 2010 RPC Client Access service

Demystifying the CAS Array Object

Exchange 2010 Technet Forum