Here I was, banging my head into the proverbial wall over why in MOSS 2007 I was able to use a service account with read permissions to Active Directory, but when setting up SharePoint 2010’s User Profile Import to AD it kept breaking. Then I stumbled across this article. So I contacted out Network guys, who created a service account with permissions as indicated in this KB article:
And lo and behold, all problems are solved! SharePoint 2010 now imports user profiles from Active Directory without issues!
I’m unable to locate a working plug-in/snap-in for Active Directory Users and Computers that works on Windows 7. Fortunately, there’s a workaround that allows administration of ADUC in Windows 7 with a little modification.
First, you’ll need to download and install RSAT for Windows 7. It’s found here. You’ll need this before you can do anything else. Once this is installed, on your Windows 7 box, open Programs and Features and click the Turn Windows Features On or Off option. In the Windows Features box, locate Remote Server Administration Tools and expand the item. Expand Role Administration Tools, then expand the AD DS and AD LDS Tools item, then the AD DS Tools item. Check the box for AD DS Snap-ins and Command-line Tools. Click Ok and those features will be enabled.
The ADUC shortcut will be placed in your Administrative Tools under Control Panel just like it used to be.
Also note, this is for the 32 bit versions only. This hasn’t been tested on 64 bit, and others have complained that they couldn’t get this working on 64 bit.
If anyone else has a better method of administering ADUC on Windows 7 Pro please feel free to post a comment. Until then, hope this helps someone!
So I’m working on a small interface that needs to check certain computers in our enterprise for file changes, and fortunately these specific computers are kept in a group nested inside our AD structure. My thought was, if I can use a SQL query to go get that list of machines, put the results in a table, then have the interface read from that table it would always have a current list of these machines, with no maintenance required for adding and removing these PCs. Here’s what I came up with:
First, the database needs to have ad hoc queries enabled. This is done in the Surface Area Configuration for Features section of Surface Area Configuration on the affected DB server. You’ll need this in order to use commands such as OPENROWSET and OPENDATASOURCE. In this case, we’re going to use OPENROWSET. Set this first, then use the following query:
Obviously you’ll want to substitute the DOMAIN\username and password, as well as the LDAP://server and the memberOf sections for your network’s info, but this structure will work. Feel free to substitute distinguishedName for another property if you want different results.
I’m always getting, updating, and validating against AD info at my company, and today I needed to pull several different schema attributes in one method, and kept running into more and more trouble. Code got bigger and bigger, and I thought there had to be a way to simplify this. I then ran across a CodeProject article definitely worth mentioning. The author, Rajasekhara Sambangi does an excellent job of demonstrating a simplified way of pulling just about anything from AD by passing in the SearchResult object and the property name you’re searching for into a basic method, and the result is the value of the key! The link to the article is here.