Master Exchange 2007

powershell, automation & more…

Archive for the ‘Mailbox\Recipient’ Category

This category contains cmdlets and scripts that relate to the management of recipient objects 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 »

Exchange 2007 Physical edb database size too large reduce size move mailbox offline defrag

Posted by shauncroucher on November 3, 2009


There is a myth that the only way to deal with an oversized *PHYSICAL* edb file in Exchange 2007 is to run an online and then offline defrag.

This is not true. You can use the Move-Mailbox method on a new database to effecively reduce the size of the database holding your mailboxes. The great thing about this method is that neither an online OR an offline defrag is required, so you can achieve the desired effect on the spot, perhaps after deleting (or Disable-Mailbox’ing) a whole bunch of mailbox enabled users.

Whilst it is true that you will never change the physical size of a database without doing an offline defrag, you can deal with an oversized database by deleting it. Stay with me.

The method is as follows:

1) If you have deleted item retention configured on your Exchange 2007 server inform your users to check their ‘Recover Deleted Items’ using OWA or Outlook. This is the message dumpster location where deleted items get sent when they have been emptied. The items will remain accessible until the retension period has passed. The next step will make the Dumpster unavailable.

2) Create a new Storage Group and Database (you can just create a new database if you prefer, but it’s generally good practice to try keeping 1 database to 1 Storage group.

3) Use the Move-Mailbox cmdlet, or the Move Mailbox management shell facility to move ALL the mailboxes from the original oversized database to the new database.

4) If you are dropping the original database, once all mailboxes have been moved, restart the Microsoft System Attendant to ensure the system mailboxes get recreated

5) Remove the original database files and log files.

Voila. You now have a mailbox database that does not inclue the white space (mailboxes and deleted items in the dumpster) and you will be left with a mailbox database that is smaller than the original.

Note that this process also includes no downtime for the users and no risky offline defrag. Granted, offline defrag will normally run without causing a problem, but because it operates on the database page by page, there is a chance that data loss will occur. It is far far better to use this Move-Mailbox approach.

Move-Mailbox command syntax would be as follows:

Get-MailboxDatabse “Name of Mailbox Database” | Move-Mailbox -TargetDatabase “Name of Target Database” -confirm:$false


Posted in Mailbox\Recipient | 2 Comments »

How to bulk add Send-As and FullAccess permissions using exchange 2007 powershell using add-adpermission and add-mailboxpermission

Posted by shauncroucher on October 28, 2009

Some email administrators have been asking how to add the Send-As and FullAccess permission to many users at once for a particular user account.

Its quite a straightforward command to achieve this, but it should be noted that it is not the Add-MailboxPermission you use, it is the Add-ADPermission for the Send-As rights.

You can easily amend this for adding FullAccess rights in bulk

So, to add Send-As rights for user JoeBloggs to ALL Mailboxes in your organisation:

Get-Mailbox | foreach-object{$mbDN = $_
.distinguishedname; Add-ADPermission -identity $mbDN -User “DOMAIN\JoeBloggs”
-ExtendedRights “Send-as”}

The CSV Approach

And if you have a list of users\mailboxes OR both you wish to process:

Create a CSV with 2 colums. TheMailbox and TheUser

For instance lets say the CSV looks like this:


This will give user emp66 Send-As rights to user emp70’s mailbox, user emp67 to user emp71’s mailbox etc etc

$Thelist = Import-csv “C:\thelist.csv”

ForEach($theobject in $thelist) {$theMBDN = (Get-Mailbox $theobject.the
mailbox).distinguishedname; Add-ADPermission $thembDN -Extendedrights “Send As”
-User $theobject.theuser}

To Add Mailbox ‘FullAccess’ permissions using the CSV approach…

Just a few small changes needed…

ForEach($theobject in $thelist) {$theMBDN = (Get-Mailbox $theobject.the
mailbox).distinguishedname; Add-MailboxPermission $thembDN -Accessrights “FullAccess” -User $theobject.theuser}


Posted in Mailbox\Recipient | 12 Comments »

Managing message size limits in Exchange 2007 using powershell

Posted by shauncroucher on October 11, 2009

The lists I have given below show the most common message size limits, however there are some attachment and header limits that the commands may not show you, so follow the links at the bottom of this article for further informationif you still have problems.

NOTE: Always include the qualifier ‘MB’ when using the management shell to specify message size restrictions.

NOTE: is the MASTER reference article for size restrictions for Exchange 2007 and most of the information below is plucked from there. The idea of this article is to extract and simplify some of the commands to get and set the settings.

Global Settings

Scope: RTM Only. Transport setting will change this automatically in SP1

Note: If the values found here and the values found using ‘get-transportconfig | fl M*ze’, the lowest value takes precedence.

Global Settings stored in Active Directory (access using ADSIEdit)
Configuration –> Services –> Microsoft Exchange –> [DOMAINNAME] –> Global Settings –> right client
Message Delivery –>
Check the settings below. They are in KB
msExchRecipLimit (default 5000)
submissionContLength (default 10240) (MaxSendSize)
delivContLength (default 10240) (MaxReceiveSize)

Transport Setting

