The following script does just that:

# Read in pst file locations and users
$strPSTFiles = Get-Content -Path "c:\pstdetails.csv"
foreach($strPSTFile in $strPSTFiles)
{
$strMachine = $strPSTFile.Split(',')[0]
$strPath = $strPSTFile.Split(',')[1]
$strOwner = $strPSTFile.Split(',')[2]

# Get network path for pst file
$source = "\\" + $strMachine + "\" + $strPath.Replace(':','$')

# import pst to mail box.
Import-Mailbox -PSTFolderPath $source -Identity $strOwner
New-MailboxImportRequest -FilePath $source -Mailbox $strOwner
}

The yellow highlighted text shows the Exchange 2010 RTM cmdlet, the red the Exchange 2010 SP1. Delete the unneeded version as appropriate.

The Exchange 2010 SP1 version of the script will execute in far less time, due to the asynchronous nature of the ImportRequest cmdlet. These requests are processed in the background and can be monitored with the Get-MailboxImportRequest cmdlet to observe their status.

There are quite a few potential pitfalls here:

1. The user’s machine must be on.
2. File sharing must be on, to allow for the file to be transferred.
3. Outlook must not be running on the remote user’s machine. If Outlook is running and has the PST file attached, the file will be locked and unable to be imported.
4. The PowerShell cmdlet used by Exchange to import PST files does not support passwords.

There are various things you could to augment this script.Some suggestions include:

•  Have WMI shut down Outlook on a remote user’s machine before attempting import http://www.computerperformance.co.uk/vbscript/wmi_process.htm
• It could be useful to generate a further file detailing a list of all the PSTs which failed to import, with the reason. These files could have been password protected, or the machine hosting them may have been shut down, or become disconnected since they were identified.

I hope you have found this series of articles on manually importing PST files into Exchange 2010 useful. Although, like me, I’m sure you feel that this is a bit of a mammoth task, particularly for the Powershell novice!

To automatically import PST files into Exchange 2010 without Powershell visit:
www.red-gate.com/products/pst_importer_2010. Here you can find out more information on PST Importer 2010 and download a free 14 day trial.

To start this, we  can query Active Directory for a list of all the machines attached to your domain. We can then use Windows Management Instrumentation (WMI) to search each of these machines for PST files. The file paths for these PSTs should hopefully give a clue as to which user they belong to, as they will be created in a directory path containing the username by default. We can also grab the file owner file attribute which should correlate with the file path.

This technique requires that all the machines in your network are switched on and accessible by WMI. A list of the machines which could not be queried can be provided as output

Notes about WMI:

By default WMI is blocked by the windows firewall in Windows 7 and 2008 R2. You’ll need to open up the ports on all your users’ machines. This can be done with the ‘netsh’ command, or through a change to group policy.

What are the implications of this? WMI is a powerful beast, and allows remote access to many aspects of a user’s machine. As such it could be considered a security vulnerability… It’s typically accessed though port 135. This not only permits access to WMI – but also any other DCOM components which may be installed on a machine, open for exploitation by Trojans and the like. Needless to say, the ports are blocked by default for a reason – so require careful consideration of the implications when opening. WMI will also not help you if the machines you wish to tinker with are subject to NAT (Network Address Translation). You’ll be unable to reach these machines. The following script generates a txt file (the filename defined on line 2) of all the computers on your domain to be searched. This can then be edited with notepad to remove those you don’t wish to search.

$strCategory = "computer"
$strOutput = "c:\computernames.txt"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("(objectCategory=$strCategory)")

