Nevron Charts for SharePoint : an alternative to Dundas

Way back, I had written a post about Dundas Charts in SharePoint 2010, after Microsoft obtained licensing rights for the web part and added a lightweight version of the web part out of the box in SharePoint 2010.

I recently came across a project that required a charting component, and after seeing their ad in the msdn magazine, found Nevron Charts for SharePoint. They were reminiscent of Dundas charts, and after using their evaluation version, I decided to buy their license.

Here are few key differences between the two:

- Nevron is a good product with pretty much the same capabilities as Dundas. Some capabilities are difficult to figure out, require some research and their knowledge Base and Customer Support is not as good as Dundas.

- The product is not as easy to configure as Dundas but the price point is much lower than Dundas Charts, and I think it is really good value for the price point.

- If you know Javascript well then it might be easier to do dynamic charts accepting parameters from other custom web parts. For example, you need to pass a Drop Down list selection to a chart as a parameter.

- If you want to load a simple Sharepoint list or a data from a predefined database using stored procs, with some basic sorting and filtering, you will not have to struggle much, but, as the requirements start getting more complex, it will be harder to figure things out from their knowledge base.

- Just like Dundas, Nevron charts interactive capabilities such as 3-d, dynamic themes, Mouse overs, Dynamic Chart Titles, Drill Downs are pretty good.

iPad Safari access of a SharePoint 2010 Web Application

As a continuation of my previous blog post located here, I would like to explain further progress made in the investigation of accessing a SharePoint 2010 Web Application using the iPad Safari browser.

We have found that exposing a SharePoint 2010 Web Application using Claims based Authentication and turning on Integrated Windows Authentication does seem to improve the user experience significantly, in fact, it is pretty close to a seamless experience.

The reason I say "almost" is because the first time the site is brought up on Safari we experienced difficulty bringing up the site, but  upon doing the same  the second time ( we are still trying to research the exact reason), the site came up fine. The user experience is find after that, even after I cleared  cookies on the iPad.

I have to say, if you have no option but to Windows Authentication, then this is the best experience I have seen so far on iPad Safari. If you have other options, then using the ASP.NET Sql Membership and Role Providers will provide the best user experience on an iPad. And if you want to test the experience without doing putting any effort, simply create an Office 365 test account, and test the SharePoint Online site on iPad Safari.

Single Sign-on: Just like your on-premise SharePoint installation allows pass through for NTLM and Integrated Windows Authentication Sites, how would you turn on Single Sign-on on an iPad? If you organization uses some form of Mobile VPNsolution, that could be the answer. Or, The answer lies in your Corporate Identity Management strategy. Here ins potential solution: If your identity Management solution supports SAML, you could enable single-sign on by making the SharePoint 2010 Claims aware Web Application use that Identity Provider (IDP) as a trusted identity provider, as shown in the screenshot below:

(the names of the provider have been erased in the screenshot due to confidentiality reasons)

However, Mobility remains a challenge with SharePoint On-Premise installations, at least up until the SharePoint 2010 Release. I am not sure if the issues have been resolved for Windows Authentication Sites using the SharePoint 2013 Platform. Will be testing further and blogging my findings.

iPad Safari issue with SharePoint 2010 Web Applicaton using NTLM Authentication

Problem: A SharePoint 2010 Web Application viewed on Safari on an iPad randomly prompts for  login credentials in the same browser session even though the user has already been authentication once.

This issue has ONLY been found on a Web Application with the following characteristics:

- It uses NTLM (Active Directory) Authentication

Solution: It turns out there is no OOTB solution to this issue. There are only workarounds. 

Any one of the workarounds described below should resolve this issue:

Workaround #1) The same site that does not work well with Safari on an iPad has been found to work seamlessly in the Chrome Browser on the iPad. You can either ask users to always use that site on Chrome by typing the Url or deploy a native iPad app that launches the Url of the SharePoint 2010 Web App in Chrome automatically, giving the users a more seamless experience. In the desktop world we call these shortcuts. 

Believe it or not, creating the shortcut for Chrome is not as easy on an iPad as it is on a Desktop. Apple forbids iPad users from making Chrome as the default browser, preventing any shortcut from opening Chrome. There are other solutions that have been suggested, such as the one in this link, but it still requires a user to manually set up the link. For Enterprise users, many of whom might not be very tech savvy, it might be a hard solution.

Both the Chrome app and the native iPad app suggested in this workaround could be deployed remotely to Enterprise iPads if you have an MDM solution in place, making the experience seamless for Enterprise Users. The code for the Xcode project can be downloaded here.

Once you download the project, you will need to modify the bundle identifier, upload the App Icon for your App, modify the Url to open in Chrome in the AppDelegate.m file, Build the Xcode Project, test and distribute based on your preference (Ad Hoc distribution, MDM, App Store etc.).

I got the code for the project from the following link provided by Google on how to open Urls in the Google Chrome App automatically.

https://developers.google.com/chrome/mobile/docs/ios-links

