SharePoint

IE11 Broke SharePoint 2010

I’ve been noticing recently my SharePoint site was behaving oddly, especially when I wanted to edit a web part. Yesterday the odd behavior hit a critical point as I was unable to connect web parts on a page. The problem was every time I clicked the drop down arrow on the web part heading the page would refresh and some of the menu content would appear in a side panel, where the web part properties are usually displayed.

Knowing we had a customized master page I was convinced some change must have caused the problem. However, after reverting the master page to the site default the problem persisted. A coworker jokingly suggested I try using Chrome or Firefox. In frustration I opened the site in Firefox and amazingly everything worked.

I went back to IE 11 and opened the emulator setting. Although the browser mode was IE8 I noticed the User Agent setting was Default. I decided to change this to the IE8 User Agent setting and after the page refreshed, the site worked as expected.

After doing a little web search I found the IE team’s blog about changes to the User Agent string, which recommends you not use the User Agent Browser Sniffing technique (maybe something to tell the SharePoint Team?).

Overall, the site’s end user experience look unchanged, but it does effect the developer’s and site owner’s experience.

Site Collection Content Type vs. Content Type Hub

I’ve been working on a project recently that has a large number of sub-agencies and the parent organization was attempting to push a standardization of Content Types.  Since no one really wanted to duplicate work the organization decided they did not want to migrate content into SharePoint (from file shares) until all the content types and metadata had been identified and created.  However, as with all large agencies some groups wanted to move forward with limited or partial capabilities because after all some limited capability is better than what they currently have.  The concern that arose from this was: What if they created a Content Type in one of their Site Collections that had the same name as one that would be published later on?

The process I followed was very simple:

  1. Create a new Site Collection
  2. Create a Content Type ‘RFP’
  3. Create a Content Type in the Metadata Hub name ‘RFP’
  4. Publish and see what happens

