Microsoft

Bye InfoPath, Hello Apps for Office & Lightswitch

The Microsoft Office announced  on Friday that InfoPath 2013 will be the final version released.  This is a significant announcement because it means any customer with custom SharePoint workflows, Office Document Information Panels, and any other Data Entry Applications will have to move those to a new technology, but Microsoft hasn’t said which one.

My Predictions

I believe Microsoft will recommend customers utilize one of two capabilities.  First, for customized Document Information Panels (those forms that can be added to Office applications, like Word, and can tie back to LOB systems or SharePoint) I believe Microsoft will recommend the use of the new Apps for Office Applications.  The Apps for Office allow creation of custom applications built on Web technologies like HTML5 and JavaScript and a set of Office JavaScript APIs are available for handling bindings to Office Templates.  The significant advantage, and disadvantage, here is that much can be done with customizing the retrieval of information from external systems, as well as customization of the injection of that information into the Document itself, but this also puts greater responsibility on the developers to request the information and push it to the application.

Second, for other business applications where data entry forms are needed, outside of the web, I believe Microsoft will push for the use of LightSwitch.  LightSwitch is a trimmed down version of the Visual Studio environment that allows for quick development of data entry applications/forms.  The information can easily be connected to XML or SQL data sources making this an easy replacement for the InfoPath Form entry design and use.

Feedback

I’d love to hear other’s predictions about what to do with the InfoPath applications that exist out there, so please leave a comment with your thoughts.

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