Walkthrough: Easily locate objects in ActiveDirectory by Guid

Often times we have the need to confirm the location of the CRM Groups in Active Directory (AD) or find what AD object a user account in CRM is pointed to.  Most recently our team had to re-image a server and as part of that process we had to confirm the location of all our CRM groups in Active Directory.  If you spend some time searching the internet or talk to people familiar with supporting and searching AD, you’ll find there are a lot of ways to search and everyone seems to use a different utility or process.  As part of our job supporting customers, we like to leverage utilities already installed with the operating system if possible.  Luckily Windows Server 2008 provides us a utility to search AD (Note on Windows Server 2003 LDP is part of a separate installation titled: “Windows Server 2003 Support Tools”). 

Take the following example: your CRM project manager has asked you to confirm and document what AD groups your Dynamics CRM deployment relies on.  You could look back at your notes from the CRM 2011 or 4.0 installation, you could take an educated guess, you could even use Netmon to trace CRM’s queries to AD, but there’s an easier and quicker way you can retrieve this information and avoid all the guess work. 

In this example I’ll show you how you can use information from the MSCRM_Config database and leverage LDP to find the CRM group information located in Active Directory. 

1. Contact your SQL DBA and have them run the following query for you against your MSCRM_CONFIG database.  This query will retrieve the GUID’s of each group used by CRM – I’ve also applied the proper syntax to the Guid’s in the select statement to make searching with LDP a little easier. 

select '<GUID='+CAST(PrivilegeReportGroupId as Varchar(50))+'>' [PrivilegeReportGroupId],
'<GUID='+CAST(PrivilegeUserGroupId as Varchar(50))+'>'[PrivilegeUserGroupId],
'<GUID='+CAST(ReportingGroupId as Varchar(50))+'>'[ReportingGroupId],
'<GUID='+CAST(UserGroupId as Varchar(50))+'>'[UserGroupId],
'<GUID='+CAST(SqlAccessGroupId  as Varchar(50))+'>' [SqlAccessGroupId]
FROM ConfigSettings

2. Your results will look something like this:


3. Open a command prompt (or use the Run box) and type “LDP.exe” and press Enter to launch the LDP utility (note: LDP.exe is usually located in: C:\Windows\System32). 


4. In LDP click the Connection Menu, then click Connect


5. Leave the server name blank and confirm the port is set to 389 (if you want to search against a global catalog set the port to 3268). Leave the two checkboxes unchecked and press Ok to connect.


6. Now click the Connection menu again and click Bind


7. Leave the bind options all set to default and click Ok  you should now see a bunch of output by the LDP tool showing all the properties of the connection and binding information.


8. Now that you’ve connected you’re ready to search. To begin a search click Browse, then click Search to launch the Search dialog box.  In the dialog box, confirm your filter is set to:(ObjectClass=*) and paste one of the results from step 1 into the Base DN box, then select a Scope of Subtree.  Your search box should look something like this:


9. Now press Run to execute the search.  Once the search has run click the Close button to close the search dialog.  Now look at your results pane in LDP.  In the results you’ll find all the attributes listed from your search – along with the DN (which show’s you the location).  Here are the results from my test environment:



You can repeat steps 8 & 9 for all four groups to confirm the locations & object names.  Also, this same process will apply to searching for users by their ActiveDirectoryGuid (stored on the SystemUser in the systemuserbase table).  Finally, don’t forget that LDP can be used for searching nearly anything in AD – if you support other applications or anything related to AD, LDP can be one of the many utilities in your arsenal to make your job a little easier. 



Comments (5)

  1. Upgrading from MS CRM 4.0 to MS CRM 2011 says:

    Hi Sean,

    I have a quick query regarding the organzational unit. If we are upgrading from MS CRM 4.0 to MS CRM 2011.

    During the import organization wizard, does it attaches the migrated organization with the old OU (crm 4.0) or attaches with the new OU. I am a bit confuse on this bit.

    Appreciate if you can answer that query at your earliest.

    P.S. Eventually I want to upgrade from CRM 4 to CRM 2013 and I am doing migrate approach (new crm + new sql).



  2. Shawn Dieken says:

    Hey Ali-

    If you do an in place upgrade, then CRM would keep the same security groups in the same OU.  If you do a migration upgrade (which is sounds like you have planned for CRM 2013), then you would have new security groups created as that's a new CRM deployment.  Each CRM deployment has one set of CRM security groups in AD.  Here is a blog post on locating with CRM security groups belong to which CRM deployment.  blogs.msdn.com/…/how-to-find-which-active-directory-security-groups-belong-to-your-crm-deployment.aspx

    We recommend the migration upgrade approach like you are doing for CRM 2013 vs. the in place upgrade whenever possible.  It just allows for better testing, fallback, etc.


    Shawn Dieken

  3. CRM 4.0 to CRM 2013 upgrade says:

    Hi Shawn,

    1. As you have mentioned that every new CRM deployment creates new groups in AD. if you use the same OU for every deployment does the installation wizard creates new groups in the same OU or updates it. is it a good practice to create different OU for different evrionments i.e. DEVCRMOU , UATCRMOU, PRODCRMOU?

    2. While you importing an CRM 4.0 organization into the CRM 2011 instance, does it link this deployment with the old OU/Groups which were created as part of CRM 4.0 deployment because the guids are saved in the organization table.



  4. Francisco says:

    Hi Shawn and Sean,

    another great blog. Can you comment also on what needs to be considered before changing the OU name where CRM creates the AD groups? Is it safe to rename the OU or are there any side-effects.

    We are about to migrate from CRM 2011 (over 2013)  to 2015 and would like to rename the OU from CRM2011 to CRM. We are now wondering if this is feasible at all and if yes at what point during the migration process we should best rename it, before or after migration?

    Many thanks and best regards


  5. Luke says:

    Here is a complete SQL query so you don't have to use ldp.exe.

    declare @sql nvarchar(max);

    select @sql = replace(replace(stuff((

    select replace(N'

    union all

    select ''' + left(CrmGroup, len(CrmGroup)-2) + '''    as CrmGroup

    , cast(objectGUID as uniqueidentifier)           as AdGroupId

    , name                                           as AdGroupName

    , right(distinguishedName,

               len(distinguishedName) – case when charindex('',OU='', distinguishedName) = 0

                                             then charindex('',DC='', distinguishedName)

     else charindex('',OU='', distinguishedName) end) as AdPath

    from openrowset(''ADsDSOObject'', ''adsdatasource'', ''SELECT objectGUID, name, distinguishedName

    FROM ''''LDAP://domain.com/<GUID=' + cast(CrmGroupId as nvarchar(36)) + '>'''''')', nchar(13), '')

    from MSCRM_CONFIG.dbo.ConfigSettings

    unpivot (CrmGroupId for CrmGroup in (


    , PrivilegeUserGroupId

    , ReportingGroupId

    , SqlAccessGroupId

    , UserGroupId)) as unpvt

    for xml path('')), 1, 11, ''), '<' , '<'), '>', '>');

    exec sp_executesql @sql;


    Replace "domain.com" with your appropriate domain.

    If the user you are executing the SQL statement as  doesn't have AD permissions,

    replace "adsdatasource" with "adsdatasource;DomainUserName;UserPassword" substituting

    Domain, UserName, and UserPassword with appropriate values.


Skip to main content