Master Exchange 2007

powershell, automation & more…

Archive for September, 2009

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.

Prerequisites:

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 https://www.digicert.com/easy-csr/exchange2007.htm)

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 mail.domain.com and your internal domain name is domain.local with a server name of ‘server’ then you would want the following as SAN names:

mail.domain.com

autodiscover.domain.com

server.domain.local

server

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

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, cn=mail.domain.com” -DomainName mail.domain.com, server.domain.local, server, autodiscover.domain.com -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 http://support.microsoft.com/kb/910249. 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:

Get-ExchangeCertificate

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.

Type:

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.

Conclusion

After this you should be able to go to the URL for OWA https://mail.domain.com/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 autodiscover.domain.com 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:

http://technet.microsoft.com/en-us/library/cc772393(WS.10).aspx – Active Directory Certificate Services Step-by-Step Guide

http://technet.microsoft.com/en-us/library/bb851554.aspx – Understanding the Self-Signed Certificate in Exchange 2007

http://www.exchangeinbox.com/article.aspx?i=127 – Replacing the Exchange 2007 Self-Signed Certificate

http://support.microsoft.com/kb/910249 – You may receive a “The request contains no certificate template information” error message when you submit a CSR to an enterprise CA”

http://technet.microsoft.com/en-us/library/aa997231.aspx– Enable-ExchangeCertificate

Posted in Client Access, Transport | 6 Comments »

Managing Public Folder Client Access Permissions – Exchange 2007 MSH / EMC (Exchange Management Shell)

Posted by shauncroucher on September 6, 2009

There are a number of ways to add permissions to public folders using the MSH (Exchange Management Shell).

Some of the common and useful commands for client permissions are as follows:

Add-PublicFolderClientPermissions -Identity <PublicFolder> -User “Username” -AccessRights <Right>

The rights for public folders can be explicit rights such as “ReadItems” or “CreateItems” or ‘roles’ such as Owner, Contributor etc, which have a set of rights.

Add-PublicFolderClientPermission -Identity “Company Contacts” -AccessRights PublishingEditor -User Steve

This will add the PublishingEditor ‘role’ to Steve, so he is able to create and delete all items that he creates, and can delete all content items regardless of ownership (but cannot delete folders he does not own). He cannot change permissions on folders that he has not created.

There is also a Remove-PublicFolderClientPermissions that will remove any permissions you wish in the same manner as above.

This is fine on a folder by folder basis but what if we want to give permissions to All users or permissions for a specific user but recursively for a whole bunch of public folders. Well, that is where the AddUsersToPFRecursive.ps1 script comes in!

So, with this we specify the -TopPublicFolder and specify the username and we can add the specified rights recursivley to all public folders beneath. Useful if want the same permission structure on all public folders.

**    Note, if the Top level PF has a space, you must place the name in ‘ ‘ inside the ” “. So -TopPublicFolder “‘\My Computer'”    **

**    Note, that you need to put the \ at the beginning of the path to represent the beginning of the public folder structure     **

AddUsersToPFRecursive.ps1 -TopPublicFolder “MyCompany” -User “Steve” -Permission “PublishingEditor”

AddUsersToPFRecursive.ps1 -TopPublicFolder “MyCompany” -User “Default” -Permission “PublishingEditor” (the Default user permissions apply to all users that are not explicitly defined)

AddUsersToPFRecursive.ps1 -TopPublicFolder “MyCompany” -User “Default” -Permission “None” (the Default user permissions apply to all users that are not explicitly defined)

AddUsersToPFRecursive.ps1 -TopPublicFolder “MyCompany” -User “Mr.ManagingDirector” -Permission “Owner”

There are a number of other scripts with similar recursive powers, the names are pretty self explanatory, but review in more detail by following links below.

ReplaceUserWithUserOnPFRecursive.ps1
ReplaceUserPermissionOnPFRecursive.ps1
RemoveUserFromPFRecursive.ps1

http://technet.microsoft.com/en-us/library/bb310789.aspx – Configuring Public Folder Permissions
http://technet.microsoft.com/en-us/library/aa998834.aspx – How to Add Permissions for Client Users to Access Public Folder Content
http://technet.microsoft.com/en-us/library/aa997966.aspx – Scripts for Managing Public Folders in the Exchange Management Shell

Shaun

Posted in Miscellaneous, Public Folder | 3 Comments »

Import-Mailbox – Import mailboxes from PST into Exchange 2007 using powershell cmdlets

Posted by shauncroucher on September 5, 2009

In Exchange 2003, one of the simplest ways to move mailboxes from one Exchange organisation to another was using exmerge. It was particularly useful for sites using ‘Small Business Server’ where the level of data and requirements were low.

In Exchange 2007, exmerge is not a supported method for Importing from PST files. The functionality has been naturally replaced with the Import-Mailbox cmdlet.

Prerequisites

1) You need to run a 32bit version of the Exchange Management tools (SP1 or higher, it should not be RTM, although the destination server for the import process can be RTM), and therefore require a 32 bit computer where you can install the management tools for the organisation. Make sure you use 2007 SP1 or higher management tools.

2) You need Outlook 2003 SP2 or higher installed on this PC.

3) You need to have full access rights to the mailbox you are importing to. You also need to be either Exchange Org Admin if mailboxes are across multiple servers, or Exchange Server Admin if the mailboxes are all on one server.

** A note on account permissions **

If you have tried with an account that does not have the correct Exchange administrator role, once you have fixed the issue by assigning either Exchange Org Admin or Exchange Server Admin you will need to Logout of the management station and log back in again for this change to take effect.

