Searching...
Tuesday, 20 May 2014

5 Most Common “New-MailboxExportRequest" Powershell Script Issues and Their Solutions

PowerShell cmdlets, the task automation and configuration management framework from Microsoft has become important throughout its product release cycle in the recent years. This is shaping all the tools and technologies that are coming out of their stable.

There are many useful powershell cmdlets available and one of the most important powershell scripts introduced by Microsoft for Exchange 2010 is New-MailboxExportRequest.

New-MailboxExportRequest cmdlet is used to start the process of exporting components of a main mailbox or archive to a .pst file. But while performing the export process using this cmdlet, if any hardware or software problem occurs in between, or cmdlet has not been properly executed or if wrong syntax of the cmdlet has been given, then these issues can lead to many errors which you can encounter in between the process and thus, export process could get a full stop if those errors are not fixed.

In this article, we are going to discuss such common errors which are being faced by the users while performing the Export process and check out their solutions as well.

1. Error Code “0x80040115” – Unable To Export Large Mailboxes to PST

When you notice this error, it normally points to a problem with connection to one of the stores engaged in the process.

In this case, the connection to the PST is the issue, because the PST is being accessed across the network. The PST is being put in a share on the Windows workstation on which the Exchange Management Shell (EMS) was used to run the command.

The main question that is required to be answered in the process was, "What to do to have PST on the same machine that the export process is running on so that it does not need to go over the network?"

To answer that, you need to look at how the export process runs:

1) In Exchange 2010, your PowerShell operations are remote and are always being executed on an Exchange server; they are not executed on the machine running the Shell, except you are on the Exchange Server and the shell has connected to the machine you are on. So, even if you are running the EMS on a workstation, it in fact connects to one of your Exchange servers, and all commands are executed on that server.

2) The MailboxExportRequest uses the Mailbox Replication Service (MRS), just like a Mailbox Move does. This means that any CAS server running the MRS Service, which by default is all CAS servers, could be the CAS server to run the export. You can state a particular CAS to use with the –MRS Server switch in your New-MailboxExportRequest command.

So, perform these two steps given below:

1) Create a folder/share on CAS server 1, and give the Exchange Trusted Subsystem ‘Read/Write’ access to the share as directed in http://technet.microsoft.com/en-us/library/ff607299.aspx.
2) Specify the new share as your file path in the command, and also specify CAS 1 in the –MRS Server setting in your New-MailboxExportRequest command (i.e. New-MailboxExportRequest -Mailbox user1 -FilePath "\\CAS1\PSTFileShare\user1.pst" -MRSServer CAS1.domain.com).

Fix "New-MailboxExportRequest" Powershell Issues & Export EDB to PST Easily with Stellar EDB to PST Converter.

2. Error in New-MailboxExportRequest - “Couldn't find the Enterprise Organizational Container”

Supply values for the following parameters:
FilePath: \\localhost\EXPORT_PST\myuser.pst
Mailbox: myuser
Couldn't find the Enterprise Organization container

In Exchange SP2, you are not informed that you have not set role assignments, it just fails. So be sure to make a management role for "Mailbox Import Export" and add your user to the group, then restart PowerShell for this to take effect.

3. New-MailboxExportRequest fails when content filter is used with non-US date formats

FailureCode: -2146233088
FailureType: InvalidContentFilterPermanentExceptionMessage
Error:
ContentFilter is invalid. The value "20/05/2014 12:00:00 AM" could not be converted to type System.DateTime.

There is a bug when using the New-MailboxExportRequest powershell script in Exchange 2010 and stating a content filter using dates in non-US format. The New-MailboxExportRequest cmdlet will only recognize dates in US formats. Something has to be the default date time and Microsoft is a US-based company, so no point in getting emotional, let us just resolve it.

Here is a neat trick which can be used to set the Culture of the "Current Thread" you are running.

[System.Reflection.Assembly]::LoadWithPartialName("System.Threading")
[System.Reflection.Assembly]::LoadWithPartialName("System.Globalization")
[System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo]::CreateSpecificCulture("en-us")

Add-PSSnapin *exchange*

$start = (get-date).adddays(-28)
$end = (get-date).adddays(-14)

$filter = "(Received -gt '"+$start+"') -and (Received -lt '"+$end+"')"
New-Mailboxexportrequest -mailbox SOMEMAILBOX -ContentFilter $filter -filepath C:\SOME.p

4. Exchange 2010 Mailbox Export failing - Get-Mailbox -OrganizationalUnit "OU=Active,OU=Users,OU=London,DC=domain,DC=local" | New-MailboxExportRequest -FolderPath \\server\folder\$($i.Alias).pst

A positional parameter cannot be found that accepts argument '\\server\folder\.pst'.
    + CategoryInfo: InvalidArgument: (:) [New-MailboxExportRequest], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,New-MailboxExportRequest

The problem is this bit: $($i.Alias) - it doesn't identify the command and consequently you get the error you are seeing.

Try this script instead:

# Specify OU which Users Mailbox should be exported 

$ou = "OU=End,DC=Contoso,DC=LOCAL"
$user = Get-ADUser -SearchBase $ou -Filter * -Properties * | Select-Object Name
$user.name
## Loop in Each user ##
Foreach($End in $user.name)
### its not the complete code/script, please download the complete code to work ##
### Dont Forget to Rate it ##

5. New Mailbox Export Request Returns Access Denied

The New-MailboxExportRequest and New-MailboxImportRequest powershell scripts need a UNC path for the FilePath parameter. In other words, you can’t use “New-MailboxExportRequest -Mailbox MailboxName -FilePath C:\output.pst”. You have to use “New-MailboxExportRequest -Mailbox MailboxName -FilePath \\servername\sharename\output.pst”. Though, if the share and NTFS permissions are not set properly on the destination path, you could get an error like this one.

Unable to open PST file ‘\\servername\sharename\output.pst’. Error details: Access to the path ‘\\servername\sharename\output.pst’ is denied.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MailboxExportRequest], RemotePermanentException
+ FullyQualifiedErrorId : D7BD75A8,Microsoft.Exchange.Management.RecipientTasks.NewMailboxExportRequest

The issue is that the New-MailboxExportRequest and New- MailboxImportRequest powershell scripts don’t run in the user context, rather run in machine-context. You should grant the Exchange Server access to the shared drive. If you are executing the powershell scripts on ExServer01, then you should add ExServer to the share and NTFS permission.

If you are not able to get rid of these errors by performing the steps given above, then what will you do then? Don’t worry! You can make use of any third party tool such as Stellar EDB to PST converter, which will help you export PST files from Exchange server easily and quickly and you won’t face any type of error while using this tool to export PST. Check out more about this tool at http://www.stellarinfo.com/email-repair/edb-pst-converter.php

0 comments:

Post a Comment