SharePoint Experts, Information Architects, Expert Witness

SICG provides a broad array of business and technology consulting from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. We focus on the "How", not just the possible. Contact me direct: or call 704-873-8846 x704.

Search This Blog

Friday, November 4, 2011

Users Prompted to Login on first access to SharePoint Site

Had an interesting problem at a client site (client actually found the fix) - the problem was users would be prompted for credentials when first accessing the SharePoint site; once logged in, there was no issue. Turns out this is a CLIENT machine problem with Internet Explorer; the fix below uses a registry change to fix it.

Note: make a backup of your registry file before making any change!

1.        Click Start, type regedit in the Start Search box, and then press ENTER.

2.        Locate and then click the following registry subkey:


3.        On the Edit menu, point to New, and then click Multi-String Value.

4.        Type AuthForwardServerList, and then press ENTER.

5.        On the Edit menu, click Modify.

6.        In the Value data box, type the URL of the server that hosts the Web share, and then click OK.

7.        Exit Registry Editor.

Friday, October 21, 2011

SharePoint Indexing Performance Tuning Tips

SharePoint Indexing Performance Tuning Tips

There are many factors involved in the SharePoint crawling process that can impact indexing performance. There are also some steps you can take to improve that. Here are the common causes and their resolution:
  • Indexing Performace is set at reduced - common mistake on the configuration screen for the index service. See Central Administration > Operations > Services on Server > Office SharePoint Server Search Service Settings and set to Maximum.
  • Number of Connections - by default the indexer will run a limited number of simultaneous threads (6 usually) per host. This can be increased manually by adding specific Crawler Impact Rules for each host. You can really improve speed by setting a large file server up to 64 connections. This number is just a suggestion btw to SharePoint, it also looks at other factors like the number of processors (8 * #procs). And also watch your network for bottlenecks and those pesky RPC errors you may get in your logs (dial it back of you see those)
  • Crawled systems are slow or hosted on remote networks. - not a lot to be done here, except by moving those files closer.
  • Overlapping Crawls - SharePoint gives priority to the first running crawl so that if you already are indexing one system it will hold up the indexing of a second and increase crawl times.
    • Solution: Schedule your crawl times so there is no overlap. Full crawls will take the longest so run those exclusively.
  • IFilter Issues - the Adobe PDF IFilter can only filter one file at a time and that will slow crawls down, and has a high reject rate for new PDFs
    • Solution: Use a retail PDF filter from or Foxit
  • Not enought Memory Allocated to Filter Process - an aspect of the crawling process is then the filtering deamons use up to much memory (mssdmn.exe) they get automatically terminated and restarted. There is of course a windup time when this happend and can slow down your crawling. The current default setting is pretty low (around 100M) so is easy to trip when filter large files. You can and should increase the memory allocation by adjusting the following registry keys
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager: set DedicatedFilterProcessMemoryQuota = 200000000 Decimal
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager: set FilterProcessMemoryQuota = 200000000 Decimal
  • Bad File Retries - there is a setting in the registry that controls the number of times a file is retried on error. This will severly slow down incremental crawls as the default is 100. This retry count can be adjust by this key:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager: set DeleteOnErrorInterval = 4 Decimal
  • General Architecture Issues - Ensure that you have at least 2 Gig of free memory available before your crawl even starts and that you have at least 2 real processors available.
  • Disk Health - the nature of the indexing process causes extensive fragmentation of the file system for both the index server and the database server. Schedule defrags routinely and after all full crawls. Ensure you have enough diskspace always.
  • Run 64 bit OS - school is still out on this one, i personally haven't seen much difference as long as there is enough memory and the same processor types, but MS recommends this for large deployments.
  • Proper SQL Server configuration (new) - For large (>5 Million) item indexing you will need to plan ahead for the correct SQL Server configuration in order to scale to these numbers. There is one table in particular that grows at 40x the number of items and can severely hinder peformance if you do not treat your SQL Environment like a very large data wharehouse. Here are my recommendations based on experience:
1.       Raid 10 Direct Attached Storage Only – minimum 4 arrays – 16 disks
2.       Multiple File Groups- pre-allocate all database files and partition on dedicated separate arrays and assign 1-1 for:
a.       Indexes for SharedServices1_search db
b.      Temp and system databases/tables
c.       transaction log for SharedServices1_search db
d.      Table content for SharedServices1_search 
                                       i.            For every 5 million items have additional file from dedicated drive in dedicated file group. Content and load is spread across and will improve performance
   3. When intially crawling, be sure to pause your crawls every day or so and rebuild/reorg the indexes on the SharedSevice1_search_db database (especially the indexes on MSSDocProps table)
NEW FROM MS:  Whitepaper on just this topic!!!!

NOTE: It is a good idea to open up perfmon and look at the gatherer stats while indexing. There is a statistic called Performance Level and this reflects the actual level that the indexer is running at where 5 is max and 3 is reduced. Even if you set everything to max the indexer may decide to run at reduced anyways based an some unknown factors.

This is a good read too: (Estimate performance and capacity requirements for search environments)
Addendum (7/28/2009)
Here is another good read from MS ( (Best practices for Search in Office SharePoint Server)

Thursday, October 6, 2011

Prevent Right Click on a SharePoint page...

Had a few clients ask for this - found a few answers but here is the fastest/most reliable methods:

Add a content editor part (or modify the Master Page) to inlcude:

     <body oncontextmenu= "return false;">
     Right Click not allowed on this page

Monday, September 26, 2011

The form cannot be rendered trying to publish a SharePoint Page

So you have you SP Site up and running - go to publish a new page and get this error:

“The form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator.”

If you do this from the Pages/Site Pages Library, you'll find that it does indeed check-in the page and start the approval workflow (simply refresh the page and you'll see the status goes to 'pending'). You can then override the Approval process.

ONE CAUSE for this is when the SharePoint State Service isn't running which just means it wasn't set up during the installation (or it was installed using the Configuration Wizard and setup wasn't finished).

You can correct this using the SharePoint Management PowerShell with some pre-requisites:
1) You have to be logged in as the SharePoint Farm account
2) The account you are using must have Shell Administrative Access
3) You have to have SP_Shell access set in the SQL Server Database(s)
4) The account you are using has DB Create permission and has a mapping to the Master database

