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

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;

Tuesday, June 7, 2011

Problems with FIM and User Profile Synchronization SharePoint 2010

Like many of you, I've come across many of those little gotcha's in security and setup of SharePoint 2010 - one of which has been issues with teh FIM services and the User Profile Synchronization (including sometimes when the connection seemingly disappears). I did find an excellent post so reposting the answer (with due credit) here:

1. For the Event ID 1004:
The reason that we are seeing this message is that the WMI calls are made under the credentials of Network Service account and it doesn̢۪t have permissions to the folder in which Microsoft.ResourceManagement.Service.exe is located and thus the resource not found error is logged.

The error should go away if the Network Service account is given permissions to the folder (as indicated in the error)where the resource is located. (C:\Program Files\Microsoft Office Servers\14.0\Service)

2. For the Event ID 5555:
a. Go to the user profile service app, click on the Administrators button in the ribbon and give Profile sync account Full Control rights
b. Then click on the permissions Tab and click and give that account full control there as well.
c. Do an IISReset and monitor to see if the errors go away.

Fred Ellis - MSFT

Monday, June 6, 2011

Adding Report Services Integration to SharePoint 2010 Account Error

When adding the Reporting Service Integration via Central administration, you might have trouble with it accepting the account and password, though you know it is correctly set. Unlike most apps, apparently the Domain Name used for the account is Case Sensitive!
In most cases, you need to a) verify that the path is correct via Report Services Configuration and b) enter in a domain name exactly as it is set in SQL - usually Uppercase so like: DOMAIN\account.

Thursday, June 2, 2011

SharePoint displays users as Domain\Username instead of Display Name

Recently had a client discover that SharePoint 2010 was displaying users as domain\username instead of the Display Name as it is in Active Directory; oddly it wasn't all accounts either. After some deep searching, I found the following fix. Using the SharePoint Command Shell do the following:

1) If the problem only appears with a single user, you can update a single account like so:

Set-SPUser -Identity ‘domain\Username’ –Web http://<URL To Site> –SyncFromAD

2) If all (or a lot) of the uesrs you can do it by the following:

Get-SPUser –Web http://<URL to Site> | Set-SPUser –SyncFromAD

The above will reset all users FOR THAT SPECIFIC URL; if you have additional site collections (i.e. Managed Paths), you have to run it on those URL's as well.

NOTE: You will often get an error for 'invalid' accounts such as Local Service - you can generally ignore the message as long as users show up correctly.