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.

NOTE:

  • 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;

2017-01-22_20-04-57

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

2017-01-22_20-04-5

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 –> https://www.microsoft.com/en-us/download/details.aspx?id=42022 (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 –>

Permissions

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.

RoleGroup

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

 

Orphaned VM Error

Orphaned VM’s can be caused by a number of things such as database, storage or network connectivity issues to vCenter server during a vmotion. I have listed a few methods to resolve the orphaned VM error below.

Method 1 – Restarting VPXA service

Initially this can sometimes be resolved by simply restarting the vpxa service on each esxi host. The service is the agent which services the connectivity between the esxi host and the vCenter Server for management. This will not cause a HA failover but a brief disconnect of the host from vCenter while the service is restarted. This can be completed as below.

Select the relevant host in the vclient

Select the Configuration tab

Select Security Profile under Software

On the right-hand side of the page select Properties

Select the vpxa service and click on Options

Click on Restart

VPXAService

If this hasn’t resolved the orphaned VM issue then move on to Method 2.

Method 2 – Kill the world

Open SQL Management studio and create a connection to the vCenter database, run the below query to find the last host in which the VM was or is running on.

Start the Esxi Shell and SSH services

Select the relevant host in the vclient

Select the Configuration tab

Select Security Profile under Software

On the right-hand side of the page select Properties

Select the Esxi Shell and SSH services and click on Options

Click on Start

Using a SSH client connect to the Esxi Host, login and type esxcli vm process list and copy the world ID for the relevant VM.

Type esxcli vm process kill -t soft -w <WORLD ID> to kill the process of the VM, if you know which datastores the VM exists on then right-click the VM and select remove from inventory DO NOT SELECT DELETE FROM DISK!.

Browse to the datastore in which the VM files exist and right-click on the relevant .vmx file and select Add to Inventory.