Automating Mailbox Repairs – Exchange 2010

While running through a series of mailbox repairs, I was looking for a way at automating this task. Since Exchange 2010 logs the output of the command New-MailboxRepairRequest to the Event Viewer, I would have to pull the results from here as part of this automation.

A brief outline of the automation to follow goes like this. Run New-MailboxRepairRequest against a mailbox database with a detectonly parameter, once completed gather all mailboxes from Event Viewer which contain corruption and continue to run a mailbox repair over them.


Some of the errors which can be resolved include;

10033 – A folder is being scoped by a search which no longer exists. 

Part of the script can also be used if you want to pull a list of corruption affected mailboxes.


  • New-MailboxRepairRequest has a maximum of simultaneous repair requests to 1 database at a time or 100 mailboxes.
  • The command may impact user connectivity to the mailbox while repairing corruption not while using the -detectonly parameter.
  • If running against a database rather than per user mailbox Exchange will only disconnect the user during their mailbox scan, in other words the command is completed in sequence rather than in parallel.
  • A repair request can only be cancelled by dismounting the entire database.

Begin by running the New-MailboxRepairRequest over each database.(Due to potential performance issues you are limited to running 1 repair per database)

You will see the request begin in the Application log of the Event Viewer with Event 10059;


You will then need to wait until the scan has finished at which point you will see the Event 10047;


Once the initial detection has been completed as above, we can continue to pull the data from Event Viewer and run a per mailbox repair on each of the mailboxes found to have corruption. I have broken down what exactly the script is doing below.

Custom event query for codes relevant to mailbox repair. (Can be found by creating custom a custom view and selecting the XML tab and copying the XML code.)

Get events using the XML filter supplied in $EventXML

Declare $Accounts variable as array to be able to query after ForEach

For each object in $events variable get data in brackets which will be the mailbox name and add it to the $Accounts variable

Select the unique objects in $Accounts variable and store in $Mailboxes variable

The final part of the script will take each object in the $mailboxes variable, store in $Mailbox variable and if the object isn’t empty then get the mailbox using the object as the identity using Get-Mailbox and store in $UserMailbox. We then Run a New-MailboxRepairRequest on each valid mailbox.

Once the script has completed, clear and save off the Application log ready to run through the same for any additional databases which need to be checked!


Hopefully the above will save some time and effort, you can of course run a repair using the command over the database without the -detectonly parameter but if you, like me, would prefer to only run against the corrupt mailboxes this should assist to some degree.

Two scripts are available, the first can be used just to view the corrupt mailboxes and write them to screen EventScript.ps1. The second is the script that has been outlined in this article PerMailboxRepair.ps1.






Importing contacts into Exchange user mailbox

This is the second part of the original post Exporting Outlook contacts with PowerShell. I will be going through the process of importing these exported contacts directly into Exchange user mailboxes, in this case we will be using Exchange 2013. If you are using an older or newer version of Exchange server, you will need to use the relevant version of the EWS API, also you will need to adjust the dll path that exists in the PowerShell script supplied.


The brief steps to complete are as follows.

Install EWS API 2.1

Assign Role ApplicationImpersonation to Account used to complete this procedure

Modify and Save the ContactImport.ps1 script with your Exchange CAS server, Impersonation Account + Credentials and CSV share

Save the Import-MailboxContacts.ps1 script to the location specified in ContactImport.ps1

Open an Exchange Management Shell  and run ContactImport.ps1 script to import 

Else create session to Exchange CAS with the below and run ContactImport.ps1 changing EXCHANGESERVER to your Exchange CAS


Prerequisites to this procedure include;

EWS API 2.1  – Install –> (Enables enhanced exchange management for third party applications)

CSV Files – If the CSV files have been created per user with the post Exporting Outlook contacts with PowerShell, the below script already includes all possible mapping for contacts properties, if a custom CSV file has been created then these mapping will need to be modified.

Exchange Impersonation Rights (Allows impersonation of users to enable the ability to import the contacts directly into mailboxes without the users credentials or full access rights to mailbox) See below –>

