For a blog started to cover powershell it seems that all my posts here so far (as few and far beteen as they have been) have all been Exchange related, this one is no exception.  Last night we had our work christmas party, so one of my colleagues decided that it may be a good idea to install Exchange 2010 SP2 on our production exchange server late yesterday afternoon, they say hindsight is 20/20 and in this instance it is no exception.  Long story short (and getting back to powershell) it seems that there is a bug (or known issue) with Exchange service packs in that if the Powershell execution policy is set to remote signed the installation bombs out, however this is after it has deleted files from the exchange installation on our production box.  I dont have all the technical details but there are some threads on the Technet forums that cover this, but basically we were left with a non functional exchange server and 2 hours to restore it before hitting the booze.

This is where all good IT professionals look to their comprenhensive and tested disaster reovery plan as a means to get things back online and out to the party only half an hour late...I knew there was proff of concept I was getting around to putting together :( .  So after a couple of hours trying to pull the server back from tape and trying a few other things we took an intermission to recharge the brain cells with copious amounts of alcohol.  Flash forward to 4am, we reset the Exchange account within our AD, built a new server at the same service pack level as the old exchange server, and had just finished the process of installing all the pre requesite's for exchange 2010 SP1 install with the setup /M:RecoverServer switch I found my self asleep at my keyboard and decided to let the process run unattended for a few hours (I went to bed).

I woke to the find the process had finished and after a reboot and IP address change found that the exchange management console was reporting all the mailboxes and the settings looked right, just an issue of the mailbox database being empty and not mounting.  This was when we remembered we had a backup, fired up Backup Exec and restored the mailbox database and while frying up some green eggs, ham and tomatoes (breakfast of hungover champions) we were greeted with the sweet sound of our iDevices new email tone and a phone call from a happy (well slightly less pissed off) employer.

This is the story of how the reaility TV term I have affectionately titled, Extreme Drunken Disaster Recovery, was born.

The morel of this story:

• Be mindful of this powershell idiosyncrasy if you are using exchange server 2010
• Dont EVER upgrade anything production when you have a night out planned afterwards
• When you cant fix an issue the resolution is almost always the time, execpt in this instance where it was lots of booze.

This may be old news for some people, but I was recently made aware that Exchange 2010 SP1 now supports exporting and importing mailboxes directly from the server in a relatively straight forward way. 

Previously in Exchange 2007 SP1 and higher you could use the Export-Mailbox or Import-Mailbox cmdlets to import/export data from a mailbox however to get access to these cmdlets you needed to install the 32bit exchange management tools on a domain joined machine in order to use them.  Exchange 2010 did away with both of these cmdlets leaving no way to import/export mailboxes at all (server side). 

Since the release of Service Pack 1 for Exchange 2010 we can now use the New-MailboxExportRequest cmdlet to Export mailbox data to a PST file or New-MailboxImportRequest to import data directly into a mailbox.  Both of these cmdlets can be run on an Exchange 2010 SP1 server without the prior restrictions of Exchange 2007.

There are still a few requirements, howerver they are not as bad as before.  I encourage creating a group and adding the import/export permissions to that group rather than assigning users the permission directly.  The following points outline the process to get this up and running:

• Create a Universal Security Group eg: ExchangeImportExport (this must be a universal security group)
• Add the Mailbox Import Export permissions to the group with the following command: 
• New-ManagementRoleAssignment -Role "Mailbox Import Export" -SecurityGroup ` "ExchangeImportExport"
• Add the user who will be performing the import/export (logged in user running the Exchange Shell) to the ExchangeImportExport Group.
• Close and re open the Exchange Shell

After this the New-MailboxExportRequest/New-MailboxImportRequest cmdlets will be available to the user in the Exchange shell. 

When exporting a mailbox it must be to a UNC share eg: \\localhost\export and this share must have Modify permissions for the Exchange Trusted Subsystem Group (as it will be writing to this location). Once these pre requesites have been setup you can use the following example to export a mailbox to a pst file.  New-MailboxExportRequest -Mailbox <Mailbox Name> -FilePath <\\Servername\ShareName\Name.pst>

eg: New-MailboxExportRequest -Mailbox adam -FilePath \\servername\foldername\adam.pst

this will begin the export.  To check the progress of mailbox export request use the Get-MailboxExportRequest cmdlet, which will output the currently queued export processes.

There are more cmdlets available than the ones I have outlined here, this link to the Microsoft Technet article Understanding Mailbox Import and Export Requests which has a listing of the cmdlets and it also gives a good overview of the process.

Another good post I found was on Steve Goodmans Exchange Blog which gives step by step instructions for setting this up as well as scheduling mailbox exports.

I recently deployed Exchange 2010 which required a large ammount of mail enabled users accounts to be created.  I created the user accounts and mailboxes in one step by using the Import-CSV cmdlet combined with the New-Mailbox cmdlet which made this really easy and created around 90 user accounts and mailboxes in about 30 secounds, I cant really say that I would call this a script because it is only three lines but it saved a mamoth amount of time. 

Throughout this blog I am going to be using the ` (backtick) to break up a single line of code onto multiple lines, this is used in Richard Siddway's Book Powershell in Practice to make single long lines of code easier to read and I am going to adopt this here to try and make whatever I post easier to read.

$password = Read-Host -Prompt "Please enter the password to give all users” -AsSecureString
$filelocation = Read-Host -Prompt "Enter the Full path and filename of the CSV file"
Import-Csv $filelocation | ForEach {New-Mailbox -Name $_.name -ExternalEmailAddress `

$_.externalEmailAddress -OrganizationalUnit $_.OU -Password $password -UserPrincipalName $_.UPN `

-Alias $_.alias -Firstname $_.firstname -LastName $_.lastName -DisplayName $_.displayName - `

samAccountName $_.samAccountName -ResetPasswordOnNextLogon $false}

• To Start with we need to read in a password for the user accounts.  You have set a generic password on all the accounts when they are created otherwise they are created in a disabled state.  To do this without hard coding the password into the script you need to use Read-Host cmdlet to read in a password from the user and convert it to a securestring, you can then use this variable as a parameter for New-Mailbox.
• The second line declares a variable with the full path and file name of the CSV file that contains the information that we are using Import-CSV cmdlet to import. 
• The Third line imports the contents of the CSV file from the location that was specified and then uses a for each loop to execute the New-Mailbox cmdlet on the information passed in from each row of the CSV file.

This was the first time I had used PowerShell to write a script (using the term loosly) from scratch, rather than googling a one liner to fix an issue and there were a few things which tripped me up when I was troubleshooting this.

Firstly at the time I did not know that the "$_." represented the current object in the pipeline, meaning, in this example $_.name was the object read in by Import-CSV from the row called name in my CSV file.  I struggled with this for a while as I originally thought it was a way to reference a variable within the loop, this is not correct.  Make sure when you are using parameters in the New-Mailbox loop that there is a corresponding row in the CSV with this information in it, all the New-Mailbox cmdlet is doing is creating an object in AD, creating the mailbox for the user object and populating the properties associated with each IE: Diaplayname, Alias, Firstname, Lastname, OU etc.

Also one other issue I ran into when testing this script was when I copied the script from notepad and then pasted it straight into the command shell.  This actually just drops whatever you paste into the prompt line by line, meaning the first line of the script when it asks for a password was actually getting the rest of the script pasted into the Read-Host field.  This had me confused for a long time.  Once I saved the script and went to run it (.\CreateAccounts.ps1), there was a pause for the actual password to be entered.

These both seem like very rookie mistakes but I do not have a scripting background and I just wanted to point these out to anyone else that may run into the same problem.