Scope: Organisational limits for ALL EX2003 / EX2007 servers in the entire organisation.

To show current settings:
get-transportconfig | fl M*ze

To Alter:
Set-TransportConfig -MaxRecipientEnvelopeLimit -MaxReceiveSize MB -MaxSendSize MB

Also check there are no Transport Rules to check the Attachment size of messages.

Connector Limits

Scope: Will affect all messages using the specified connector. Either Send,Receive or Foreign.

To retrieve current settings:

get-ReceiveConnector | ft Id*,M*ze
Get-SendConnector | ft Id*, M*ze
Get-ForeignConnector | ft Id*, M*ze

To Alter:

Set-ReceiveConnector “” -MaxMessageSize MB
Set-SendConnector “” -MaxMessageSize MB
Set-ForeignConnector “” -MaxMessageSize MB

‘Server Specific’ Limits and Outlook Web Access (OWA) limits

Scope: Hub/Edge servers with Transport Rule AND Client Access Servers for the OWA restrictions.

Check there are no transport rules that have ‘server specific’ attachment size over restrictions

CAS servers provide OWA for users to access mail using a web browser. The underlying engine is ASP.NET.

ASP.NET uses the maxRequestLength setting to determine the maximum amount of data that the Web browser can submit to the Client Access server
The setting can be found in the web.config file.

See for instructions on changes needed here.

‘Multiple Sites’ and ‘E2000 \ E2003 Co-Existence’ Settings

Scope: Will affect messages using the site links and the routing group connectors for delivery. The settings themselves
DO NOT affect least-cost routing decisions.

* Note that Exchange 2007 RTM does not support site link or routing group connector size limits and routing loops
may occur if they are set. SP1 and above does support size limits though.

Active Directory site links:

Get-AdSiteLink | ft Name,M*ze
Set-AdSiteLink “Site link name” -MaxMessageSize MB

Routing Group connectors:

Get-RoutingGroupConnector | ft Name,M*ze
Set-RoutingGroupConnector “Name of routing group connector” -MaxMessageSize MB

‘Users and Groups’ Settings

Scope: All the above is for Transport level restrictions, but you need to check the MaxMessageSize setting for the user mailbox/contact and
also the groups they may belong to.

Get-Mailbox “name of mailbox user” | fl M*ze
Get-MailUser “name of user” | fl M*ze
Get-MailContact “name of contact” | fl M*ze
Get-DynamicDistributionGroup “name of dynamic dist” | fl M*ze
Get-DistributionGroup “name of dist” | fl M*ze
Get-MailPublicFolder “name of public folder” | fl M*ze

Manually SET a limit (if ‘unlimited’)

Some exchange administrators have reported that the limits indicate ‘unlimited’ in one or more of these location, and once they change to a value (such as 100MB), the problems disappear. If you are unsure, I would recommend setting a limit rather than leaving as ‘unlimited’.

References: – Exchange 2007 Message Size Limits – Managing Message Size Limits – How to Modify Exchange 2003 Global Message Size Limits in Exchange 2007 RTM – Message Routing in a Coexistence Environment – How to Configure Message Size Limits for Internal Routing – How to Manage Maximum Message Size in Outlook Web Access

Posted in Mailbox\Recipient, Transport | 8 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.


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.


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


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!


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.


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: – You Had Me At EHLO… : How to Export and Import mailboxes to PST files in Exchange 2007 SP1 – Import-Mailbox cmdlet Technet reference – How to Import Mailbox Data Technet reference

Posted in Mailbox\Recipient | Leave a Comment »

Exchange 2007 ‘Managed by’ does not allow user to change, add or delete distribution list members

Posted by shauncroucher on August 31, 2009

No, it doesn’t!

The Managed By: in the Group Information tab of a Distribution Group is for informational purposes. It does not give a user / group to manage the distribution group.

You need to run the Add-ADPermission cmdlet to add this permission:

Add-ADPermission -Identity <name of distribution group> -User <name of user> -AccessRights WriteProperty -Properties “Member”

This will then allow the specified user to manage the distribution group membership.

It is an area common for confusion in Exchange 2007 due to the change of behaviour.


Posted in Mailbox\Recipient | 8 Comments »

Local Continuous Replication – No excuse not to!

Posted by shauncroucher on August 27, 2009

Local (or clustered if you prefer) replication should be a mandatory requirement on every 2007 server in the world where there isn’t already a level of mailbox data redundancy!!!

I recently came across a situation where somebody with a little IT knowledge was trying to retreive a CD (that had become stuck) from a server … after looking in 3 drives, they still couldn’t find the CD? Then it dawns on them that instead of looking for the CD in the various CD-ROM drives, they were actually pulling out the Hotswappable HDD’s!!!

Net effect…. Destroyed RAID5, luckily it wasn’t so bad getting the company up and running again, but it got me thinking how easy it is to place too much faith in hardware. Nothing will prepare for user error.

So back to Local Continuous Replication. It’s really simple – a copy of your mailbox database and storage group files (transaction log files etc) are copied asyncronously to another set of disks. This can be another RAID volume on the server, or even NAS/SAN storage. The point is in the event of a major disk failure you can switch over to the passive copy almost instantly.