$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()
[bool]$firstOutput = $true
foreach ($objResult in $colResults)
{
$objComputer = $objResult.Properties;
if($firstOutput)
{
Write-output $objComputer.name | Out-File -filepath $strOutput
$firstOutput = $false;
}
else
{
Write-output $objComputer.name | Out-File -filepath $strOutput `
-append
}
}

The next script will generate a CSV (Comma separated values) detailing the network paths of the PSTS you need.

$strComputers = Get-Content -Path "c:\computernames.txt"
[bool]$firstOutput = $true
foreach($strComputer in $strComputers)
{
$colFiles = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query "Select * from CIM_DataFile `
Where Extension = 'pst'"
foreach ($objFile in $colFiles)
{
if($objFile.FileName -ne $null)
{
$filepath = $objFile.Drive + $objFile.Path + $objFile.FileName + "." `
+ $objFile.Extension;
$query = "ASSOCIATORS OF {Win32_LogicalFileSecuritySetting='" `
+ $filepath `
+ "'} WHERE AssocClass=Win32_LogicalFileOwner ResultRole=Owner"
$colOwners = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query $query
$objOwner = $colOwners[0]
$user = $objOwner.ReferencedDomainName + "\" + $objOwner.AccountName
$output = $strComputer + "," + $filepath + "," + $user
if($firstOutput)
{
Write-output $output | Out-File -filepath c:\pstdetails.csv
$firstOutput = $false
}
else
{
Write-output $output | Out-File -filepath c:\pstdetails.csv -append
}
}
}
}

This script will take as input a text file containing a list of machine names (conveniently the output of the first script), and will generate a csv file of all the pst files found on those machines, and the owners associated with them.

Find PST files across your network quickly and easily with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

A PowerShell cmdlet in the EMS is used to perform the action. Use of this cmdlet requires that the current user has Import Export mailbox roles on their profile. Exchange 2010 RTM also requires that Outlook 2010 x64 is installed on the machine. This is no longer a requirement of Exchange 2010 SP1.

So, to import a single PST file into an Exchange 2010 mailbox:

• Install Outlook 2010 64-bit on the Exchange Server. By default, on a machine with no pre-existing Office installation, the 32-bit applications will install from the DVD’s autorun setup. Be sure to manually run the install from the x64 directory to install 64-bit Outlook. This step is not necessary for Exchange 2010 SP1, as this includes a MAPI provider.
• Enable import permissions for a security group your user belongs to (in this case ‘Mailbox Support’) with the command:New-ManagementRoleAssignment -Name "Import Export Mailbox Admins" `
-SecurityGroup "Mailbox Support" `
-Role "Mailbox Import Export"

• Import the PST file into the appropriate user’s mailbox with the following command:Import-Mailbox -PSTFolderPath pstfilepath -Identity exchangealias 

Exchange 2010 SP1 differs a little in that you don’t need to install Outlook 2010 x64, and rather than the synchronous ‘Import-Mailbox’ cmdlet, the asynchronous ‘New MailBoxImportRequest’ can be used.

This takes the form of:

New-MailboxImportRequest -FilePath pstfilepath -Mailbox mailbox

One of the advantages of this new cmdlet (other than being asynchronous), is that you can specify an additional –IsArchive parameter, which will import the PST into the user’s archive mailbox.

I did experience a few problems using these cmdlets during  my research for this guide. The Exchange 2010 RTM Import-Mailbox on one system refused to play nicely, throwing the following error:

Error:
Error was found for XXX because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Not a lot of help in itself – a little Googling and experimentation revealed four main causes for this error:

1. The appropriate role permissions had not been added to the user’s security profile.
2. The version of MAPI being used had somehow got confused. Running the ‘fixmapi’ command from the command prompt should fix this.
3. The PST file is password protected.
4. There is a bug in Exchange.

In my case I’d unfortunately hit the fourth case and the work around proved to be pretty horrific It may simply be worth waiting for a fix from Microsoft. To complete my task, I had to temporarily add a new domain controller to my network to host a new Exchange 2010 server. I then moved the mailboxes for which I had PSTs to import to this new server, performed the import, then moved the mailboxes back to their original Exchange Server, and removed the temporary server from the network. Upgrading the system to 2010 SP1 and using the ‘New-MailBoxImportRequest’ cmdlet  on the same system yielded the following error:

Couldn't connect to the target mailbox.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MailboxImportRequest], RemoteTransientException
+ FullyQualifiedErrorId : 1B0DDEBA,Microsoft.Exchange.Management.RecipientTasks.NewMailboxImportRequest

Again, this appears to be a known issue, and apparently due to be fixed before the release of SP1.

In my next post I will go through finding PST files on your network the manual way.

Automatically import PST files into Exchange 2010 with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

Error:
Error was found for (username) because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo          : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Here is how I worked round it.

After doing some digging,  I found the site http://www.korneel.nl/?p=28 that  identifies most of the problems you might hit importing a PST file.

The cause for the error in my case transpired to be an acknowledged (according to the blog post) bug in exchange, presumably with an upcoming hotfix. However, it seems to be a generic error for all ills, as other solutions on the web suggest using the ‘fixmapi’ command (though admittedly referring to exchange 2007…). http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/82424f36-2611-4188-808e-df9aad36a5b7 (And the most common suggestion being adding the import export role to the user account.)

Another potential pitfall is the requirement for the 64bit version of outlook 2010 to be installed. It’s worth noting that by default an installation of Office 2010 on a clean machine will install the 32bit version.

As an unrelated aside,  installing the SP1 beta on exchange also caused a few problems – it required the manual installation of several hot fixes – and more annoyingly one package (UCMA 2.0 Runtime 64bit)– which despite coming as an ‘msi’ installation package, and on running giving all the signs it had installed successfully – had actually only ‘installed’ the installation files, which then had to be run separately. I’m sure these niggles will be ironed out before SP1 is released, but it wasn’t the friendliest of upgrades.

PST Importer 2010 provides a simple and transparent way to find and import PST files into Exchange 2010. To find out more information and to download a free 14 day trial please visit: www.red-gate.com/products/pst_importer_2010

This is much easier in Exchange 2007 than it was in Exchange 2003 as here we can use PowerShell. I would like to mention that in case of using Ex 2007, we don’t even have to create the users in advance, the server will take care of that for you. For the full 2007 PowerShell reference guide please see this page http://technet.microsoft.com/en-us/library/bb123703%28EXCHG.80%29.aspx#NthruR

In short, in order to create a new user type in:

New-Mailbox -Name <String> -Database <DatabaseIdParameter> -Password <SecureString> -UserPrincipalName <String> [-DisplayName <String>] [-FirstName <String>] [-Initials <String>] [-LastName <String>]

You might notice that if you simply type a string in for the password you’ll get an error:

New-Mailbox : Cannot bind parameter 'Password'. Cannot convert value "[given_password]" to type "System.Security.SecureString". Error: "Invalid cast from 'System.String' to ‘System.Security.SecureString'."

The reason for this is that the given password has to be a secure string type. In order to create it, type in the following (has to be separate from the previous command):


$Password = ConvertTo-SecureString '<string>' -AsPlainText –Force

After this you could refer to the given password as $Password.

We usually use this command in two different ways. The first one is to use a scripting language (my preference is Python) to generate the commands with different names. I have a list with the thousand most popular first names and the thousand most popular surnames. My script simply combines the two, giving me quite a lot of options. The second method is to name the users using a counter such as User 1; User 2;… User n and use a cycle in PowerShell to generate all required user names, such as:

$Password = ConvertTo-SecureString '<password>' -AsPlainText –Force

for ($i=0; $i -le 10; $i++)

{

New-Mailbox –Name <name>$i -Database <dbname> -Password $Password -UserPrincipalName <UPname> -DisplayName "<name> $i" -FirstName <firstname> -LastName $i

}

If someone doesn’t like PowerShell or doesn’t have it (e.g. Exchange 2003), the batch files I mentioned earlier used in active directory work just fine. After creating the users using those the mailboxes can be assigned to them fairly easily. In Exchange 2007, we have to start the “create new mailbox” process and select “existing users” in the first window.

This will show all users in AD that don’t have mailboxes. Fortunately multiselection is allowed so we don’t have to handle them one by one. Exchange 2003 doesn’t have this feature but there’s an easy workaround. Do a search using Exchange 2003’s Active Directory Users and Computers application for all users and multiselect them. Right clicking once will open the context menu where we can select “Exchange tasks” and “Create exchange mailbox” from there.

Finally, the command to add full access rights to a specific user so all mailboxes could be opened (and managed) from one outlook:

foreach ($sg in Get-StorageGroup) { if ((Get-ExchangeServer
$sg.Server).Domain.Equals("DomainName.com")) { get-mailboxdatabase
-storagegroup $sg.Identity | add-adpermission -user UserName
-accessrights GenericAll; } }

Are you planning to use the Personal Archive feature in Microsoft Exchange 2010 to get rid of all those nasty PST files on your network?

In a way, it is a reasonable call: with the secondary mailbox of Exchange 2010, your users will not need to generate PST files to try and comply to their mailbox quota limits….
… but you now have a new dilemma: what do you do with all the PST files already spread over your network?

Here are your options:

1. Do nothing –> I wish you good luck next time one of your end users contacts you because they lost a VERY IMPORTANT email.
2. Let your users import manually (or not) their PST files into exchange –>  Go to 1)
3. Take action to deal with this PST hell –> import them into Exchange yourself.

Sadly, Microsoft doesn’t make the import easy to do. For some reason, they got rid of the functionality in the Exchange Management Console GUI, and we are left with just a cmdlet, that is apparently rather  clumsy.

This is why Red Gate Software are currently developing a tool for a PST search and import into Exchange 2010. It is based on the existing PST Importer tool developed to complement Exchange Server Archiver, but works independently with Exchange 2010. It is still work in progress, but here is a preview of the tool:

Step 1 (optional if you know where your PST files are located): Find the PST files on your network, via a 4 step wizard.

Step 1: Find the PST files on your network.

Step 2: Search is completed (in this case returned 4 files) . Select the files you want to import, and click “New import list” to initiate the import.

Step 2: Search is completed (in this case returned 4 files)

Step 3: Set the destination mailbox. In this case, we automatically select the PST file owner, Anne.

Step 3: Set the destination mailbox

Step 4: Click “Import all now” to start the import.

Step 4: Start the import.

Et voila, now Anne can access her PST files in Outlook:

PSTs are imported and visible in Users’ Outlook mailboxes

So what do you think? Better or worse than a cmdlet? Post your opinion here! We’d love to hear your thoughts – the good, the bad, and the ugly.

1. Find out how big (or hopefuly small!) our own PST problem is, and
2. Test our new PST Importer tool

To accomplish both objectives we used Microsoft System Center Configuration Manager 2007 R2 to deploy the PST Importer Agent to all corporate desktops.This is how we did it! With the System Center Configuration Manager infrastructure (SCCM) in place, the default collection “All Windows Workstation or Professional Systems” was selected to push the PST agent to PCs running the SCCM client agent.

The PST Agent 32 & 64 bit .MSI installer,  were added to the system center software distribution packages for silent deployment to Windows 7 x64 and Windows XP x86.

A previous deployment of the ESA outlook plugin, included the Microsoft .NET Framework Version 2.0.  Therefore the client PC ‘s met the PST agent prerequisite.

Create the PST Importer Agent package manually

1. In the Configuration Manager console, navigate to System Center Configuration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Packages, point to New, and then click Package.
3. Use the New Package Wizard to create a software distribution package, specifying general information, data source, distribution settings, and other information for the new package.

Create the PST Importer agent package manually

4. Use the Data Source page in the Configuration Manager 2007 New Package Wizard to specify the file location of the PST Agent. msi

Create the PST importer Agent package manually

5. Complete the wizard with your preferred options

Create the PST Importer Agent Install Program manually

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution / Package / Red-Gate Software PST Importer Agent
2. Right-click Programs, point to New, and then click Program.
3. Use the New Program Wizard to create a program for a software distribution package:

-For the Silent 32bit install program we use the command line:

msiexec /i “PST Agent_1.0.0.852_x86_r103425.msi” /qn /norestart CENTRALSERVICEHOST=myESAserver.mydomain.com  (myESAserver.mydomain.com being where the pst importer tool is installed).

-For alternative installer options , please refer to: Command-Line Switches for the Microsoft Windows Installer Tool  http://support.microsoft.com/kb/227091

Create the PST Importer Agent Install Program manually

4. Then create a new program for the x64 for version (repating the steps above)

Create the PST importer Agent Uninstall Program manually

1. Repeat the above program install steps, using the msiexec /uninstall command line:

msiexec /uninstall ” PST Agent_1.0.0.852_x64_r103425.msi” /qn /norestart CENTRALSERVICEHOST=myESAserver.mydomain.com

Create the PST Importer Agent Uninstall Program manually

Create the PST Importer Agent package from a Package Definition File

Alternately you can create the PST importer Agent package and programs from a Package Definition File.

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Packages, point to New, and then click Package from Definition.
3. Use the Create Package from Definition Wizard to create a software distribution package based on an existing package definition file.
4. Use the Package Definition page in the Configuration Manager 2007 Create Package from Definition Wizard, to select the PST Agent_1.0.0.852_x86_ r103425.msi

Create the PST Importer Agent package from a Package Definition File

5. Then edit command lines to suit your requirements

Command-Line Switches for the Microsoft Windows Installer Tool  http://support.microsoft.com/kb/227091

Select the Client operating Systems the agent should run on

Use the Requirements tab in Software Distribution PST Agent –silent -32bit program  Properties dialog box to specify program requirements, including the client platforms on which the program will run.

Select the Client operating Systems the agent should run on

The 32 bit and 64 bit PST agent programs were advertised to all PC’s, so we selected which agents can run on which operating systems.

Copy the package to a distribution point

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution / Red-Gate Software PST Importer Agent
2. Right-click the Distribution Points node, and then click New Distribution Point.
3. Use the Copy Package Wizard to select the destination distribution point and the package to copy.

Copy the package to a distribution point

4. Verify that the package has copied – navigate to Red-Gate PST Importer / Package Status /Package Status /sitenmame/  -the status should be “installed”

Copy the package to a distribution point

Create an Advertisement

You will need to have a collection for to advertise the program too. Please refer to the Microsoft documentation http://technet.microsoft.com/en-us/library/bb694134.aspx

We used the default “All Windows Workstation or Professional Systems” collection but you can create your own specific collection of PCs

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Advertisements, point to New, and then click Advertisement

Create an Advertisement

3. Use the New Advertisement Wizard to create an advertisement, specifying general information, the collection to which the advertisement should be distributed, the run schedule, and other information for the new advertisement.-

We deployed the tool using a mandatory assignment running at logon and selected “Run program from distribution point”

Create an Advertisement

The mandatory assignment meant that our users were not required to Run the program form advertised tasks. The Agent was deployed to the user without the users interaction

We always advertise tasks at least 10 minutes into the future, to ensure that the task is not out of date when the it reaches the client.

We chose to run the prgoram form our disrtutbion point so the user would not be propeted to download the agent.

Create an Advertisement

Trobuleshooting the Installation

1. View the status of an advertisement

In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / System Status / Advertisement Status.

2. Client Event Viewer

 


Client Event Viewer



Client Event Viewer

 

3.SCCM reports

Report Name- Last 1000 messages for a specific computer (Errors, Warnings, and Information).

SCCM Reports

The report “All advertisements for a specific collection” is also helpful in demitting success:

The report “All advertisements for a specific collection” is also helpful in demitting success

The 144 rejected are 32 bit machines and the 37 succeeded / accepted are 64 bit

The 62 machines are turned off. The 32 bit installer:

The 32 bit installer

System Status -> Advertisement status-

System Status -> Advertisement status-

Msi logs

To troubleshoot installation errors add     “/l*v c:\PSTagent.log” to the msiexec command line.