mylifeinaminute.com

MOSS 2007 SP2 has a bug fix that it seems a number of people don’t want. It enables redirection from the userdisp.aspx page in a local site collection to the MySite portal page even when a portal site connection is not configured.

Thankfully, a quick feature scoped at the farm level can remedy the situation. The following feature disables profile redirection and also hides the “My Site” global navigation link. Note that this feature is scoped at the Farm level, making it applicable to all web applications/site collections within the farm.

The feature

feature.xml

<?xml version="1.0" encoding="utf-8"?>
<Feature  Id="6768ca75-6afb-4b70-80e6-7964abf4fb68"
          Title="Disable MySites Redirection"
          Description="Disables MySites redirection to person.aspx (pre-SP2 behavior) and removes the My Site global navigation link"
          Version="12.0.0.0"
          Hidden="FALSE"
          Scope="Farm"
          DefaultResourceFile="core"
          xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="elements.xml"/>
  </ElementManifests>
</Feature>

elements.xml

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Control Id="GlobalSiteLink1" Sequence="50" ControlSrc="" />
    <Control Id="ProfileRedirection" Sequence="50" ControlSrc=""/>
</Elements>

Reference

• How to bypass MySite redirection introduced with the SP2 when you display user details?

Ah yes, the people picker again. I recently inherited an environment where the previous administrator was kind enough to not document anything, especially the items he/she had been playing with in development.

When trying to designate a user as a Primary Site Collection Administrator in Central Administration, I was unable to query for subsets of domain users on a single web application. After checking all of the usual suspects (Peoplepicker-searchadforests I’m looking at you) with no success, it was off to the not-so-usual suspects.

It turns out the previous admin was kind enough to set the Peoplepicker-searchadcustomfilter property on the main portal site collection. After setting the property to null

stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "" -url [URL]

all was once again right with the world.

Now where did I leave my sledgehammer?

Restoring site collections with stsadm is normally a straightforward affair, requiring little to no manual intervention to get things back up and running. That is of course, unless you are restoring sites based on the Publishing Site template.

I recently wanted to take an existing site collection, make a copy of it in the same web application under a newly created managed path and have it reside in a new content database. The backup went smooth, utilizing stsadm -o backup. The creation of the new managed path went off without a hitch. The creation of a new content database and the restoration of the site collection into that database also occurred with no issues.

Browsing the site however told a different story. I was immediately greeted with a standard error page stating “File Not Found”. Browsing to other pages within the site (eg. “/_layouts/settings.aspx“) yielded the same result. After turning on the callstack/debugging and disabling the custom error page, I was greeted with the following:

The problem? Each publishing page points to an incorrect page layout after the restoration. One would think that the restore via stsadm would recognize this and fix it, but it does not.

The fix? The stsadm extensions published by Gary Lapointe. The package built by Gary offers a command call gl-fixpublishingpagespagelayouturl. Verbose? Yes. Does it work? Absolutely.

After running the command and executing an iisreset, the site was once again able to be browsed and appears to be intact.

Reference

• SharePoint Automation: Fix Publising Pages Page Layout URL
• File not found errors when restoring a site collection
• stsadm backup Operation
• stsadm restore Operation

When upgrading from a standard SKU to an Enterprise SKU in SharePoint (MOSS 2007), things can (and do) go wrong. Come to think of it, I’ve never seen one complete successfully without some type of manual intervention. Fortunately, the majority of errors that are experienced are recoverable. Take for instance:

An existing request to enable the Enterprise feature is in progress. To check the status of this request, go to the Timer Job Status page in Central Administration Operations and check the status of the Office Server Enterprise Features Upgrade Job.

When you find the job in the Timer Job Status page, you will see that it needs to run on all servers in your farm. Chances are it has failed on one (or more) servers. The quick fix? Restart (or start if stopped) the Windows SharePoint Services Timer service on the server where the upgrade job failed. After the job has completed, return to Central Administration to verify that your farm has been upgraded.