Workaround #2) Extend the Web Application to use FBA (whether you use it or not), create a different URl and have users navigate to the different Url from iPads.

You can do so using the steps outlined below:

· Zone-1: A URL that uses NTLM, good for use on internal users/desktops machines within the office.  So you can utilize the pass-through authentication of NTLM (no prompts for any password or authentication method).

· Zone-2: A secondary zone/URL for use specifically for the iPad (so the user is prompted for an authentication method and their username/password).

· It will not be possible to simply have one URL that will work seamlessly between internal users/desktop computers and iPad users, unless the internal users do not mind the hassle of selecting an authentication method and then typing in their password every time they want to access the portal.

· However, you can devise a redirect page on the main URL that will detect the user’s device (desktop, tablet, smartphone) and redirect the user to the appropriate URL (you will however still need to setup two webzones/two URLs to see this solution through). OR, you could have some sort of automatic redirect at the Firewall that determines from the device accessing the portal and then redirects the user to that url. But SharePoint will need to have 2 Urls and 2 Zones for this to work.


Workaround #1) seemed to be a better solution that Woraround #2) because of the following reasons:

a) Requires less communication to users about 2 different Urls for the same Web Application.
b) Does not require making architecture changes to the SharePoint Web Application by creating two zones, one with FBA authentication and the other one with NTLM Authentication,
c) Since the problem is specific to iPad safari, the solution should be specific to the iPad and not force us to modify the Architecture of the Web Application we set up originally.
d) If an Enterprise has a strong MDM platform, which many organizations do these days, the App developed in Workaround #1) can be deployed remotely along with the Google Chrome App and make the experience seamless for users.

Workaround #3) If there is an option to use claims based authentication, you could use  that and use Integrated Windows Authentication along with it. That has seemed to work the best on Safari, although not without issues. It often randomly prompts for login twice and works on Chrome better than Safari. However, it works much better than a web application with NTLM Authentication.

SharePoint 2010 List: Customize Form with Infopath Bug with Calculated Columns

I recently stumbled upon a bug with the 'Customize Form' feature on a SharePoint List. If you have a calculated column in your SharePoint List and are trying to represent it with reduced number of decimal places, either directly through the cloumn definition or through a calculated formula (such as ROUND() etc.), the value is calculated and displayed correctly in the List Views, but when you open the individual list item in an infopath form, Infopath represents the entire number, including all the decimal places, and does not respect the original column definition or any calculated formula.

The bug can be rec-created by following the steps below:

1) Create a simple Custom List  and add two columns, one called Numerator (a 'Number' type of Column) and the other one called a Denominator(a 'Number' type of Column), as shown in the screenshots below:

Numerator Column

Denominator Column

2) Add a third column, a 'Calculated' type of Column, called Num/Denom that simply divides the Numberator by the Denominator. Make sure you set the number of decimal places on this column as zero, as shown in the screenshot below:

Num/Denom Cloumn

3) Now, try to Click on 'Customize Form' in Infopath and add the Calculated Column created in Step 2) to the Infopath form, as shown in the screenshot below:

'Customize Form' View

4) Now try to add a new list item, you will notice that even though the Num/Denom is calculated and displayed correctly in the All Items view (see screenshot below), it is not displayed correctly when you open the list item (see screenshot below).



List View



The Individual List Item View

At the time of writing this blog post, I have not reported the bug to Microsoft but will be doing so soon.

SharePoint Farm Secure token Service Issue due to a WCF Update

I was woken up early morning yesterday and informed about an issue on our SharePoint Farm. All the web applications in the farm were down, and showing errors (as shown in the screenshot below) to any user trying to login.

My first guess was that it was a custom solution (such as a web part, event receiver, timer job) that we deployed that might have caused the issue. Upon investigation, it turned out that was not the case. I then looked at the ULS Logs. The following error was found:

"An exception occurred when trying to issue security token: The requested service, 'http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc/actas' could not be activated. See the server's diagnostic trace logs for more information.. "

We also saw the error shown in the screenshot below with the User Profile Service Application:

User Profile Application’s connection is currently not available. The Application Pool or User Profile Service may not have been started. Please contact your administrator”.

Upon checking the User Profile Service Application Pool, it was found to be running and the Services were running on the server.

This error told us that something was wrong with Authentication within SharePoint, which is probably why no user was able to log on SharePoint. This also told me that there was probably something deployed lower down the stack, probably either a SharePoint update or a Windows update that broke the STS. We started checking Windows Update and found that one of the updates applied to the server was: kb2756920

On further checking we figured that one of the update kb2756920 for Windows Server 2008 r2 looks to resolve WCF Security issues with the STS. As explained in the blog at:

http://sharepoint.nauplius.net/2013/01/installing-kb2756920-ms13-004-on-windows-server-2008-r2-rtm-breaks-sharepoint-2010/

However, since this is a production box, installing SP1 would have been a rigorous process and we needed to bring up our farm asap. Uninstalling the update, would have left our STS with the very vulnerabilities that the update was designed to fix. Upon calling Microsoft, we were told we could apply a SharePoint hot fix described in the link below: The hotfix is something the blog post does not mention and we learnt about it from Microsoft. It can be accessed here:

