Duane Wolff's Tech Blog

Spring time… the birds are chirping, the gentle rains are falling and the boss is wanting the MOSS environment to talk to another AD domain. Thus, this post will deal with a specific command (peoplepicker-searchadforests) in the Active Directory integration feature set in SharePoint. Besides the usual user import in the SSP, SharePoint has a plethora of different features related to pulling users from other forests and domains, as well as authentication to those domains. Most of us have, at one point or another, used the peoplepicker to pull in a person to grant them access to a list, library or site. “What if that person isn’t a member of the domain that my machines are hosted upon?” “Do I need to make more accounts on my users domain now?” Fortunately, no. The command string “stsadm -o setproperty -pn peoplepicker-searchadforests -pv “forest:mydomain.local,forest:myotherdomain.net”,DOMAIN\ USERNAME,PASSWORD -url http://mysite.mydomain.com” is all you need to set SharePoint looking at 2 different domains for users. If you haven’t run this before, you’ll also need to run the following: “stsadm setapppassword -password “MYPASSMAN”" (without quotes) on each web front end server. The setproperty function is used to set a specific property to a value we specify, easy thus far, right? The peoplepicker-searchadforests property is used to set which AD forests we’ll use to populate users in our Peoplepicker. Then we specify the domain(s) we’re interested in using and provide an administrative credential for SharePoint to use when getting users. the last piece is to specifiy the URL we’re desirng to work with. This isn’t a farm change but a site collection change and we’re done. When specifying the URL make sure you include the HTTP:// as SharePoint balks when it encounters a URL without the http and willl throw the ever-cryptic “COMMAND LINE ERROR”. Hope this has helped some admins out there with your hair intact.

Thanks again!

Duane

What is it with Microsoft and renaming product lines?!?!  First, SharePoint Team Services 2001, then SharePoint Server 2003,  on to Microsoft Office SharePoint Server 2007 and now back to SharePoint Server 2010.  Anyway, enough rants, let’s get onto a review.  First, install was buttery smooth, not ONE hitch, even on a non-spec box.  They want a minimum of 4GB of RAM and now I see why.  SPS2010 HAMMERS a server with services, requests and, if you chose the standalone option, database hits.  Apart from a monster box with oodles of resources, don’t expect it to fly.  When it installed and PSCONFIG (I assume that’s what they’re calling it as I haven’t heard different) finished, I was presented with a decent looking Central Admin site.  Not the ground-shaking change that SPS2003 to MOSS was but it was still WAY different.  I felt the social tags on Central Admin were a bit much (what, we REALLY like Central Admin now and want to share with our friends?!?!) but other than that, it’s a true improvement over what was there before.  Total setup time from bare metal box rebuild to opening Central Admin was 1 Hr, 48 Minutes.  Nice and fast in case I need to turn up a farm or five.  More unboxing, installing, etc. later as I get time.  Thanks for reading!!!

Hello

I don’t know if you’re like me but when I have to keep deleting error dump files on a 250GB partition or the TEST environment’s SQL Server will lock up, it’s annoying to say the least.  I also had the issue where the TEST SharePoint full crawl wouldn’t stop, no matter what I did.  Stop the service?  Didn’t work.  Run STSADM -o execsvcjobs?  Also, didn’t work.  I installed SQL Server 2005 SP2 on our TEST SQL machine and both the errors and the crawl stopped.  Checking on it now but that appears to have worked.  UPDATE: yup, it worked.  There are no error dumps in the log folder and SharePoint is humming along nicely.