To configure impersonation rights, you will need to complete through either the Exchange Control Panel or Exchange Management Shell.

The steps to configure impersonation rights through ECP:

Access the ECP URL where EXCHANGESERVER is the name of your CAS and login with an administrative account e.g Exchange Domain Admins–> https://EXCHANGESERVER/ecp/

Select permissions –> admin roles –>


Enter a relevant name e.g Impersonation –> Leave scope as Default –> Add Role ApplicationImpersonation –> Add the user in which you will use to complete the import under Member –> Click Save.


Steps to configure impersonation through PowerShell:

Open Exchange Management Shell with an administrative account

Now that impersonation is configured we can look to start the import process. In this specific use case the name of the CSV files are the name of the user account in the new domain, if you have a case where the new mailbox names differ from the CSV generated name, you will either need to change the generated name of the CSV or create a mapping between the CSV name and the new user account name.



Breakdown of the ContactImport script

Get all CSV file names from share and store in $list variable (Change SERVER\SHARE as appropriate)

Loop through each CSV name in Share, If the name matches the UserPrincipalName property of the mailbox then import to users mailbox else display “No Address Found”

The ForEach uses the Import-MailboxContacts script which will be explained later in the post with the relevant parameters for EWS. You will need to change the EXCHANGESERVER name to your Exchange CAS server with the user name used earlier which has the impersonation rights.



Import-MailboxContacts script

At the bottom of this post is the Import-MailboxContacts script, thanks to Steve Goodman and has been configured to be used with the Exporting Outlook contacts with Powershell post.

The script needs to be saved as Import-MailboxContacts.ps1 and is called by the ContactImport script. The ContactMappings array has been modified to work with the export from Outlook and the script has been updated with the corrects paths for use with EWS 2.1.

And thats it, if all is configured correctly, your users should have newly imported contacts in their mailbox.

Hope this helps!

Full Scripts with comments below;


Import-MailboxContacts script




ContactImport Script


Exporting Outlook contacts with PowerShell

Who new you could utilise PowerShell to drill into Outlook (while running) and pull out tons of stuff, awesome. I have documented a script which can be used to do just this, a couple of caveats…

*Outlook must be running

*This doesn’t export the contacts picture

*PowerShell will need an Execution Policy set during running e.g Bypass (unless run in a PowerShell windows on user session)

See more about execution policies on the Microsoft technet site –>


A bit of background: I had a rare instance where the data held in a user mailbox who was moving to a new company within the umbrella of a corporation was sensitive, so a mailbox migration couldn’t be completed and they wanted to take across their contacts to their new mailbox, which spurred the creation of this script and in turn this post.

In this instance for ease of use I will be running the script initiated from a batch script with a bypass execution policy.

Copy the line of code above into notepad and save as ContactExport.bat, you will be running this batch script through whatever means you choose e.g GPO, management agent, SCCM etc.

I have broken the script down into sections to explain each part:

The $Outlook variable holds the New-Object command which is allowing control of the current session of Outlook, you need to have Outlook already running else PowerShell will attempt to create a new session and error.

We can then drill down to individual folders to extract information, in this case (10) is contacts.

*** Additional script below to include folders within contacts (pointed out by Mike in comments section)



Exempt additional folders as by default there are Recipient Cache folder, Global address lists and any other type of created address lists. (the one variable exempted all folders other than user created ones, which I found strange, but it works so hey!)

Declare the array so that objects gathered within the For loop can be used outside of itself

For loop to loop through each folder and pull contact items, exempting additional folders. (the Folders.items array only accepted integers, which may be a restriction of using Outlook this way )

***Note you need the exemption as if your users have GAL’s this is going to pull all the contacts in there! So be warned

Finally add the contacts within the contact folders to the original $Contacts variable.



I have listed all of the different folder numbers and what they relate to below:

Next we get the OS’s environmental variable UserName (currently logged in user) ready for naming the exported .csv file.

We then need to select all of the attributes and details for each contact from the $Contacts variable, here I have selected everything but have listed it all to pick and choose.

