Master Exchange 2007

powershell, automation & more…

Archive for the ‘Client Access’ Category

This category contains cmdlets and scripts that relate to the management of the Client Access Server role within Exchange 2007/2010.

Exchange 2003 to Exchange 2007 transition migration using Exchange management shell cmdlet commands

Posted by shauncroucher on January 6, 2010

E2000\2003 – E2007 Transition ‘maximising EMS’

 Document Purpose

The purpose of this document is to run through the steps necessary to fully transition Exchange 2003 to Exchange 2007 maximising the use of the Exchange Management Shell (EMS).

Where it is easier to use the Exchange Management Console (EMC) I will show the steps using this tool.

Test Environment Used

  1. The Flexible Single Master Operation (FSMO) role holders were not changed or migrated from Windows 2003.
  2. The Exchange 2003 server is installed on the server hosting all 5 FSMO roles. This is not best practice in a production environment, but will suffice for the purposes of this document. Note here that you cannot run the ‘/Prepare switches’ prerequisite tasks on a computer that has Exchange 2003 installed. This may mean you need to promote a new DC to run the initial AD preparations.
  3. Single forest \ single domain environment
  4. The Exchange 2007 server introduced will be a 2008 DC for the domain and will be running Windows 2008 operating system. Note in a production environment it is best practice to not install Exchange 2007 on a Domain controller
  5. The Windows 2008 AD preparation commands have been run to upgrade schema in order to allow the introduction of a Windows 2008 DC. Includes adprep /forestprep  /domainprep etc


