>At one of my clients they currently have three domains. A domain for development, staging and live. The domains are linked via trusts which is kinda great but this presents a problem with the SharePoint People Picker.

This is more apparent when using SharePoint on the staging domain as the live users are copied over to the staging domain so that the domains are like for like.

Therefore it is hard to pick the right user when assigning permissions or setting up workflows. When a username is entered in a user control and you click the tick button to try and resolve the user, a drop-down list displays the possible options. Until you select one there is no way to work out which domain the user is in. To get around this you use the slower picker and have to click on the search button against a user field, type in the name and then using the full DOMAIN\login name column pick the appropriate user, this is a pain in the arse!

I have been thinking about this for a while and reading this great post from Joel , none of the common people picker properties allow you to only restrict to a domain. Looking through this post I picked out the stsadm -o setproperty -pn peoplepicker-searchadcustomquery option.

After a bit of investigation using ADSIEdit I had found a user/group property, canonicalName that could be used to restrict the search to a particular domain.

This property has the following format
canonicalName UnicodeString = Domain/Container/Container…….

So here it is:-
To restrict the people picker to a particular domain do the following:-

stsadm -o setproperty -pn peoplepicker-searchadcustomquery -pv “(canonicalName=[YOURDOMAIN]*)” -url http://[yoursharepointsitecollection]

e.g stsadm -o setproperty -pn peoplepicker-searchadcustomquery -pv “(canonicalName=DEV*)” -url http://vmsd-sharepoint

If you want to switch this off then run the same command but change the -pv parameter to “”
e.g stsadm -o setproperty -pn peoplepicker-searchadcustomquery -pv “” -url http://vmsd-sharepoint

That’s it!

The people picker will still resolve SharePoint groups and works in the same way through SharePoint in the workflow assignment and InfoPath forms.

Enjoy
Simon

>Over the weekend our development servers were setup to be monitored by Systems Operation Manager. A few errors occured including one of them stating that “Performance Monitor could not find a performance counter, SharePoint Publishing Cache, Publishing cache flushes /seconds.”

To check the performance counter:-

• Logging on to the SharePoint machine
• Opened the Performance Monitor (Start->Control Panel->Administrative Tools->Performance)
• Selected System Monitor
• Click [+] and choose SharePoint Publishing Cache from the performance object list
• Select Publishing cache flushes /second

You will see that there are no instances available, which makes sense as System Centre cannot find the counter. I gave this some thought and of course if publishing cache has not been enabled then there will be no counters.

So we have two choices :-

1. Disable System Centre alert via Override (see http://blogs.technet.com/momteam/archive/2008/03/01/performance-module-could-not-find-a-performance-counter.aspx)
2. Enable Performance caching

I decided to enable performance caching, so browse to your SharePoint site collection:-

• Click on Site Actions->Modify Site Settings->All Site Settings
• Under the Site Collection Administration list click Site Collection Output cache
• Enable Output cache
• I set the following Anonymous – Public Internet (this wont be used)
• Authenticated Cache Profile – Intranet
• Click OK

After about 5 minutes I switched back to the Performance tool and closed down the add counter. Then tried to add a counter this time the SharePoint Publishing Cache had various counters.

Cheers

Simon