Open the SharePoint 2010 Management Shell via Start > All Programs > SharePoint (be sure to run as an Administrator!).

Make sure the account you are using has Shell Admin access:

Shell> Add-SPShellAdmin -username domain\account

Once the shell is open, create a new Service Application by typing in:

Shell> $SPStateSvc = New-SPStateServiceApplication -Name “SP State Service”

NOTE If you get an error that says the name is not unique, the state service was already created (so this won't fix your publishing problem).

Next create a State Service database for the new Service Application by entering:

Shell> New-SPStateServiceDatabase -Name ”StateServiceDB” -ServiceApplication $SPStateSvc

Last, create an Application Proxy for the Service:

Shell> New-SPStateServiceApplicationProxy -Name ”SP State Service” -ServiceApplication $SPStateSvc -DefaultProxyGroup

Run an IISReset (as an Administrator) and try again!!

Wednesday, September 7, 2011

Getting Ripped off on SharePoint Expertise

I’ve seen it all – or at least I thought. Over the past two weeks alone, I’ve had two new clients come to us to ask us about SharePoint installations. As typical, we offered a quick review of the farm setup, sites, etc. and what we found was shocking.

In both cases, the firms that setup the installations a) used the “SharePoint Wizard” to deploy the farm (which does not work) and b) installed Enterprise deployed the primary site as a SharePoint Team Site (i.e. foundation site), thus cutting out more than half of the features. Unfortunately for both, our corrections have required a complete redeployment – lost time, lost money, lost effort. Sad but true. We often say, pay us now or pay us to fix it later but that’s for another day.
In both cases, the organizations didn’t have any in-house knowledge of SharePoint so were taking their respective ‘consultants’ at their word. Now as much as I’d like to take these ‘consultants’ out into the parking lot for a little chat….

Update: Now three - incredible?
So how do you avoid getting burned?
Alas, there is no magic method but there are a few key questions for any firm:
1)      How many actual installations of SharePoint
2)      What size of user base (does it match yours?)
3)      What kind of farms have they deployed (intranet, internet, extranet, etc.)
4)      How long have they been working with SharePoint (i.e. first client)

There are also three more checks you can do:
Check 1: Look for red flags in their background or CV/Resume of the ‘expert’; a few ‘red flags’ include:

1)      Listing ‘creating sites’ as a SharePoint skill
2)      Enabled/Disabled Features
3)      Created SharePoint Groups
4)      Created custom SharePoint Lists
5)      Created Site Content Types
6)      Managed backup and restore
All of the above are user interface activities – they are not ‘SharePoint Skills’ at the consultant level.
Check 2: Ask a few questions (whether you know the answer or not, you can gauge their knowledge level in how they respond) – these include:
1)      Can they explain their experience with the Enterprise Content Model of SharePoint?
2)      Can they explain master pages and page layouts and how they fit together?
3)      Can they explain the differences between Foundation, Server and Enterprise?
4)      Can they explain the differences between the site types?
5)      Can they explain when to use the Wizard and when not to?
6)      Can they explain what is gained by enabling Publishing in a Foundation site?
7)      Can they explain the difference between Classic and Claims Based Authentication?
Check 3: Explore their background in terms of what you need:
1)      Have they done end-to-end deployments or just portions?
2)      Have they deployed for a similar type firm or type of usage expected?
3)      Have they done any design work within SharePoint such as Branding?
4)      Have they trained anyone in the use of SharePoint and at what level – developer, administrator or end-user?
5)      Can they produce any samples (Screen shots or on-line if possible though on-line difficult for intranets)?
Hopefully the above will help you find the right consultant or firm to help if your organization is looking to deploy SharePoint.
One last suggestion, regardless of which consultant or firm you hire, you should find an independent/3rd party firm that has a known track record to provide you an audit – not to sell anything but simply to double check the work (1 hour or less).
Of course, SICG provides auditing services to address and help you avoid this kind of problem. As a non-invasive review installation/deployment, we make sure you got what you paid for before you sign off.

Wednesday, August 31, 2011

SharePoint Search Center missing controls

Soonor or later you will come across this issue - you have a custom styled master page, apply it to the site and all is well. You decide to use the Enterprise Search Center and viola - no search controls!

There are a number of articles on this but found one of particular use:

While his solution is great, I usually have to add a custom style to fix the left side of the page:

  #s4-leftpanel {
   display: none !important;
  #MSO_ContentTable {
   margin-left: 0 !important;
This prevents the page from displaying a little box on the left (where the QuickLaunch would be).

Wednesday, August 24, 2011

SharePoint Logout with UAG

Unified Access Gateway (UAG) and SharePoint Logout

If you are working with UAG and SharePoint, you might find that there are some oddities in the Log out process. Specifically, you might see some of the following symptoms:

·         Trying to Login as a Different user displays a ‘not found’ UAG page
·         Logout of SharePoint leaves user logged in to UAG
·         Logout of SharePoint leaves user logged in to SharePoint
·         Logout redirects to a bad page

Note: This has also been found to be an issue using ISA and Forefront.

There are a few ways to deal with the issue but bear in mind, that you must use the SharePoint logout process to ensure that users are indeed logged out. You can use a combination of the following solutions to customize a way to deal with it on your site.

The Menu:

The first issue you have to deal with is the menu; that is the menu where users can either logout or login as a different user. This is a control that can be located under c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\ControlTemplates\Welcome.ascx. You can edit this file directly (make a backup first) or you can create a feature to overlay this file in a SharePoint farm so that you do not have to worry about keeping the servers in sync (see below).

Within this control, you have a few options:

1)      You can simply delete the ‘login as a different user’ option – this section of code looks like this:

<SharePoint:MenuItemTemplate runat="server" id="ID_LoginAsDifferentUser"

2)      You can add your own menu option to send the user to a different page for that option and use the same method to replace the Logout:

<Sharepoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"       ClientOnClickNavigateUrl="/_layouts/CustomPages/CustomSignout.aspx"
       Description="My Custom Logout"
   UseShortId="true" />

3)      You can remove both options completely and a) replace it with your own custom link or b) integrate a logout button in your Master Page.

Creating a Welcome replacement feature:

The easiest way to deploy your custom welcome control is to create a simple feature that copies the file into a custom folder under CONTROLTEMPLATES as well as deploy a new master page that has the control path adjusted:

<%@ Register TagPrefix="wssuc" TagName="Welcome" src="~/_controltemplates/Welcome.ascx" %>


<%@ Register TagPrefix="wssuc" TagName="Welcome" src="~/_controltemplates/CustomFolder/Welcome.ascx" %>

Developing this as a feature is absolutely necessary if you intend to have multiple sites and do not what to have this change apply to all of them. This takes a bit more work that here; rather than duplicate, you can see the post on this here:

NOTE: DO NOT attempt to overwrite the original Welcome.ascx file using a feature (this is possible since the Control Templates folder can be selected) since it will erase the original file. The problem is that you cannot copy or backup the file via the feature and when the feature is removed, the ASCX file will be removed with it.