This is then exported to a .csv file named as the logged in user with the $User variable. The Encoding is set to ensure any contacts which contain funky characters are not made worse.

That’s it, this should export all contacts to a .csv file ready for importing elsewhere. I will be writing an article on importing this into users mailboxes through Exchange using PowerShell in the coming weeks.

Full Script with comments below, hope it helps.(Updated to include Contact Folders)

PowerShell Script to run commands per Active Directory OU

I regularly run into a case in which it is handy to have a script to hand to run against a group of windows desktops or servers in an Active Directory OU.

Requirements to run the below are below.

  1. WinRM needs to be running on the relevant desktops and servers (can be completed by GPO) or by running “winrm quickconfig” in a PowerShell session on the machine
  2. Remote Server Admin Tools need to be installed on the desktop or server in which you are running the script (not required on DC’s)

The script is broken down below.

Import the AD module (RSAT requirement)

The $OU variable holds the full LDAP filter of the targeted OU

The $Script variable holds the command to which you would want to run against the computers. (installations, batch scripts or any other commands)

The window title of the PowerShell windows will display “Processing Computers in OU OU=SETOFCOMPUTERS,OU=COMPUTEROU,DC=DOMAINNAME,DC=COM” while the Connectivity Timeout variable is used later to complete inital connectivity of the computer before completing the script.

The $ComputerNames variable uses the AD command Get-ADComputer with the filter of the $OU variable to select all computers in the targeted OU.

The foreach loop runs a test-connection or ping with a TTL of 20 seconds, if this fails the “Computer Not Found COMPUTERNAME” message will be returned. If successful then the invoke-command will run a remote PowerShell session to execute the $Script variable on the targeted desktop.


Full Code:


SCCM Site Code Change with PowerShell

I came across a case whereby a test SCCM installation had been completed and needed to be removed and replaced with a production instance. There are a few cleanup operations but in this case I needed to automate a way to change the clients to point to the new Site Code.

This can be completed with the below PowerShell command replacing SITECODE with the new Site Code (PowerShell run as administrator)

Running across VM’s in vCenter

I also have a script for completing in PowerCLI by using the Get-VM command, this is broken down below.

This presumes you have already created a connection to your vCenter through PowerCLI

*Use PowerCLI x86

Note that there is no error checking on the below, replace the GuestUser and GuestPassword parameters with your own credentials with administrative rights on the VM Guest OS.

In the perfect world this environment would have WinRM enabled across the server estate but alas it didn’t. This saved a fair amount of manual work for me and I hope it does you too!

Complete script available here –> SCCMSiteCodeChange just paste into PowerShell ISE, save and run from PowerCLI.

VMware vShield Driver Installation through PowerCLI

While deploying vShield I have found the easiest way to automate the installation of the additional vShield Driver (Now called Guest Introspection Driver) is to use PowerCLI and complete through the invoke-vmscript command.

I will presume that you have PowerCLI installed, else it can be obtained from

*If using an x64 OS you will need to use the x86 version of PowerCLI*

Connect to your vCenter Server where *vCenterServer* is the name of your vCenter Server, I use the $Credential variable to store the credential for this session but you can skip that and use the -user and -password parameters after the connect-viserver if preferred;

The $Name variable stores the name that is input when the script is run, if you specify a wildcard * for the name this will run against all servers so be warned! In turn you can run against VM1 and VM2 with VM*.

The name is then checked using the Get-VM command to see if the server exists displaying “VM FOUND 🙂” if true or “VM NOT FOUND 🙁” if false. Until the correct name is entered the script will keep prompting for a name.

The below code is only required if the hostname differs from the name of the VM.

Next we attempt to mount the VM tools to the VM

Get the drive letter of the VM and store in the $DriveLetter variable (I have seen this fail if the VM has WMI issues).

Storing the entire script in $ScriptText to run in the Invoke-VMScript command, replace Administrator and *Password* with your local admin account credentials.

Entire Script available below with additional menu option, split into Functions as I attempt to learn Powershell!
I apologise to any programmers/script writers as my script writing has a lot to be improved.