4) Update the computer with update rollup 9 (if using SP1) once you have installed the Management Tools.

5) You need to have created the mailbox enabled users first, and the user ‘alias’ (which is usually the users login name) needs to match the name of the pst file.

Step 1 – Install the Exchange 2007 SP1 Management Tools

Log in to the PC which has Exchange 2007 Management Tools SP1 installed and Outlook 2003 SP2 or higher installed with an appropriate account. During testing I was using Windows7, and this already has all the prerequisites for the management tools out the box. You may need to install the Management Tools prerequisites if you are using an older operating system.

Run a Custom install, and install just the management tools. We do not want to install any other roles on this workstation.

After the install, make sure that you run ALL the same update rollups as is on the Exchange server(s) in your organisation.

Step 2 – Add Full Access Permissions to the Mailboxes

Double check the account you are using on the management computer is an Exchange Organisation admin or Exchange server admin. Next is to add FullAccess to all the mailboxes. This is done using the Add-MailboxPermission cmdlet. I will not go into detail on this cmdlet. Suffice to say that running the following will give the user account ‘shaun’ FullAccess permission on all mailboxes for a particular mailbox server (omit the)

Get-ExchangeServer <servername> | Get-Mailbox | Add-MailboxPermission -User Shaun -AccessRights FullAccess -inheritancetype all

(after you are done, you may wish to remove these permissions, to do so, use the Remove-MailboxPermissions -User Shaun -AccessRights FullAccess -inheritancetype all -confirm:$false)

Of course, if you wish, you can perform this using the GUI, just go to EMC –> Recipient Configuration –> Mailbox and select the users –> Managed Full Access Permissions… on the Action pane and add the account there.

Step 3 – Using the Import-Mailbox cmdlet

Now is time for the Import-Mailbox command. The Import-Mailbox command has a couple of parameters that we are especially interested in.

-Identity

As the name suggests, this is where you specify the mailbox you would like to use for the destination of the import routine.

-PSTFolderPath

This will point the Import routine to look in the path for the PST files we are interested in. If you have only ONE PST file to import for a specific user, you can reference the exact PST file here and it will import the PST file. However be careful that you do not specify an explicit PST file and pipe multiple Mailboxes to the command, otherwise it will import the same PST file for all users which could have some embarrassing results!

-MaxThreads

This is the number of mailboxes to move at any one time. Now, this will largely depend on the resources that you have available. The typical value is 4, and this is normally more or less acceptable for this operation unless you have thousands of mailboxes, then you may want to increase this. Just remember ultimately you will have hardware bottlenecks.

-ValidateOnly

Using this switch is similar to the whatif switch in other cmdlets (and this one in fact). It will not move any data, only highlight if the process is likely to be successful and notify you if there are any issues you need to take care of.

So once we have the PST file(s) in the PSTFolderPath of our choosing run the command depending on your situation:

Importing a single PST to a single Mailbox:

Import-Mailbox <MAILBOX ALIAS> -PSTFolderPath <PathToFolderContainingPST>

Importing a bunch of PST files to their associated Mailboxes:

Dir c:\PSTFiles*.pst | Import-Mailbox

Go through ALL mailboxes, and find associated PST and import:

Get-Mailbox | Import-Mailbox -PSTFolderPath <PathToFolderContainingPST>

So as you can see, this routine is all in the preparation of the environment. The actual commands you run to do the Import are small, sweet and efficient. The great thing about using Powershell for this task is that it is so scalable, if you have a situation where there are many PST’s you need to import, this will quite happily do the work.

References:

http://msexchangeteam.com/archive/2007/04/13/437745.aspx – You Had Me At EHLO… : How to Export and Import mailboxes to PST files in Exchange 2007 SP1

http://technet.microsoft.com/en-us/library/bb629586.aspx – Import-Mailbox cmdlet Technet reference

http://technet.microsoft.com/en-us/library/bb691363.aspx – How to Import Mailbox Data Technet reference

Posted in Mailbox\Recipient | Leave a Comment »

Forwarding Envelope & Message Headers – Exchange 2003 & Exchange 2007

Posted by shauncroucher on September 5, 2009

Exchange 2007 uses a different Envelope FROM address (and Return-path) address when forwarding is enabled to an external email address.

Take the following situation. sender@example.net is an external sender, who has sent an email to receiver@example.orgreceiver@example.org has a forward set up (using an AD contact) to receiver@example.com.

So to clarify, these are the addresses we are looking at:

So, for both Exchange 2003 and Exchange 2007, we are interested in the ‘forwarding’ part of this sequence of events (ie: the automated process when sending from original recipient to forwarding address).

The Envelope Header is what is used for routing the message. It is the MAIL FROM: and RCPT TO: of the SMTP conversation as set out in RFC 5321. When the forward process takes place, these will be the values used for each version of Exchange:

The key difference is that Exchange 2003 will use the ORIGINAL sender SMTP address, and not the domain for which it is authoritative. This has been changed in Exchange 2007, so that the MAIL FROM: header is set to the Original recipient, and the domain for which the email server IS authoritative.

Next is the message header information in the conversation:

The To and From of the message is what the MUA (Mail User Agent) or ’email client’ will be presented with. They will not see a change really. They will know it is a forwarded email because it will appear to be addressed to the original receiver, and not the forwarding address. Note however, that the Return path address will be different  for each version of Exchange.

This information is worth noting when it comes to mail flow issues, or if you are attempting to whitelist for your forwarded mail.

Shaun

Posted in Transport | 11 Comments »