The Custom Logout Page:

To ensure the user is logged out properly, it is necessary to run the SharePoint controls that kill the cookie, etc. This is easily done by making a copy of the signout.aspx file located in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Layouts\.

In that same folder, you should create a new folder called CustomPages – this is where the custom logout page should be placed. In this way, you can always reference the file with the relative URL of /_layouts/CustomPages.

The Custom Logout page looks like this (Notice the JavaScript section – this determines the type of browser and attempts to clear the user’s authentication. At the end if redirects to a new page using window.location. The URL is whatever page the user should go to once logged out, typically a site that has anonymous access.):

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%> <%@ Page Language="C#" Inherits="Microsoft.SharePoint.ApplicationPages.SignOutPage" MasterPageFile="~/_layouts/simple.master"       %> <%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %> <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %> <%@ Assembly Name="Microsoft.Web.CommandUI, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<asp:Content ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
       <SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,signout_pagetitle%>" EncodeMethod='HtmlEncode'/>
<asp:Content ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
       <SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,signout_pagetitle%>" EncodeMethod='HtmlEncode'/>
<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">
<script type="text/javascript">
window.location = "";

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
       <asp:Label id="lbPageDescription" Text="<%$Resources:wss,signout_pagedescription%>" runat="server"/>
<!-- This is put in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\CustomPages -->

Creating the Custom Logout URL Feature:

Depending on your environment or governance, you may not be able to alter SharePoint’s default files so you can get around this using a feature.  

Step 1:

Create a new Empty SharePoint project in Visual Studio called ChangeURLSignoutFeature (you can call it whatever you like if you don’t like that name).

Step 2:

When prompted, select the site you wish to deploy to and leave the Sandbox Solution selected (do not deploy as a farm solution!) and click Finish.

Step 3:

When the project opens, right click on the Features folder and from the menu, select Add Feature. When the feature is created it will have the default name of “Feature1”, rename it to ChgSOURLFeature (again, you can use a different name if desired) then update the feature title and description.

Step 4:

Right click on the Feature and select Add Event Receiver. This will create an empty event handler (code commented out) using the same name as the feature itself.

Step 5:

Code the Event Handler with the following – this will be triggered on Activate and Deactivate of the feature:

using System;
using System.Runtime.InteropServices;
using System.Security.Permissions;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Security;
using Microsoft.SharePoint.Administration; 

namespace ChangeSignoutURLFeature.Features.ChgSOUrlFeature
    /// <summary>
    /// This class handles events raised during feature activation, deactivation, installation, uninstallation, and upgrade.
    /// </summary>
    /// <remarks>
    /// The GUID attached to this class may be used during packaging and should not be modified.
    /// </remarks>

    public class ChgSOUrlFeatureEventReceiver : SPFeatureReceiver
        // Set page on Activate:
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
            SPSite featureSite = (SPSite)properties.Feature.Parent;
            SPWebApplication webApp = featureSite.WebApplication;
            if (webApp != null)
                if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout, "/_layouts/CustomPages/CustomSignout.aspx"))
                    throw new SPException("Unable to update the custom signout page");
        // Reset to default on Deactivate:
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
            SPSite featureSite = (SPSite)properties.Feature.Parent;
            SPWebApplication webApp = featureSite.WebApplication;
            if (webApp != null)
                if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout, null))
                    throw new SPException("Could not restore default signout page");

Compile the project and assuming all is well with the compile, try deploying it to your site. If you do this from Visual Studio, it will automatically activate. If you use the WSP to install (as you would in a production site) using the STSADM –o AddSolution command, you must navigate to the site, select Site Actions > Site Settings then click Site Features. When the list of features opens, you can activate the feature.

You can then try the logout to verify it is running your custom page.

That’s all there is to it!!!

Friday, July 22, 2011

Visual Studio 2010 Project Error AssemblyInfo.cs could not be opened

Discovered this from a client site source code review...

So you open a project in Visual Studio 2010 and get an odd error:
Source file '<Project Location>\Properties\AssemblyInfo.cs' could not be opened ('Unspecified error ')
What this means is that the AssemblyInfo.cs file is either missing from the Properties folder in the project or there is a permissions issue. If permissions, update the ACL (File > Properties > Security), close and re-open the project. If missing altogether, you just need to recreate it using the following steps:
  1. Within Visual Studio 2010, select Tools > Create GUID
  2. Click Copy (or New GUID then Copy)
  3. Click Exit
  4. Expand the Properties folder in the Solution Explorer (Control + W, S to open)
  5. Delete the AssemblyInfo.cs file shown with the exclaimation point
  6. Double click on the Properties folder - this should open the Properties window
  7. On the Application Tab, click the Application Information... button
  8. Fill in the application information, paste the GUID you copied into the GUID field - when done click OK
