locked
Database '<GUID>' doesn't exist - New-MoveRequest RRS feed

  • Question

  • We have just introduced our new Exchange servers into the Exchange Org and are testing the first mailbox moves. Trying to move a legacy (Exchange 2003 mailbox) to the Exchange 2010 mailbox server. Getting the error: Database 'ec10c506-a323-4840-8208-0d4ede411c3f' doesn't exist. I take it this is the objectGUID associated with the source database? It is the GUID associated with the SystemMailbox residing in the source database. Even with verbose mode I am not getting any further clues as to why the move request seems to think the source database doesn't exist. I'm not sure what permissions the new Exchange 2010 groups need to have across legacy Exchange servers and mailbox stores as I have nothing to compare to. I assume this is a permissions issue which is just not being described very well. Can anybody help?

    [PS] C:\Windows\system32>new-moverequest -identity 'test.mbx5@domain.co.uk' -TargetDatabase 'Lastname (A-C)' -Verbose
    VERBOSE: [15:22:23.069 GMT] New-MoveRequest : Active Directory session settings for 'New-MoveRequest' are: View Entire
    Forest: 'False', Default Scope: 'child.root.net', Configuration Domain Controller: 'RDC01.root.net',
    Preferred Global Catalog: 'HDC01.child.root.net', Preferred Domain Controllers: '{
    GBDCS01HDC01.child.root.net }'
    VERBOSE: [15:22:23.069 GMT] New-MoveRequest : Runspace context: Executing user: root.net/root/Admin/Admin
    Accounts/Admin, Executing user organization: , Current organization: , RBAC-enabled: Enabled.
    VERBOSE: [15:22:23.069 GMT] New-MoveRequest : Beginning processing &
    VERBOSE: [15:22:23.069 GMT] New-MoveRequest : Instantiating handler with index 0 for cmdlet extension agent "Admin
    Audit Log Agent".
    VERBOSE: [15:22:23.069 GMT] New-MoveRequest : Searching objects "root (A-C)" of type "MailboxDatabase" under the
     root "$null".
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Previous operation run on domain controller 'RDC01.root.net'.
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Current ScopeSet is: { Recipient Read Scope: {{, }}, Recipient Write
    Scopes: {{, }}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive Recipient Scope(s):
     {}, Exclusive Configuration Scope(s): {} }
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Searching objects "test.mbx5@domain.co.uk" of type "ADUser" under the
     root "$null".
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Previous operation run on domain controller
    'GBDCS01HDC01.child.root.net'.
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Processing object "$null".
    VERBOSE: [15:22:23.084 GMT] New-MoveRequest : Searching objects "SourceMBXServer\First Storage Group\Lastname (S-Z)" of
    type "MailboxDatabase" under the root "$null".
    VERBOSE: [15:22:23.100 GMT] New-MoveRequest : Previous operation run on domain controller 'RDC01.root.net'.
    VERBOSE: [15:22:23.100 GMT] New-MoveRequest : Searching objects "Lastname (A-C)" of type "MailboxDatabase" under the
     root "$null".
    VERBOSE: [15:22:23.100 GMT] New-MoveRequest : Previous operation run on domain controller 'RDC01.root.net'.
    VERBOSE: [15:22:23.100 GMT] New-MoveRequest : [DEBUG] No RequestJob messages found.
    VERBOSE: [15:22:23.116 GMT] New-MoveRequest : [DEBUG] MDB becfe764-9380-47e4-a400-296a924d8b9f found to belong to Site:
     root.net/Configuration/Sites/Site1
    VERBOSE: [15:22:23.116 GMT] New-MoveRequest : [DEBUG] MRSClient: attempting to connect to
    'EXC02.child.root.net'
    VERBOSE: [15:22:24.413 GMT] New-MoveRequest : [DEBUG] MRSClient: connected to 'EXC02.child.root.net', version
     14.1.218.11 caps:07
    VERBOSE: [15:22:24.413 GMT] New-MoveRequest : [DEBUG] Loading source mailbox info
    VERBOSE: [15:22:24.428 GMT] New-MoveRequest : Database 'ec10c506-a323-4840-8208-0d4ede411c3f' doesn't exist.
    VERBOSE: [15:22:24.428 GMT] New-MoveRequest : Admin Audit Log: Entered Handler:OnComplete.
    Database 'ec10c506-a323-4840-8208-0d4ede411c3f' doesn't exist.
        + CategoryInfo          : NotSpecified: (0:Int32) [New-MoveRequest], RemotePermanentException
        + FullyQualifiedErrorId : BDA592E6,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

     

    Environment overview:

    AD: One root domain (root.net), one child domain (child.root.net).
    Exchange: One Exchange Organisation

    Legacy Exchange environment: 6 Exchange 2003 back end servers, 2 Exchange 2003 front end servers - all SP2. Spread across 6 locations.
    New Exchange environment: At the moment: 2 Exchange 2010 mailbox servers and 2 CAS/Hub servers.

    Friday, February 25, 2011 4:28 PM

All replies

  • Anyone have any ideas how one might go about troubleshooting this or is a call into MS now due?

     

    Thanks

    Monday, February 28, 2011 9:28 AM
  • In case anyone is interested, this did turn out to be a permissions problem (I know MS and their error descriptions too well to think otherwise!). A reminder what the error description was:

    Database 'ec10c506-a323-4840-8208-0d4ede411c3f' doesn't exist.

    The issue is due the Exchange 2010 prep tasks failing to permission any legacy Exchange servers which are set to NOT INHERIT permissions form the Administrative Group or Organisation Level (Set via Delegate Control). In our environment, we granted IT staff their permissions based on which specific sites they administered. We therefore had to disable inheritence from the top and configure it almost independently at the server level.

    One slight oddity is even if you set your legacy Exchange server's security to inherit from above, the permissions that filter down cannot be found listed within the Delegate Control wizards for the Admin Group or Organisation. I can only think this is because they are very granular in nature.

    Bottom line is server level permissions must be set to inherit. Therefore, anyone attempting to migrate mailboxes from Exchange 2003 servers in very large environments (where there may have been a requirement to do something clever with permissions in the past), make sure you've got a plan to collapse them down before any Exchange 2010 project. If you don't set them to inherit you are looking at the arduous task of adding in the permissions manually (a quick check reveals they are extremely granular).

    MS TechNet editors: Please validate and then incorporate into your Exchange 2010 documentation.

    Monday, February 28, 2011 4:43 PM