Once the import of the Content Types was completed I checked my Content Type Import Log in the Site Collection (created in #1 above).  What I found was an error stating: Content Type Name ‘RFP’ conflict.  In addition I checked my Site Content Type and found that the one custom field I had added in the Metadata Hub was NOT included as a field of my local ‘RFP’ Content Type.

SharePoint Published Content Types

I have done a lot of development with SharePoint workflows, especially those developed in Visual Studio.  Unless I have been working with a standard list type, I generally create a Content Type that my workflow can be associated with and to ensure the columns and values needed in the workflow will be present.  However, creating Content Types is always a painful process, because as you develop the content types and test them you need to delete the original content type, and any list depended up in before you deploy the updated version.  This is even worse when you upgrade a solution that is in use in production because you can’t easily delete the content type just to add additional fields.

Recently, I have been working with Publishing Content Types, usually designed through the SharePoint UI, and what I began to notice was that when the published Content Type was updated in the Content Type Hub those changes were reflected in the sites making use of those Content Types.

This made me wonder if the same would happen if I deployed the Content Type through a Visual Studio solution, published it and then updated the Content Type.  I initially created a Content Type that had a Title and a Choice column.  Once deployed I published the content type and created a list in my Published Content Type Consumer site.  I then added an additional text column to the Content Type and redeployed.  After the Content Type Hub timer jobs executed the List I created using the Published Content Type now had the new column.

Lesson from this: If you have to deploy and maintain Custom Content Types use a Content Type Publishing Hub to manage the Content Types, and any future updates you may need to make.

SharePoint 2010 and jQuery 2.x

Recently, I was working with a coworker who had created a javascript dashboard using jQuery and KnockoutJS in SharePoint.  The dashboard had worked perfectly for him, but when I viewed the site none of the data would render.  While we were testing the site we noticed that my browser was running in Browser Mode IE10 with Document Standard IE 7 Standard, but his was running Browser Mode IE 10 with Document Mode: Standards.  Having battled with SharePoint 2010 using an HTML5 Masterpage I began looking for the Meta tag on the page which should define the appropriate browser mode and noticed he had removed it.  I had him add the tag back to the masterpage (from my experience removing the browser mode tag in SP2010 causes all kinds of issues when editing pages, list items, etc) but still found the dashboard was not functioning properly.

When we looked at the jQuery include I noticed he was using the latest version from the Microsoft CDN, which happens to be version 2.x.  Because I had another site running with jQuery and Knockout I had him revert his version of jQuery to 1.10.x and we found this was working.

The cause of the issue is detailed in the jQuery documentation for 2.x:
jQuery 2.x has the same API as jQuery 1.x, but does not support Internet Explorer 6, 7, or 8. (source)
The reason this is relevant is because SharePoint masterpages include:
<meta http-equiv=”X-UA-Compatible”content=”IE=8″/>
Which forces IE browsers to effectively run in an IE 8 mode.

Therefore, if you are a SharePoint 2010 developer and are attempting to use jQuery, make sure you are using 1.x versions

User Profile Personalized Links

Recently my company performed a migration for our old production environment to a new production environment so we had a more stable and robust platform to support the company, including providing leadership with better business intelligence about our operations. As part of the migration one of my goals was to launch My Sites for our internal users so they had somewhere to store information they were working on.

As I was thinking about what would be useful to our employees I ran across the Personalized Links capability available in the User Profile Service Application. In general this capability allows us to “push” links onto a user’s My Site. Since our company uses Great Plains for timecards and financial management integrated into SharePoint I thought it would be worthwhile to place the link to an employee’s Timecard Entry page along with a link to our primary portal. I then decided a link for Timesheet Reviewers made sense, but I didn’t want it to show up on all of the employee’s pages, just the employees who actually review timesheets. We have already scoped this link on our portal by using the Business Portal security groups, but since we are working in the context of the My Site we don’t have those security groups to rely on.

User Profile Personalized Links like most other things in SharePoint include the ability to apply audiences, so controlling who sees the links are possible, but I needed to create the right audience. I jumped over to the Profile Audiences and told my profile service to compile the audience. While the audience was compiling I applied it to my Personalized Link for Timesheet Review. I then checked to see that the audience had compiled and took a look at my My Site…no Timesheet Review link.

I took another look at my audience and realized it had 0 members, so I decided to delete it. After deleting the audience I then decided I would remove the Timesheet Review Link for the time being ad that is where the trouble began.

When I pulled up the Personalized Links page the only item showing where my links should have been was a message “The query returned and error. Contract your SharePoint Administrator” *Crap! I am the SharePoint Administrator! *

Ok, I figured I could fix this easily, I’ll just recreate the Audience with the same name…Nope, same error message.

Ok, the add new link button is available, I’ll add a new Link and the bad one will get “fixed” magically…Nope, no magic here.

Ok, so I checked my SharePoint Logs, my server application logs, and everywhere else in hopes I would see what the exact error was, alas nothing…

Fine, SharePoint is nothing more than a database application when we boil it down to the root I decided to crack it open and see what was going on. I opened the My Site Content Database and began looking at the various tables and opening the ones I thought had the highest probability of containing the list of links I had created.

After about an hour of searching I finally opened the table SharedListSync, and there I found my entry for the Timesheet Review along with the audience GUID. I decided the best method at this point was to change the audience GUID to 0, like the other entries that I had not applied Audiences to.

When I returned to the Personalized Links page sure enough all the links I had entered were now available and I was able to finally remove the Timesheet Review link.

SharePoint 2010 and Windows Azure App Fabric Access Control (ACS)

Last month I was working on a demo for a charitable organization that has lots of volunteers around the country. The charity didn’t want to have to create new active directory accounts for each of these volunteers so as part of the demo we integrated SharePoint 2010 site with Windows Azure App Fabric Access Control (ACS), this way we could use Google, Windows Live, and Yahoo! as authentication providers. (Yes I know we could hook directly to each of these providers, but using ACS allowed me to use all the providers with one SharePoint Trusted Provider instead of using three different trust providers). We demoed the site to the charity and they were very excited and happy with the solution.

This week we began building a demo for an accounting firm who needs to be able to grant access to external clients. While talking with our Business Developers and other team members I recommended we re-use the ACS access for this new site to give the external users access. I first attempted just enabling the current ACS Trust for my new Account site, but found that it was trying to authenticate me to the original charity site. After a little playing around here are the steps to allow multiple sites to authenticate with a single Windows ACS.

Add a new Relying Party Application

From the Windows Azure AppFabric portal (or the demo portal as we are using) select your existing SharePoint 2010 Service Namespace and click on the Access Control Portal button.

From the Access Control portal select the Relying Party Applications


In the Relying Party Applications click Add.


Provide a unique name and realm for the new application.

Make sure you increase the Token lifetime so you don’t get stuck in a token issue-reissue cycle. For the Rule Group use the same rules I created for my previous application. Also make sure you select the “Use a dedicated certificate” for the Token Signing Setting. You can re-use the same certificate for each application or issue a new one, but if you don’t set this value one of the certificates created by Windows ACS will be used and your services will fail to authenticate due to certificate signing issues.

Now click the Save button.

At this point you should have a new relying party application listed.

Update your SharePoint Trust

Now you will need to go to your SharePoint 2010 environment and log in as one of the SharePoint Farm Administrators.
In Central Administration view the application previously configured with the Windows ACS. Here you are just looking for the name of the Trusted Authentication provider, we will need that name in order to access it from the SharePoint Management Shell.
Open the SharePoint Management Shell and type the following command:


To see all the properties of the provider type $provider in the management shell. This will result in a printout of all the properties.
Next we need to create a URI object so we can add a new realm to the Trusted Identity Issuer.


Now we can add the realm with the URI to the trusted provider we retrieved


Now update the provider.


Now when you display the Trusted Identity Issuer you will see an entry in the Provider Realms like this.

Update your SharePoint Site Authentication

Now we can enable the site to use this claim provider.

Go back to Central Administration->Manage Web Applications and select the new site.


Then select Authentication Providers and the name of the Zone you want to allow ACS authentication for.


Scroll down in the Edit Authentication window and check the Trusted Identity provider and your Windows ACS provider name (this is the same name we used above in the SharePoint 2010 Management Shell).


Now scroll all the way down to the bottom and click Save.
Now go and log into your site with a non Windows ACS account. This way you can add some Windows ACS accounts to your site and test.
Once you have added some accounts go ahead and give it a try, you should be able to log in using your Windows ACS service on both the original and the new site.
Need to set up ACS for the first time? I recommend using these sites:

https://blogs.pointbridge.com/Blogs/nielsen_travis/Pages/Post.aspx?_ID=38 (this is a bit older version of ACS, so the UI is different)

http://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml-authentication-with-sharepoint-2010-and-azure-access-control-service-part-1.aspx

Visual Studio 2010 SharePoint List Template Error

I was attempting to create a custom FAST Search Center that would have a custom master page, and some web parts added to the search and result pages. My starting point was to grab the FAST Search Center site definition from the site templates in the SharePoint 14 Hive.

Next, I added the search tab and result tab lists to the site collection. Again I copied the XML from the SharePoint site definition…well almost. I actually copied all but the root node which had an XML namespace. After pasting this content I noticed under a few nodes, and some attributes, the little squiggly line. When I built the solution I noted warning messages but there were no errors. However, the deployment failed with an XML validation error.

As I began comparing the SharePoint list template with my list template I began removing various segments, starting with the ones that we marked as errors. While this resolved the deployment issue my lists did not function properly with the Site Template.

Next, I removed the XML namespace and the restored the previously erroneous XML, this time without any squiggly line or build warnings. When I deployed the solution no errors or failures occurred and my Custom FAST Site Template worked perfectly.

SQL Server Date vs. DateTime columns and the SharePoint 2010 External Content Type

Recently I have been working on a SharePoint 2010 solution that leverages External Content Types for storing information associated with Microsoft Dynamics Great Planes Timesheets. Part of the information captures when an task is expected to be completed, which the UI allows the user to select a date from a calendar. Since the only significant information for this field was the date when I designed the database I chose to only capture the date value. Testing on my local Windows 7 VM worked perfectly and we rolled the solution out to the customer for testing.

In the late testing stages the customer sent back a critical issue. The date value selected by the user was being changed, worse when the associated information was imported from Timesheet to Timesheet (because it was an ongoing task) the dates were moving further and further back in time.

I have seen this issue before with SharePoint 2007, pre SP1, that on DateTime field inputs if you didn’t convert to from local time to UTC your dates would not appear correctly. Immediately I added code to manually convert my captured time from local to UTC. I then changed the Time Zone on my VM so I would have a similar offset (originially I was running with GMT time myself thus I had not seen this issue). As I began testing I continued to see the same issue the customer was seeing, even with my conversion to UTC.

With the debugger attached I began looking at the values going into and out of the database. What I noticed was that a value going in would be something like 1/1/2011 05:00:00 but the value being returned looked like 12/31/2010 19:00:00. Looking into the External Content Type I noticed that it was using a DateTime .NET object. This means that when the value is retrieved from the database if the time is not in the database field then it defaults to 12:00:00. From there SharePoint performs the conversion from UTC to the local timezones (in this case subtracting 5 hours).

Lesson from this is to make sure you use full date time fields with your external content types.

Microsoft Silverlight 4 and SharePoint 2010 Integration

Recently I was contacted by PACKT Publishing because they have recently published a book Microsoft Silverlight 4 and SharePoint 2010 Integration and wanted me to review the book.  I’m actually quite excited about this opportunity because it is my first invitation to review a book, and the book is talking about two of my favorite technologies!

Currently I have a deadline approaching for a SharePoint 2007 Farm Architecture document, my least favorite thing to do, so I’m not allowing myself a lot of time with “fun” stuff like the topics in this book until the documentation is complete.  However, I have reviewed the first chapter and I really can’t wait to get back to it.  The first chapter is a very straight forward approach to creating a Silverlight Application and then including it in SharePoint 2010.

PACKT has published the first chapter “Integrating Silverlight 4 with SharePoint 2010” here for others to read before purchasing the book.

Once I have gotten through my documentation work I will take the time to review the book, try the examples, and will then post more about it here on my blog.

SharePoint and Membership Providers

Many SharePoint developers have come from a background with ASP.NET and so most are familiar with the Membership Provider concept.  SharePoint uses ASP.NET at its core the membership providers you have build for custom web applications can be used in your SharePoint web application.  The advantage of this is that you can abstract your web parts, application pages, etc in SharePoint so they use the Membership Provider to get user information rather than coding your own Active Directory calls into a library or the web part/application page itself.

Although SharePoint can use membership providers for authenticating users it does not require the membership providers be configured unless you want to use them.  So what happens when you use a web part or application page with membership provider logic on a SharePoint site that does not have the membership providers configured?

What ends up happening is that SharePoint, by default, assumes you are trying to talk to a SQL Membership Provider.  In fact, SharePoint assumes you want to use the default ASP.NET SQL Membership Provider (System.Web.Security.SQLMembershipProvider).  This surprised me because SharePoint by default uses Windows Authentication (Active Directory or local machine accounts) for authentication, not SQL.  The resulting error is also not very clear as it simply states “Unable to connect to SQL Database”.  This error may also occur if you have not specified a membership provider default provider in the web.config xml.