Active Directory and Environment Preparation


  1. Check Exchange 2003 is running in Native Mode by opening the Exchange System Manager, right click the ‘Organisation’ –> properties.


  1. Check the server holding the schema master role is running at least Windows server 2003 SP1. The schema master also needs .NET framework 2.0 and Powershell v1.0 installed.
  2. All DC’s should have the same ‘locale’ as the OWA Client (see
  3. The Domain functional level should be Windows 2000 minimum.
  4. You should run the Exchange Best Practices Analyser (ExBPA) Exchange 2007 Readiness check to ensure the environment is ready for Exchange 2007.

Exchange 2007 Specific Preparation Switches

The following ‘prepare’ commands will automatically be performed on the introduction of the first Exchange 2007 installation. I list them here because this document focuses on using shell commands for the transition, and I believe this also gives more control over each step and therefore the transition as a whole. Use the from the Exchange 2007 installation media for these tasks. Use the freely downloadable 32bit version of Exchange 2007 to update the schema on a 32 bit schema master computer.

If you are installing Exchange SP2 to run the switches you will need Windows Installer 4.5 installed

Note you cannot run these commands on a computer running Exchange 2003. The setup program will notify you there is a previous version of Exchange server already running.

1. /PrepareLegacyExchangePermissions

2. /PrepareSchema

3. /PrepareAD

The ‘PrepareAD’ switch should be run in the root domain. This will create a new Administrative group and routing group for Exchange 2007. It will also create the ‘Microsoft Exchange Security Groups’ (for use with Exchange 2007) OU in the root domain.

Before /PrepareAD:

After /PrepareAD:  

4. /PrepareDomain or /PrepareAllDomains

/PrepareDomain can be run for each domain that has an Exchange 2007 server implementation. You can run /PrepareAllDomains to run the tasks automatically on all domains within the forest.

Installing Exchange 2007 ‘Critical Three’ Prerequisites

The following commands can be run from the Windows 2008 command prompt to install all the necessary prerequisites for the three minimum critical Exchange 2007 roles we will be installing for this scenario – Mailbox, Client Access and Hub Transport. For other switches please see the references section at the end of this document.

ServerManagerCmd -i PowerShell

ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-ISAPI-Ext

ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console

ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Digest-Auth

ServerManagerCmd -i Web-Windows-Auth

ServerManagerCmd -i Web-Dyn-Compression

ServerManagerCmd -i RPC-over-HTTP-proxy

Installing Exchange 2007 ‘Critical Three’

From the command prompt run the following command from the Installation media source: /m:install /role:M,H,C /enablelegacyoutlook /legacyroutingserver:MACHESTER

In this example, the legacy Exchange 2003 server is called MACHESTER. You must specify this so that a routing group connector is setup to allow for mail flow between the legacy routing group and the Exchange 2007 routing group that is created for legacy interoperability only.

In this example, I have also supplied the switch /enablelegacyoutlook. This will allow for Outlook 2003 and earlier clients to still use the Exchange organisation. Omit if all clients are Outlook 2007 and above.

Once Exchange 2007 is installed you should use the E2007 EMC or EMS for configuration of organisation wide settings, not the E2003 ESM.

E2003 Recipient Policies –> E2007 Accepted Domains & Email Address Policy

The installation will find entries from the Exchange 2003 Recipient Policies and attempt to import them into Exchange 2007. There are two sections in Exchange 2007 ‘Accepted Domains’ and ‘Email Address Policies’. You should check that you have ALL the accepted domains listed in Exchange 2007 first. You may find you need to create any that have not been imported.

From the Exchange Management Shell run the following:


This will show you all domains on the Exchange 2007 system. If any are missing add them here using New-AcceptedDomain. (see references for commands) or use the EMC –> Organisation Config –> Hub Transport –> Accepted Domains


This will show you the email address policies imported from Exchange 2003. If you get any errors shown here such as:

WARNING: The SMTP address template ‘’ is invalid because it references a domain that is not an accepted domain.

Ensure the domains are listed as an Accepted Domain. This can happen if the domain is not ticked in Exchange 2003 Recipient Policies prior to transition. (ticking the domain tells Exchange 2003 to populate user objects with an SMTP proxy address for the domain).

If you try to open the Email Address Policy using the EMC, you will get a prompt as below:

This is because EAP’s generated from legacy systems need to have their filters upgraded.

Use the EMS command as below:

Get-EmailAddressPolicy | ?{$_.RecipientFilterType -eq “Legacy”} | ft Name,Rec*Type

This command will return the name of all EAP’s that require updating.

You can run the upgrade on all these EAP’s automatically by running the following (note you will no longer be able to manage these using E2003 after running the command):

Get-EmailAddressPolicy | ?{$_.RecipientFilterType -eq “Legacy”} | Set-EmailAddressPolicy -IncludedRecipients AllRecipients

Note: Check that all the domain names you need applied to recipient objects are listed in the email address policy. If you had any that generated errors earlier (added as Accepted Domains), you may need to add them in the Email Address Policy too.

Replicating Public Folders (PF)

There are a few different ways to move the public folders content from the Exchange 2003 server over to Exchange 2007. For the purposes of this document we will use the shell script MoveAllReplicas.ps1. This will move the PF content from Exchange 2003 to Exchange 2007.

Folders that are not created by users and do not hold ‘user created’ content are known as system folders or NON_IPM_SUBTREE data folders. Most importantly, to support Outlook 2003 and earlier clients you will need to replicate the SCHEDULE+ FREE BUSY system folder and the OFFLINE ADDRESS BOOK system folder. Both are public folders and this information will be needed to support legacy Outlook 2003 and older clients.

Note that you should already have the public folder structure (or hierarchy) in the Exchange 2007 database, this replicates automatically. You can check that the folder structure is in place by using the Exchange 2007 Public Folder Management tool (if you have at least SP1 installed) or by using the shell.

Get-PublicFolder \ -recurse | ft Name,Replica

If you see the structure you are good to go with the MoveAllReplicas.ps1 task which will move the data from the Exchange 2003 to the Exchange 2007 server.

From Exchange 2007 EMS:

cd $exscripts

MoveAllReplicas.ps1 -server MACHESTER -newserver THREEROLE

One of the easiest and clearest ways to see the status of the PF replication is to monitor the public folder instances until all are moved over to the Exchange 2007 database. You can see Public Folder Instances for both servers using the Exchange 2003 ESM.

You can also evaluate the current replica list of all NON_IPM_SUBTREE PF’s by using the shell command. Below is the list prior to running the MoveAllReplicas.ps1 command:

Get-PublicFolder \NON_IPM_SUBTREE -recurse  | ft Name,Replicas

Once all the Public Folder Instances have been moved to the Exchange 2007 server, you can dismount the Exchange 2003 public folder and test that users are still able to see Free\Busy info. Once satisfied (and you have a backup of course?!) you can delete the E2003 public folder database using the Exchange 2003 ESM and then follow the prompts to configure existing E2003 mailbox users to use the Exchange 2007 Public folder database.

Move Mailboxes from Exchange 2003 Mailbox Store to Exchange 2007 Mailbox Database

There is a straightforward command to move the legacy mailboxes to Exchange 2007. The Move-Mailbox cmdlet. Run this and specify your tolerance for message corruption etc during the move process.

Get-Mailbox <SERVERNAME> | Move-Mailbox -TargetDatabase <NAME OF TARGET DB> -BaditemLimit <NUMBER> -MaxTreads 10

Note the -Maxthreads which will allow you to move more than the default 4 mailboxes at a time. This is something that is not possible using the Management Console. If used, you can specify the number of mailboxes to move simultaneously.

Confirm the cmdlet and the mailboxes should now move over to the new database. The Move process can also be performed just as easily using the Exchange Management Console if you prefer.

You should find that once the process completes that you have no mailboxes that show as ‘Legacy Mailboxes’, they should all show as ‘User Mailboxes’

E2003 SMTP Connectors  –> E2007 Send Connectors

All the public folders and mailboxes are now hosted on Exchange 2007 so it is time to remove the server from mail transfer responsibilities. At this time, the mail will be flowing from the outside to the Exchange 2003 server and then relayed onto the Exchange 2007 server. We will be looking at having the mail travel directly to the Exchange 2007 server.

Receive Connector

You will need to make sure that the server that will be responsible for accepting internet mail is configured to allow ‘Anonymous users’. By default, it will not accept anonymous connections and therefore cannot be used for accepting internet mail.

To check this using the Exchange Management Shell you can use the following command:

Get-ReceiveConnector | fl Identity,PermissionGroups

If it does not display ‘AnonymousUsers’ for the Default Connector (or another connector you have setup for Internet mail) then you will need to set this. It is generally easier to do this using the console, so drop into the console, and then navigate to Server Config –> Hub transport –> Receive Connector –> Default –> Properties –> Permission Groups –> Select Anonymous users.

You can leave any other group ticked if you still wish to allow for outside authentication or legacy server authentication. This may be a security risk for SPAM attacks so do so with caution. The minimum required to accept inbound mail is ‘Anonymous Users’

Once this is done, you can direct port 25 traffic to the Exchange 2007 server. Test this using your favourite email client or by running a telnet test on port 25 (see

Send Connector

You should ensure that you have a send connector configured for outbound delivery. You can use the Get-SendConnector cmdlet to see if you currently have a send connector configured.

You should get a connector returned which shows that it is responsible for AddressSpaces SMTP:* and Enabled TRUE. If you do not get this then I would advise creating one through the Exchange Management Console. Navigate to Organisation Configuration –> Hub Transport –> Send Connector –> New send connector. Set up a Internet type connector with address space of * and either use DNS if you send directly or use smarthost if you currently use a smarthost for your delivery. You can refer to your current Exchange 2003 SMTP connector to see if you have a smarthost configured, to do so open Exchange System Manager –> Connectors –> SMTP connector – if you see a connector here that relates to outgoing mail or SMTP, then this may be responsible for outgoing mail. Go to properties and the front page will show if you have a Smarthost entry. If you do, you are using a smarthost. If this is blank, go to step 2.

2) Next, check your SMTP bridgehead does not specify a smarthost entry. Open Exchange System Manager -> Servers –> [SERVERNAME] -> Protocols -> SMTP –> Default SMTP virtual server –> Properties –> Delivery –> Advanced –> Smarthost.

If there is an entry here, you are using a smarthost. If it is blank then you are using DNS.

OK, now we have a send connector configured, disable SMTP on the Exchange 2003 server by going to a command prompt and typing:

net stop SMTPSVC

Test if you are able to send an outbound mail to an outside address.

You can now remove the routing group connector that was automatically created to allow mail flow between the two routing groups. To do so use the Remove-RoutingGroupConnector.

Use the Get-RoutingGroupConnector, and you should see routing group connectors responsible for the Exchange 2003 routing group and Exchange 2007 routing group. You can use the following command to remove these connectors from the organisation:

Get-RoutingGroupConnector | Remove-RoutingGroupConnector

De-commission the Exchange 2003 server

You are now in a position to de-commission the Exchange 2003 server. You may wish to leave your Exchange 2003 in place for a period of time to allow your Outlook clients to automatically adjust to the re-homing of their mailboxes. Once you are happy this has taken place you can decommission.

Although Exchange 2007 does not use Recipient Update Services (RUS), you will still need to transfer this to the Exchange 2007 server before you can decommission the server. To do so, navigate to Recipient Update Services and for both entries (Enterprise and the domain) go to properties and select the Exchange 2007 server from the Exchange server browse button.

Now you can use Add Remove Programs (Start –> Run –> appwiz.cpl) to access the Exchange 2003 setup program and remove Exchange 2003 from the organisation completely. Note that you may require the installation media to complete the removal process.

Copyright Shaun Croucher 2010

References – Transition Exchange 2003 – 2007 Guide – OWA issue locale – Preparing AD for Exchange 2007 – Installing Exchange 2007 Prerequisites using shell commands – New-AcceptedDomain cmdlet – EAP and Filter Upgrades – Free\Busy and Availability Info – Move PF Replicas – Move Mailboxes – Telnet test port 25

Posted in Client Access, Global\General, Mailbox\Recipient, Public Folder, Transport | 1 Comment »

Default Authentication Settings Exchange 2007 IIS Application & Virtual Directories

Posted by shauncroucher on November 9, 2009

You can find these settings in IIS7. Select each Virtual Directory and then IIS section –> Authentication. Listed are the VD’s that are enabled by default with a vanilla install of Exchange 2007.

Note these settings are from Exchange 2007 Standard SP2 Installation, but should be the correct settings for all versions of Exchange*.


SSL Settings:

All the Virtual directories are set to Require SSL with 128bit except for OAB that DOES NOT require SSL and RpcWithCert which DOES NOT require 128bit (it DOES require SSL though).

* Unchecked on SBS 2008 at this time.


Posted in Client Access | Leave a Comment »

Exchange 2007 Internal and External URL \ URL’s – Autodiscover Availability IMAP POP3 OOF OAB

Posted by shauncroucher on October 17, 2009

Exchange 2007 stores quite a few URL’s for the new Autodiscover feature and for other services such as the Availability service, IMAP, POP3, OOF and OAB.

In total there are at least 7 powershell commands that can be used to display the URL’s for Exchange.

If you are aware of any I have missed off the list please leave me feedback and I will update this post.

This article is designed to show you which commands you will need to find all the URL’s in your organisation. The script will run for ALL servers in your organisation where appropriate.


Get-WebServicesVirtualDirectory | fl Id*,*url*

Get-OwaVirtualDirectory | fl Id*,*url*

Get-ClientAccessServer | fl Id*,*uri*

Get-OabvirtualDirectory | fl Id*,*url*

Get-ImapSettings | fl Id*,*509*,*url*

Get-POPSettings | fl Id*,*509*,*url*

Get-UMVirtualDirectory | fl Id*,*url*

The vast majority of these are self explanatory. One that is often forgot are the POP and IMAP URL’s, both for the additional CAS calendaring services that are available by setting the ‘OwaServerUrl’ value.

References: Security warning when you start Outlook 2007… – How to configure the Web Services URLs that are used by Outlook 2007 – More on Exchange 2007 and certificates – with real world scenario

Posted in Client Access | Leave a Comment »

Create UC SAN Private CA issued certificate to replace self signed certificate Exchange 2007

Posted by shauncroucher on September 20, 2009

This guide is intended to help you setup your own Certification Authority, and issue a UC certificate for Exchange 2007 testing purposes \ lab environments.

It also uses powershell cmdlets wherever possible, rather than using the Windows 2008 or Exchange 2007 GUI interfaces.

When and why you shouldn’t use this guide

The reason I say this should be used for lab environments is because you really should use a commercial and trusted third party supplier of SSL certificates with Exchange 2007, it will save you a lot of time and aggravation over using a ‘Private CA’ certificate process. The problem with self signed certificates and Private CA issued certificates is that they are NOT TRUSTED by client devices, and so for the devices to use SSL successfully you have to import the SSL certificate or add the CA to the list of ‘trusted root certificates’. This can be achieved using a GPO for domain joined PC’s (this is outside the scope of this document) or you have to manually install the certificate on non-domain devices – PC’s and mobile devices alike.


Windows 2008 Standard

Exchange 2007 (tested to work this SP1 and SP2)

Step 1 – Install the root certification authority role:

You will need to install the server role called ‘Active Directory Certificate Services’.

Go to ‘Server Manager’ –> ‘Add Roles’ wizard –> Choose ‘Active Directory Certificate Services’ –> Next –> Choose ‘Certification Authority’ only (don’t need the other role services) –> Enterprise –> Next –> Root CA –> Next –> Create a new private key –> Keep all defaults here (2048 length / RSA Sha1 key) –> Keep Common Name as default –> Next –> Valid for 5 years should be fine as this is just for testing, change if you wish –> Next, Finish

You should now have a Certification Authority from which you can process certificate requests. Next is on to creating the certificate request for exchange 2007.

Step 2 – Create the UC \ SAN certificate request

I would highly recommend navigating to the Digicert website and making use of their ‘free to use’ tool for creating a Exchange 2007 UCC cmdlet.  (at time of writing this could be found at

All in all you will need to include the ‘fully qualified domain name’ as specified for external access. The server NetBIOS name and distinguished name for internal access PLUS the autodiscover reference (autodiscover is a tool used for automating the configuration of Outlook 2007 clients and providing the URLs necessary for the availability service etc, this is outside the scope of this document).

So, if you wish your external users to access the service using and your internal domain name is domain.local with a server name of ‘server’ then you would want the following as SAN names:



Note: Make sure you include the common name of the certificate as a ‘Subject Alternative Name’ as well. In the example this is

Alternatively you can use the New-ExchangeCertificate cmdlet as below:

New-ExchangeCertificate -GenerateRequest -Path c:\domain.csr -KeySize 2048 -SubjectName “c=GB, s=TheState, l=TheCity, o=TheOrgName, ou=TheDeptName,” -DomainName, server.domain.local, server, -PrivateKeyExportable $True

Note that we are using the -GenerateRequest here which basically tells exchange to create a ‘request’ for a CA to process rather than creating a self-signed certificate. This is an important distinction.

Then we use the ‘certreq’ command to import the request file and generate us a certificate. (Note that you could try this by using the ‘Certification Authority’ directly but will be prompted with an error, because standalone CA’s do not use certificate templates – see For this reason, we can bypass the problem by using either the web enrollment OR the certreq.exe command as below.

certreq.exe -submit -attrib “CertificateTemplate:WebServer” c:\domain.csr.

This will generate a .cer file for us to import into Exchange.

Step 3 – Process the certificate request file

Using the generated .cer, go into Certificate Authority MMC (Start –> Search –> type ‘Certification Authority’) –> Go to issued –> Go to certificate -> Open –> Details –> Copy to file –> Cryptographic message syntax standard -PKCS #7 Include all certificates in the path –> Export –> Export as C:\domain.p7b.

Now with the .p7b you can use this with the Import-ExchangeCertificate and Enable-ExchangeCertificate commands.

Step 4 – Importing the certificate and attaching the relevant services

Open up Exchange management shell and type:


This will show you all the certificates on the system with their associated thumbprint. The thumbprint of the certificate uniquely identifies it. Each certificate will have a unique thumbprint even if all other details are the same.


Import-ExchangeCertificate -Path C:\domain.p7b

Once the certificate has been imported, you can attach the certificate to the relevant services.

The services are as follows:

IMAP – For secure IMAP services

POP – For secure POP services

UM – For Unified messaging

IIS – For autodiscover \ owa \ oab and other web related services

SMTP – For TLS communication

None – To set a certificate to have no associated services.

Use Get-Exchangecertificate command and record the thumbprint for the new certificate. you can right click shell window –> Mark –> Highlight thumbprint –> Hit Enter to place the thumbprint in the clipboard.

Enable-ExchangeCertificate -Thumbprint <your thumbprint> -services IIS, POP, IMAP, SMTP,UM

That is all that is required on the server side. You should now be able to run Get-Exchangecertificate and see all services attached.

Step 5 – Importing the ‘certificate authority’ to client devices

There are a number of ways to install the certificate to devices. The method describes below works for me and should work for you.

On the server –> Go to IE –> Internet Options –> Content –> Certificates –> Go to Trusted Root Certificate Authority –> Export –>

Cryptograpyhic Message Syntax Standard (.P7B) + Include all certificates in the path –> Export.

Then on the computers you need to TRUST the ‘certificate authority’ certificate, simply IMPORT this certificate into Trusted Root Certification

Authority using Internet Explorer Import command (make sure it is imported into Trusted Root Certification Authority when prompted by Import routine).

For mobile devices, copy the file to the Windows Mobile device, and then using the phone, select the certificate file and allow this to import.


After this you should be able to go to the URL for OWA and not get ANY certificate warnings.

You should be able to use Outlook Anywhere without any certificate warnings, and Activesync with SSL should work fine too.

As long as you have created the public DNS record, autodiscover will work too when it returns the https:// URL’s.

Feedback always welcome. Hope you found the article useful.

Based on information found in the following articles: – Active Directory Certificate Services Step-by-Step Guide – Understanding the Self-Signed Certificate in Exchange 2007 – Replacing the Exchange 2007 Self-Signed Certificate – You may receive a “The request contains no certificate template information” error message when you submit a CSR to an enterprise CA”– Enable-ExchangeCertificate

Posted in Client Access, Transport | 6 Comments »

Category Time of Birth

Posted by shauncroucher on August 3, 2009

Posted in AntiSpam, Client Access, Global\General, Mailbox\Recipient, Miscellaneous, Public Folder, Transport | Leave a Comment »