http://support.microsoft.com/kb/2637518

Just applying this hotfix on both the WFE and APP server and rebooting the servers brought the SharePoint Farm back up. Users were able to login successfully.

However, we still had issues with the User Profile Synchronization service. The User Profile Service Application we showing 0 profiles so we had to do a synchronization back to AD. 

Several attempts to the the AD synch failed and we got errors each time. Upon analyzing the ULS logs once again, we got the following error message: 

01/14/2013 11:47:13.52              w3wp.exe (0x0200) 0x1014    SharePoint Foundation          Runtime  tkau         Unexpected                System.IO.FileLoadException: The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)    at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.InitializeIlmClient(String ILMMachineName, Int32 FIMWebClientTimeOut)     at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)     at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.ProfileAdminPage.IsProfileSynchronizationRunning()     at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.ProfileAdminPage._CheckProfileSynchronizationStateAndNavigateJS()     at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.ProfileAdminPage.OnPreRender(EventArgs e)     at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.SyncNow.OnPreRender(EventArgs e)     at System.Web.UI.Control.PreRenderRecursiveInternal()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     6e86cdbe-18a1-4a14-b83c-7134295e8a60

Upon searching the internet, we found the following blog post:

http://sharepointguideme.blogspot.com/2012/04/sharepoint-2010-user-profiles-you.html

This blog gave us an idea to do an IISRESET on both the WFE and App Servers. AS soon as we did that, the User Profile Synchronization Service started and we were back up completely.

Export to Excel and Email SharePoint Lists in a Timer Job

Problem Summary: SharePoint Lists need to be exported as Excel Worksheets and emailed to users on a scheduled basis so that they could be accessed via any device at any time.

The idea was communicating with team members without direct access to the list through a browser due to the nature of their job and also because people generally find it much simpler when information is pushed to their email accounts instead of them having to logon to a portal, click a few times and then be able to get the information. 

For example, a busy Sales Executive who travels a lot and is used to only carrying a mobile device for most purposes. 

Even though the OOTB Export to Excel is a great feature, it cannot be called over an API.  

Solution:

We had to write a custom timer job that would do the following:

- Run on a scheduled basis and find all the lists that need to be emailed as Excel Worksheet (the List Names could be read from a Config list). These lists may be spread across several Site Collections so the timer job needs to read the list name from the Config List.  

- Find the Views that need to be exported for each such list (the view name needs to be read from the Config list). 

- Export each List to a separate Excel Worksheet, using the View Name for Column List. 

- Either save the exported Excel Worksheet to a document library, or send the worksheet as an email, with a custom Email Message (the Email To, Subject and Body could be read from the Config list). 

- We also added a feature where the timer job would dynamically add columns such as an Item Url that don’t exist in the View, just in case the user wanted to access the Item directly by clicking the link. 

Code for the Timer Job can be accessed here. The code will deploy the timer job and feature to all Site Collections. All you need to do is activate the feature on Site Collections you want to run this timer job on. Activation of the feature will provision the Config List, using which you can specify all the fields mention in the explanation above. When the solution is deployed it also copies a template excel file to a folder in the Layouts folder. That was required in order to make the Export to Excel Utility work.

Powershell Script to download attachments on a SharePoint List into a file share

Problem Description: Download all attachments on a SharePoint List to a File Share. Each set of attachments for a List Item need to be in its own folder, with ItemId as the name of the folder.

Solution: Powershell script shown below was run. The script took about 5 minutes to run on a list with 3000 items, each containing between 1 and 5 attachments. Average size of an attachment is between 1 and 5 MB.

   1:  $webUrl = "Url"    

   2:  $library = "ListName"   

   3:  #Local Folder to dump files

   4:  $tempLocation = "FolderPath"     

   5:  $s = new-object Microsoft.SharePoint.SPSite($webUrl)    

   6:  $w = $s.OpenWeb()         

   7:  $l = $w.Lists[$library]    

   8:  foreach ($listItem in $l.Items)

   9:  {

  10:      Write-Host "    Content: " $listItem.ID 

  11:       $destinationfolder = $tempLocation + "\" + $listItem.ID          

  12:        if (!(Test-Path -path $destinationfolder))        

  13:         {            

  14:          $dest = New-Item $destinationfolder -type directory          

  15:         }

  16:      foreach ($attachment in $listItem.Attachments)    

  17:          {        

  18:              $file = $w.GetFile($listItem.Attachments.UrlPrefix + $attachment)        

  19:              $bytes = $file.OpenBinary()                

  20:              $path = $destinationfolder + "

\" + $attachment

  21:              Write "

Saving $path"

  22:              $fs = new-object System.IO.FileStream($path, "

OpenOrCreate")

  23:              $fs.Write($bytes, 0 , $bytes.Length)    

  24:              $fs.Close()    

  25:          }

  26:  }

Reference: Thanks to this blogpost. I tweaked the script mentioned on this blog post for the above purpose.