≡ Menu

Error: “Couldn’t find the Enterprise Organization Container” when Creating a New Mailbox Export Request

One of my colleagues hit me up the other day when he ran into a problem trying to export a mailbox to a .pst file using the New-MailboxExportRequest cmdlet. The *-MailboxExportRequest cmdlets are new in Exchange 2010 SP1, and there is a great article over here on Steve Goodman’s blog if you need more details on how the import/export process works in SP1. Anyway, my colleague was receiving the following error when trying to perform a mailbox export from the shell:

Couldn’t find the Enterprise Organization container.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MailboxExportRequest], OrgContainerNotFoundException
+ FullyQualifiedErrorId : AB0EB1E4,Microsoft.Exchange.Management.RecipientTasks.NewMailboxExportRequest

After a quick Google search I didn’t find anything relating to this error and mailbox export requests, so I went to my lab to see if I could reproduce the problem. As it turns out, this is one of those misleading errors that can possibly send you down the wrong troubleshooting path. The problem is actually related to a lack of permissions on the shared folder being used as the target for the .pst file. To solve the issue, ensure you have:

  1. NTFS Permissions. Make sure the Exchange Trusted Subsystem group has at least read and write capabilities on the share being used as the target for the .pst file.
  2. Share Permissions. Of course, you need share permissions as well. Make sure that Exchange Trusted Subsystem group has at least read and change share permissions.

For example, the bare minimum NTFS and Share permissions permissions for the “data” folder are shown below:

Once the permissions are set, you should have no problems exporting a .pst to the share.

10 comments… add one

  • Joseph M. January 4, 2011, 7:47 am

    Thanks for the info, but in my case it is not solving the problem.

  • Mike Pfeiffer January 4, 2011, 9:30 pm

    Sorry to hear about that…I’ve run into the problem twice now and both times it was related to incorrect share/ntfs permissions. You might want to try creating a share on another server and seeing if that makes any difference.

  • Julien A. January 20, 2011, 7:31 am

    Do you add user to RBAC import export role ?

    New-RoleGroup “Mailbox Import-Export Management” -Roles “Mailbox Import Export”
    Add-RoleGroupMember “Mailbox Import-Export Management” -Member

    And if you just done it don’t foget to restart windows session ;-)

  • Mike Pfeiffer January 20, 2011, 7:47 am

    Yes, if the role is not assigned and the cmdlet is not available, you’ll get an error that ‘New-MailboxExportRequest’ is not recognized as the name of a cmdlet. However, when the role is assigned and you can actually run the cmdlet, you still need to have the correct permissions on the network share, which was the issue in this case.

  • Chuck V. June 8, 2012, 10:40 am

    That worked for me!

    I had to do all the following:
    New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “administrator”
    Created a share with r/w permissions
    New-RoleGroup “Mailbox Import-Export Management” -Roles “Mailbox Import Export”
    Add-RoleGroupMember “Mailbox Import-Export Management” -Member administrator
    before the following would work.
    New-MailboxExportRequest –Mailbox “alias” –Filepath “\servernamesharefile.pst”

  • Rob Curls February 3, 2012, 1:52 pm

    Hey Mike,
    I came across this today in an SP2 environment. It looks like in SP2 you are able to see the new-mailboxexportrequest command prior to assigning your user account the permissions. If you run the command without adding the account to the appropriate role group it will give the same “could not find the enterprise organization container” error.

    Rob

  • Mike Pfeiffer February 7, 2012, 7:15 pm

    Thanks Rob!

  • Jackie Butzbach February 24, 2012, 4:16 pm

    I just have to say that this particular blog is invaluable information regarding Exchange 2010. So easy to read, understand and follow and saved me. Thank you very much.

    p.s. Any ideas what I can do with Global Security groups that are also distrabution groups that had a bunch of parenthesis in the old naming convention from 2003? I know that they will need to be turned into Universal security groups, but is there anyway to just rename groups so that they have the same permissions on files and folders without having to go and figure out what all the permissions are?

    Thanks again,

  • Mike Pfeiffer February 25, 2012, 10:03 am

    Thanks Jackie.

    The Exchange team published a script some time ago called Fix-alias.ps1. This script allows you to identify and modify users, contact and distributions lists that have invalid characters in the alias. See if that helps. Existing permissions for your groups would be retained.

    http://gallery.technet.microsoft.com/scriptcenter/411aec4e-8c01-4594-b993-fbd968f15399

  • SysAdmin-E.com December 4, 2012, 11:51 am

    Running Exchange 2010 SP1 with no rollups. I had both issues – incorrect RBAC role and folder/share permissions. I had added a new VMDK to the Exchange server and wrongly assumed that Exchange would have somehow automatically granted the Exchange Trusted Subsystem group permission to that drive. My exports are working now, thanks to info from this post.

Leave a Comment