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?

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?

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

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.

The solution? I whipped up a Windows application so download one, several, or all of the solution packages currently stored in the farm configuration database.

I have posted the application to CodePlex @ http://spsolutiondownloader.codeplex.com/.

The application must be run in the context of a Farm Administrator (i.e. right-click, Run As…) on a server in the farm for which you wish to download the solution package(s) from and requires the .NET Framework 3.5.

I would love some feedback from the community as to whether or not this useful. I have some other little apps in mind I could put together with the proper motivation.

Today when I attempted to completely retract my form (inlcuding manually deleting the content type associated with the form), I was presented with the always helpful error “The content type is in use“.  This is by far one of the more helpful errors you will ever see from SharePoint.  Unfortunately it isn’t clear how to discover where the content type is actually in use.  A quick trip to the content database for the site collection you are working in can show us:

DECLARE @ContentTypeName nvarchar(128)

SET @ContentTypeName='Content Type Name Here'

SELECT w.Title AS [Web Site], w.FullUrl AS [Web Url], al.tp_Title AS [List Title],
	ct2.*
FROM ContentTypes ct1
	JOIN ContentTypes ct2 ON LEFT(ct2.ContentTypeId, Len(ct1.ContentTypeId))=ct1.ContentTypeId
	LEFT OUTER JOIN dbo.ContentTypeUsage ctu ON LEFT(ctu.ContentTypeId, Len(ct2.ContentTypeId)) = ct2.ContentTypeId
	LEFT OUTER JOIN dbo.AllLists al ON ctu.ListId = al.tp_Id AND ctu.WebId=al.tp_WebId
	LEFT OUTER JOIN dbo.Webs w ON al.tp_WebId = w.Id WHERE ct1.ResourceDir=@ContentTypeName

[Credit to Curtis Ruppe]

Once we know where the content type is in use, deleting it through the GUI is a trivial matter.

The moral of the story? When publishing a custom initiation form, be sure to leave the “Alternate” publishing location empty.

What are you waiting for?  Go check it out!

[Via To The SharePoint]