I've got an WSS 3.0 installation. In the people picker, I can see AD groups that existed when I installed it, and I can see all new AD users, however I cannot see any new AD groups that have been created since the WSS installation. I have reviewed the STSADM commands "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn peoplepicker-searchadforests" to ensure they are correct (we only have one forest, and WSS is on our intranet). I read in a couple of places online that this behavior is by design, however, I've also read that WSS can read the AD all the time, in real-time, so I'm confused. Anybody know the truth?
"Rick Scott" wrote: > I've got an WSS 3.0 installation. In the people picker, I can see AD groups > that existed when I installed it, and I can see all new AD users, however I > cannot see any new AD groups that have been created since the WSS > installation. I have reviewed the STSADM commands > "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn > peoplepicker-searchadforests" to ensure they are correct (we only have one > forest, and WSS is on our intranet). I read in a couple of places online > that this behavior is by design, however, I've also read that WSS can read > the AD all the time, in real-time, so I'm confused. Anybody know the truth?
No, I have not found a solution. I've ensured that these are in fact global security groups and not distribution groups. The only other piece I have to this puzzle is our network administrators are in the process of moving groups from one OU to another, but they assure me that the domain account for SharePoint has permissions to read both the old and new OUs. SharePoint can only "see" the old OU, and was in the old OU until a about an hour ago when I requested that it be moved to the new OU as a test. That did not fix the problem, and I would have expected it to by now. I'll probably keep it there overnight just to see what happens.
"Vinicius Paluch" wrote: > Hi.. did you get it to work ? I´m facing the same problem.
> "Rick Scott" wrote:
> > I've got an WSS 3.0 installation. In the people picker, I can see AD groups > > that existed when I installed it, and I can see all new AD users, however I > > cannot see any new AD groups that have been created since the WSS > > installation. I have reviewed the STSADM commands > > "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn > > peoplepicker-searchadforests" to ensure they are correct (we only have one > > forest, and WSS is on our intranet). I read in a couple of places online > > that this behavior is by design, however, I've also read that WSS can read > > the AD all the time, in real-time, so I'm confused. Anybody know the truth?
> No, I have not found a solution. I've ensured that these are in fact global > security groups and not distribution groups. The only other piece I have to > this puzzle is our network administrators are in the process of moving groups > from one OU to another, but they assure me that the domain account for > SharePoint has permissions to read both the old and new OUs. SharePoint can > only "see" the old OU, and was in the old OU until a about an hour ago when I > requested that it be moved to the new OU as a test. That did not fix the > problem, and I would have expected it to by now. I'll probably keep it there > overnight just to see what happens.
> At this point I'm open to suggestions.
> Let me know if you have any success, > Rick
> "Vinicius Paluch" wrote: > > Hi.. did you get it to work ? I´m facing the same problem.
> > "Rick Scott" wrote:
> > > I've got an WSS 3.0 installation. In the people picker, I can see AD groups > > > that existed when I installed it, and I can see all new AD users, however I > > > cannot see any new AD groups that have been created since the WSS > > > installation. I have reviewed the STSADM commands > > > "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn > > > peoplepicker-searchadforests" to ensure they are correct (we only have one > > > forest, and WSS is on our intranet). I read in a couple of places online > > > that this behavior is by design, however, I've also read that WSS can read > > > the AD all the time, in real-time, so I'm confused. Anybody know the truth?- Hide quoted text -
> - Show quoted text -
You need to run a full profile import for the new groups to display.
-----Original Message----- From: Rick Scott <Rick Sc...@discussions.microsoft.com> Subject: PeoplePicker Missing New AD Groups Date: Tue, 27 Oct 2009 09:40:02 -0700
I've got an WSS 3.0 installation. In the people picker, I can see AD groups that existed when I installed it, and I can see all new AD users, however I cannot see any new AD groups that have been created since the WSS installation. I have reviewed the STSADM commands "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn peoplepicker-searchadforests" to ensure they are correct (we only have one forest, and WSS is on our intranet). I read in a couple of places online that this behavior is by design, however, I've also read that WSS can read the AD all the time, in real-time, so I'm confused. Anybody know the truth?
Thanks Yury and Brooks for the assists. Actually, I ended up contacting Tech Support, and discovered that I have inadvertently set my server farm to AD creation mode that last time I installed it. They walked me through the process on creating a new server farm without AD creation mode turned on, then attaching the new server farm to my existing content databases. Worked like a charm.
> -----Original Message----- > From: Rick Scott <Rick Sc...@discussions.microsoft.com> > Subject: PeoplePicker Missing New AD Groups > Date: Tue, 27 Oct 2009 09:40:02 -0700 > Newsgroups: microsoft.public.sharepoint.windowsservices
> I've got an WSS 3.0 installation. In the people picker, I can see AD groups > that existed when I installed it, and I can see all new AD users, however I > cannot see any new AD groups that have been created since the WSS > installation. I have reviewed the STSADM commands > "get/setsiteuseraccountdirectorypath" and "get/setproperty -pn > peoplepicker-searchadforests" to ensure they are correct (we only have one > forest, and WSS is on our intranet). I read in a couple of places online > that this behavior is by design, however, I've also read that WSS can read > the AD all the time, in real-time, so I'm confused. Anybody know the truth?