Viola - problem solved...

One FYI - if the project requires a specific GUID, you can set it - if not known, you have no choice but to create one.

Friday, July 15, 2011

Annoyances in PowerShell

So you are trying to run a PowerShell and keep getting:

Suggestion [3,General]: The command <script file> was not found, but does exist in the current location. Windows PowerShell doesn't load commands from the current location by default. If you trust this command, instead type ".\<script>.ps1". See "get-help about_Command_Precedence" for more details.

This generic error is pretty much what you will see for anything, even if the file does not exist. One of my clients was trying to run Invoke-AlertFixup in SharePoint and kept getting this error even when correctly opening it as:


The fix is quite simple - simply enter:

$env:PATH = $env:PATH + "."

then enter the .\<script>.ps1 - Viola!

Wednesday, July 13, 2011

Borders on images in the Summary Links Part SharePoint 2010

A first, a client recently reported having difficulties with a Border showing up around images when using the SharePoint 2010 Summary Links part. Thinking it was something quick, we tried adding a style update to the master, the page layout and even tried the content editor part with no luck. I did some digging around and finally found the 'correct' answer from a post by Amit Kumar. The real reason for this problem is that the XSL for this part is rendered separately as a server side control; by the time the page is rendered and styles kick in it is too late. It does appear that it has to do with IE8/IE9 settings somehwere - not all users experience the problem.

The fix is quite simple - open the Site in SharePoint Designer, open the Style Library then the XSL Style Sheets folder and edit the SummaryLinkMain.xsl style sheet. Search for 'presense-status-icon' and you'll find the style as follows: 

<span class="presence-status-icon">
<img src="/_layouts/images/imnhdr.gif" onload="{concat($prefix, @SipAddress, $suffix)}" ShowOfflinePawn="1" id="{concat('MWP_pawn_',$slw_clientid,'_',$id,',type=sip')}"/>

Now modify the <img tag and add 'border="0"' as follows: 

<span class="presence-status-icon">
<img src="/_layouts/images/imnhdr.gif" border="0" onload="{concat($prefix, @SipAddress, $suffix)}" ShowOfflinePawn="1" id="{concat('MWP_pawn_',$slw_clientid,'_',$id,',type=sip')}"/>

Save and check in (very important) the file and you should be good to go. Note that you 'might' have to run an IIS reset and/or dump IE cache.

Tuesday, July 12, 2011

Fastest way to create a custom ListDefinition 2010

As we all know, it can be a real pain to code out a custom list definition in SharePoint. Sure, not complicated but sheesh - enough with the typing!

Anyway, quick tip on getting the proper Schema information when you want to create a list. Create the majority of the list in SharePoint (views, etc. too). When done, you can use the following:

http://<Site URL>/_vti_bin/owssvr.dll?Cmd=ExportList&List=<ListGUID>

Note that if you navigate to a list and go to list settings, the "List=GUID" is there for you to copy.

The benefit of this method is that the Schema for the list is 'complete' and has all views, references to existing site columns, etc.

Friday, July 8, 2011

SharePoint 2010 ListDefintion Edit Fails with "Object reference not set"

So you create a new custom List Defintion in SharePoint 2010 - deploy it to the site and it creates fine. You even add an item and works but then you go to edit it and you get either the dummy error page or you get "Object reference not set".

Turns out the problem is quite easy to fix - it simply means that one of the fields you created in the list has a duplicate GUID (or you used one that is already in use by another field) OR you didn't add the the a field in the <FieldDefs> section.

Check the FieldDefs first and if they look OK, it is probably a GUID - simply go back through your Schema.xml file and check each one of the GUID's - be sure all of them are unique and that you DON'T change the GUID of the Title, LinkTitle or LinkTitleNoMenu fields if you are modifying them (i.e. like changing the display name). In one case I had to change each field until I found the offending one. Don't forget to use the MakeGuid utility (either through Visual Studio : Tools > Create GUID) or you can always download it.

FYI - Many of us end up changing the Title field - for this field, the following GUID's apply:
  • Title | fa564e0f-0c70-4ab9-b863-0177e6ddd247
  • LinkTitle | bc91a437-52e7-49e1-8c4e-4698904b2b6d
  • LinkTitleNoMenu | 82642ec8-ef9b-478f-acf9-31f7d45fbc31
