How to find the Object that belongs to a GUID

When troubleshooting an error message which only displays a GUID, and does not make any reference to a specific object, there are several tools that are used to find that object: ADExplorer, ADFind...etc.

Since most Admins have the Support Tools installed, below is a description of an easier way to find that object, by using LDP.

The search has to be done on the Domain Controller.

Start-Run- LDP

Connection –> Connect


Connect using the Global Catalog port: 3268




Connection – Bind



View - > Tree




Right click on the domain -> Search



Under “Base DN” insert: <GUID=HereYouInsertTheGuid>

Under “Filter” insert: objectclass=*




Then click on Options, and change the limits as shown here:





If the time limit and/or the Timeout milliseconds are on 0 (as it is by default), then the search might not find anything, so it is recommended to increase those values.


Here the name of the user is “Greu Greuceanu”, and the results show a lot of information like: Distinguished Name,Creation date,UserPrincipalName, even the phone number:



If the error message comes in a similar format like:

Event ID: 9646
Description: Mapi session "
4034194C-21C1-4DC1-951D-652320577AN0 " exceeded the maximum of xxx objects ....

And the Event ID also only shows the GUID and does not point to any specific object, then the same steps as above should be followed, but the only difference will be that the criteria has to be modified since „Mapi Session“ means the search should be made for a Mailbox GUID.

This issue occurs if the Exchange Store.exe process cannot resolve the GUID to an msExchMailboxGuid attribute or to an objectGUID attribute. The Store.exe process may not be able to resolve the GUID if sibling domains exist in the same forest. A sibling domain is another domain that exists at the same level in the forest. When the Store.exe process tries to resolve the GUID, the Store.exe process sets the BaseDN parameter of the Lightweight Directory Access Protocol (LDAP) query to a value that is equal to the domain naming context of the user. If the Exchange server is in a sibling domain, the LDAP query returns no results.


If the GUID is not found in by searching with it’s original form, then it has to be modified as shown in the KB <>


Original GUID from the Event Log: 4034194C-21C1-4DC1-951D-651320577AN0

Divide it with backslashes: \40\34\19\4C\21\C1\4D\C1\95\1D\65\13\20\57\7A\N0

Invert the first 3 columns: \4C\19\34\40\C1\21\C1\4D\95\1D\65\13\20\57\7A\N0

(Leave the last 2 columns in their original form)

In the LDP, the search has to be done using:

Base DN: Just leave the Root Domain here

Filter: (&(objectclass=*)(msExchMailboxGuid=\4C\19\34\40\C1\21\C1\4D\95\1D\65\13\20\57\7A\N0))


And it should find the corresponding User.


Note: If there is any misconfiguration in the edited GUID such as one extra backslash or any hyphens, then the results will be NULL.

Comments (6)

  1. Rocco Daniele Ciaravolo says:

    Very useful and clear,
    thank you.

    Rocco Daniele Ciaravolo

    Cle IT staff

  2. Larry says:

    easy peasy. I can't understand why MS thinks this much work to find a mailbox by a guid is ok.

  3. Anonymous says:

    This is Part II of my previous blog "Migrate On premise Mailboxes to Exchange online Using Cutover

  4. Steven Gossner says:

    Really Cool

    Sr. System Admin Zephyrs International Global

  5. I second that! says:

    Found just what I was looking for in a flash.

  6. Bob says:

    Thought folks stumbling on this page might want a function which does it, so here you go (from

    function ConvertGuidToLdapSearchString(
    [parameter(mandatory=$true, position=0)]$Guid
    $guid_object = [System.Guid]$Guid
    ($guid_object.ToByteArray() | foreach { ‘\’ + $_.ToString(‘x2’) }) -join ”

    # example:
    ConvertGuidToLdapSearchString -Guid “a3acaee7-cb14-4466-83ce-1dd117b546dc”
    # returns: \e7\ae\ac\a3\14\cb\66\44\83\ce\1d\d1\17\b5\46\dc

Skip to main content