FAST Search Links Missing from FAST Search Center

Posted on 02. May, 2012 by .


If you create a FAST Search Center based on the FAST Search Center Site Collection template, you may find that the FAST Search links are missing within the “Site Collection Settings” in Site Settings. If this is the case, you need to fire up PowerShell and add the SearchExtensions feature to the site collection using the following code (from Neil Richards at

PS C:UsersAdministrator> Get-SPFeature | ? { $ -eq "5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5"}

DisplayName                    Id                                       Scope
-----------                    --                                       -----
SearchExtensions               5eac763d-fbf5-4d6f-a76b-eded7dd7b0a5     Site

PS C:UsersAdministrator> $siteWithNoFastFeatures = get-SPSite http://your SP SITE NAME FOR FAST COLLECTION (ADD UR OWN url)
PS C:UsersAdministrator> $siteWithNoFastFeatures.Features.Add("5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5")

DefinitionId           : 5eac763d-fbf5-4d6f-a76b-eded7dd7b0a5
Parent                 : SPSite Url=http:// SP FAST NAME (ur OWN url)
Properties             : {}
Definition             : SPFeatureDefinition Name=FeatureDefinition/5eac763d-fbf5-4d6f-a76b-eded7dd7b0a5
Version                :
FeatureDefinitionScope : Farm

Continue Reading

Locating MySQL Root Password for Plesk 10 Client Server

Posted on 10. Nov, 2011 by .


If you need to access the client MySQL instance on your Plesk 10.x box, you will need to connect to the admin instance first. To do that, do the following:

"%plesk_dir%mysqlbinmysql" -P8306 -uadmin -pyour_password psa

The password for connecting to the plesk admin instance is the same as your plesk admin password. If you need a refresher, run the following:

"%plesk_cli%admin" --show-password

Okay, so once you’ve connected to the admin instance, you will want to execute the following:

select * from databaseservers;

The results will give you not only the admin username and password for the client MySQL instance, but also MSSQL if you have it installed.

Good luck!

Continue Reading

AllowUnsafeUpdates Error Updating User Profile Information

Posted on 10. Nov, 2011 by .


My customer has a requirement to track the last login date/time for each SharePoint user so that they can disable accounts that have not had any activity for a time period. I decided to implement this requirement by creating an HttpHandler and tying a jQuery .post call into the custom masterpage. The HttpHandler would then update a property, LastLogin, that has been added to the user profile service application.

The issue I ran into is that SharePoint would constantly complain about not allowing updates via a GET, and that I needed to set the AllowUnsafeUpdates property on the SPWeb object. Sounds simple and straight forward enough, and oddly this was an instance where not only did SharePoint give you a decent error, it even went so far as to propose a solution! Double word score! Unfortunately it took forever to figure out WHICH SPWeb object it was talking about! Check out the following code:

private void UpdateUserLastLogin(HttpContext context)
            string siteURL = SPContext.Current.Site.Url;

                using (SPSite site = new SPSite(SPContext.Current.Site.ID))
                using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))

                    // this is the important bit
                    SPContext.Current.Site.AllowUnsafeUpdates = true;
                    SPContext.Current.Web.AllowUnsafeUpdates = true;

                    SPServiceContext serviceContext = SPServiceContext.GetContext(site);
                    UserProfileManager profileManager = new UserProfileManager(serviceContext);

                    UserProfile profile;

                    if (!profileManager.UserExists(SPContext.Current.Web.CurrentUser.LoginName))
                        profile = profileManager.CreateUserProfile(SPContext.Current.Web.CurrentUser.LoginName);
                        profile = profileManager.GetUserProfile(SPContext.Current.Web.CurrentUser.LoginName);

                    profile["LastLogin"].Value = DateTime.Now;


                    SPContext.Current.Web.AllowUnsafeUpdates = false;
                    SPContext.Current.Site.AllowUnsafeUpdates = false;

So if you look at the part commented “This is the important bit” you will see AllowUnsafeUpdates getting set. This is what I finally came to which actually worked. Previously I tried the following:

site.AllowUnsafeUpdates = true;
web.AllowUnsafeUpdates = true;

And that did not work at all. So I’m still not completely clear why setting it on the SPContext.Current.Web works, considering that I am spinning up new instances of SPSite and SPWeb and sending them to UserProfileManager, but whatever. I’ll take it.

If anyone can explain why this works that would be awesome, in the meantime I’ll keep this handy incase I run across this dreaded error in the future.

Continue Reading

XSL for Displaying Raw XML in XsltListViewWebPart

Posted on 31. Oct, 2011 by .


I am writing this post so that I can hopefully save myself time in the future from trying to track down this little snippet that will take the incoming XML to an XsltListViewWebPart and render it out. This is the snippet:

<?xml version="1.0" encoding="UTF-8"?>
 <xsl:stylesheet version="1.0" xmlns:xsl="">
 <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
 <xsl:template match="/">
 <xmp><xsl:copy-of select="*"/></xmp>

This snippet comes from a community content comment on MSDN:

Continue Reading

Use A Records for SharePoint Sites When Using Kerberos

Posted on 12. Jul, 2011 by .


When given the choice between using an A DNS record or a CNAME DNS record for your SharePoint web applications, favor an A record particularly if you are using Kerberos authentication.  Reference the following TechNet article:

Of particular interest in this article is the following passage:

Kerberos authentication and DNS CNAMEs

There is a known issue with some Kerberos clients (Internet Explorer 7 and 8 included) that attempt to authenticate with Kerberos enabled services that are configured to resolve using DNS CNAMEs instead of A Records. The root of the problem is the client does not correctly form the SPN in the TGS request by creating it using the host name (A Record) instead of the alias name (CNAME).


A Record:

CNAME: (aliases

If the client attempts to authenticate with, the client does not correctly form the SPN and requests a Kerberos ticket for http/ instead of http/

Details regarding the issue can be found in the following articles:

To work around this issue, configure Kerberos enabled services using DNS A records instead of CNAME aliases. The hotfix mentioned in KB article will correct this issue for Internet Explorer but will not correct the issue for the .NET framework (which is used by Microsoft Office SharePoint Server for web service communication).

What me and my team experienced is that a customer had a customization which interfaced with Exchange.  The browser authentication to the web application appeared to be working fine, but the double-hop to Exchange was failing with a 401 error.  All SPNs appeared to be correct.  We changed the DNS records from CNAME records to A records and the authentication began to work as expected.

Continue Reading