crminthefield: Walkthrough: Easily locate objects in ActiveDirectory by Guid

[Blog bot]

Источник: http://blogs.msdn.com/b/crminthefiel...y-by-guid.aspx
==============

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 '' [PrivilegeReportGroupId],
''[PrivilegeUserGroupId],
''[ReportingGroupId],
''[UserGroupId],
'' [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. 

 

Sean





Источник: http://blogs.msdn.com/b/crminthefiel...y-by-guid.aspx