So, how to do this in powershell.

Well, first of all you need to ensure that you have enabled the database for replication. To do this run the following command (note the DB name must be the same as the original):

Enable-DatabaseCopy -Identity:”SG1\DB1″ -CopyEdbFilePath:”D:\DB1\SG1\Mailbox Database.edb”

Of course, this is where D: is another set of disks, NAS or SAN. Once done it is time to Enable Storage Group Replication

Enable-StorageGroupCopy -Identity “SG1” -CopyLogFolderPath “E:\DB1\SG1” -CopyLogSystemPath “E:\DB1\SG1”

Now, as long as the Storage group has one database in it and that database is set to copy, then these really are the minimal commands required to get LCR working on your server. You can optionally provide the -SeedingPostponed command parameter to stop the database copy from starting immediantly.

If you have chosen to Seen at a later stage, you can run the seen operation by using the Suspend-StorageGroupCopy and then Update-StorageGroupCopy to initiate the seeding. Don’t forget to Resume-StorageGroupCopy afterwards!!

Excellent Further Reading:


Posted in Mailbox\Recipient | Leave a Comment »

Managed Default Folders managed custom folder exchange 2007

Posted by shauncroucher on August 20, 2009

It can be a little confusing what the difference is with Managed Default Folders and Managed Custom Folders. I recently tried to clarify the differences for a confused administrator!

A Managed Default Folder can be of type ‘Inbox’ , ‘Calendar’ , ‘Deleted Items’, basically all the usual folders you find by ‘default’ in an Exchange 2007 mailbox.

Only 1 “Managed Default Folder” ‘of a particular type’ can be assigned to a “Managed Folder Mailbox Policy” and only 1 “Managed Folder Mailbox Policy” can be assigned to a mailbox user. So if you simply create a Managed Default Folder called “Inbox – 60 day retention”, this will do nothing until you link it to a “Managed Folder Mailbox Policy” and link that policy to a mailbox user.

So the steps may look like this:

1) You have set up a Managed Default (or Custom) Folder Policy for the folder
2) You have set Managed Content Settings to set retension as per your requirements
3) You have added the Managed Default (or Custom) Folder Policy to a Managed Folder Mailbox Policy
4) You have ensured that the users mailboxes are configured to use the Managed Folder Mailbox Policy
5) You have scheduled the Managed Folder Assistant to run regularly, or you have manually run the assistant.!!

It’s a little confusing at first, don’t confuse “Managed Default Folders” with “Managed Custom Folders”. With custom folders you can create *additional* folders in a mailbox, but not so with Managed Default Folders.


Some useful powershell commands to double check the policies and settings are in place:

Get-Mailbox <username> | fl *man* (This will show you the MailboxPolicy applied for a particular user)

Get-ManagedFolderMailboxPolicy <Name of ManagedFolder from above> | fl *fo* (This will show all the Managed Folders that are managed by the policy)

Get-ManagedFolder <Folder Name from above, replace {Name} with ‘Name ‘ > |

Get-ManagedContentSettings | fl  (This will show the content settings and the Mailbox Folders they apply to)

Review the articles found in this section of technet, they make it pretty clear. Also a *quicker* read can be found here:


Posted in Mailbox\Recipient | Leave a Comment »

Customised UPN or Email alias when bulk creating users in Exchange 2007

Posted by shauncroucher on August 20, 2009

I found on a recent Experts-exchange article a really great way of manipulating the UPN or email alias based on certain letters found in the name, ie 7 letters from last name then . then first initial.

The script is written by Chris-Dent on EE. The script shows some pretty useful basic concepts with Powershell such as string concatenation and using Functions to convert basic string to secure string on the fly.

## Run BulkImport.ps1 c:tempimportusers.csv
## Import data from csv and store it in variable ‘data’

$data = import-csv $args[0]

## Function to convert password into a secure string

function New-SecureString([string] $plainText)
$secureString = new-object Security.SecureString
foreach($char in $plainText.ToCharArray()) { $secureString.AppendChar($char) }

foreach ($i in $data)
$ss = new-securestring $i.password

# Build the UPN
$UPN = $i.lastname
# If the last name length is greater than 7 characters trim off the end
If ($UPN.Length -gt 7) { $UPN = $UPN.SubString(0, 7) }
# Concatenate with the first character of the first name and the domain name
$UPN = “$UPN.$($i.firstname.SubString(0, 1))@bch.local”

new-mailbox -Password $ss -Alias $i.alias -LastName $i.lastname -Firstname $i.firstname `
-Name $ -Database $i.database -UserPrincipalName $upn -OrganizationalUnit $i.ou

Add-DistributionGroupMember “citrix_staff” -member $UPN


Posted in Mailbox\Recipient | Leave a Comment »

Offline Address Book (OAB) and web based distribution

Posted by shauncroucher on August 11, 2009

Exchange 2007 manages the Offline Address Books and distribution of these offline address books using BITS transfer to Outlook 2007 clients. The article below does a great job of explaining the process that occurs:



Posted in Mailbox\Recipient | Leave a Comment »