If you want to change the Title field (the display name for example), you have to specify the field just like those you are creating but being sure to use the Name/StaticName and GUID's from above.

Thursday, June 30, 2011

SharePoint 2010 The List Cannot be displayed in Datasheet view for one or more of the following reasons

So you setup a brand new SharePoint 2010 site and found that like MOSS, it can be a pain to get the Datasheet View working - to wit:

"The List Cannot be displayed in Datasheet view for one or more of the following reasons"

You may also have problems with the GridView - this solution fixes both problems. The problem is that the Office components needed are not installed, SharePoint 2010 needs BOTH the 2010 and 2007 components to work properly.

The guaranteed fix is to do the following (do this in order - x64 MUST be installed before x86, i.e. 2010 before 2007.

1) Install Office x64 (does not have to be licensed)

2) Download and install:
Microsoft Access Database Engine 2010 Redistributable

3) Download and install:
2007 Office System Driver: Data Connectivity Components

After these, run and IIS reset and off you go!

SIDE NOTE: If you want to run a copy of SharePoint Designer on the server (i.e. a staging or test environment), you must install SharePoint Designer x64 BEFORE the 2007 Office System Driver.

Wednesday, June 29, 2011

SharePoint 2010 Forms Based Authentication Tips

I was recently at a client that had enabled FBA for SharePoint 2010 and were having issues getting the User's information due to the format and problems with connecting SharePoint user to Membership Provider user. After a bit of checking, turns out they had a) not understood the format of the user name being returned and b) didn't know about naming in FBA.

First off is the format of the name - when pulled from either the Membership Provider or SharePoint, the format is something like: i:0#.f|MyFBA|MyLogin - for the translation:

i0#.f = A placeholder (seems to be always 0)
MyFBA = the name of the provider
MyLogin = the actual login name of the user

Second was the naming of the provider itself - as it turns out, they had used two different names when they created the Membership Provider and the name they gave it in SharePoint and SharePoint's web.config.

When accessing SharePoint (the SPUser object), the name SharePoint will return is in the provider format of : i0#.f|membership provider name from the web.config|user login - the provider name in this case is the name supplied when the site is created.

However my client had used a different name when creating the provider using the ASP tool - thus when returning the User from the Membership provider, the format is the same but the name is different: i0#.f|membership provider name ASP configuration|user login. This of course, makes comparison a bit difficult as you may imagine.

The problem is that once this is setup, the only way to change it is via Central Administration > Web Applications > Manage Web Applications. Click to select the site to select it then click Authentication Providers in the ribbon. From the pop-up, select the Default link, and then from there you can change the names. HOWEVER BE FOREWARNED - if you do this, it will mess up the users in SharePoint internally (those already created have the original provider name); this means you have to delete ALL USERS from SharePoint and add them back - not for the faint of heart.

The following routines should help you.

To get the SharePoint User:

        public SPUser ReturnCurrentSPUser()
            SPWeb site = SPContext.Current.Web;
            SPUser currUser = null;
                using (SPSite ElevatedsiteColl = new SPSite(site.Site.ID))
                    using (SPWeb ElevatedSite = ElevatedsiteColl.OpenWeb(site.ID))
                        currUser = site.CurrentUser; //not the ElevatedSite.CurrentUser      
            return currUser;

To get the "real" login name from the Membership Provider:

        public string ReturnCurrentUserLogin()
            string LoginName = "";
            SPClaimProviderManager ClaimManager = SPClaimProviderManager.Local;
            if (ClaimManager != null)
                    LoginName = ClaimManager.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName).Value;
                catch (Exception NotMembershipUser)
                    string WhyErr = NotMembershipUser.Message.ToString();
                    LoginName = "";
            return LoginName;

To get the "Formated" User Name:

        public string ReturnCurrentUserClaimLogin(string UserLoginName, string ProviderName)
            string userName = null;
            SPClaimProviderManager ClaimManager = SPClaimProviderManager.Local;
            if (ClaimManager != null)
                    SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, UserLoginName, "", SPOriginalIssuers.Format(SPOriginalIssuerType.Forms, ProviderName));
                    userName = ClaimManager.EncodeClaim(claim);
                catch (Exception NotMembershipUser)
                    string WhyErr = NotMembershipUser.Message.ToString();
                    userName = "";
            return userName;