May 13, 2013 - 13:32, by Steven Van de Craen
Categories: Claims, SharePoint 2010, SharePoint 2013Claims based authentication in SharePoint 2010 and SharePoint 2013 works with a FedAuth token that can be kept on the local machine for a configurable amount of time. This leads to an effective Single Sign On even between client reboots, as long as the cookie and the token aren't expired yet. The SSO experience also works for Microsoft Office and Explorer View, so the user can transparently open and edit documents and workbooks from the SharePoint environment.
When configuring the Web Application with only Windows Authentication, the FedAuth cookie isn't written and the Windows handshake will need to redone when the browser is closed or when opening documents from Office applications. If the client cannot automatically authenticate the Windows user, it will present a credential prompt which may be undesired.
The Win Auto SignIn component is a sign in page for a Claims Authentication Web Application that automatically redirects all requests to do Windows (NTLM, Kerberos, BASIC) sign in for SharePoint 2010 and SharePoint 2013. It has the benefit that it will generate a FedAuth cookie for the Windows user as well.
Once you have the dual authentication (Windows and FBA) and custom sign in page configured, your users will automatically be redirected to use Windows authentication for the SharePoint Web Application, but with the benefit of having a FedAuth cookie.
Reference
http://ventigrate.codeplex.com/wikipage?title=Win%20Auto%20SignIn
May 4, 2013 - 08:02, by Steven Van de Craen
Categories: BIWUG, Claims, SharePoint 2010, SharePoint 2013
Last Saturday I delivered a session on “Claims for developers” at the 3rd Belgian SharePoint Saturday edition, focusing on Claims Based Authentication. It was great to see that there was a lot of interest in this topic, since it’s something that allows you to do some very cool things.
It was a really fun event and I am really proud to have been part of it! Kudos to the BIWUG people for doing all the hard work organizing this.
http://www.biwug.be/
http://www.sharepointsaturday.org/belgium

I promised to share my slides and the code I demoed, so here it is.
Slides

Code
Here’s the code package with the following:
SPSBE2013.ClaimsForDevs.zip
- Role Claims Provider – copies incoming “role” claims that aren’t mapped (augmentation), resolves a list of known claims (received from a web request) to the Entity Picker
- FBA Login Page – additional functionality such as Reset Password (with Captcha)
- Windows Login Page – when configuring dual auth on a Zone, use this page to force users to Windows Authentication
- SAML Login Page – custom redirection to the STS so we can use a generic realm for our STS registration in SharePoint
- SAML Logged In Page – Debug overview of claims for current user, can be used for updating SPUser
- STS – Security Token Service with username/password, Facebook and Twitter login. Normalizes the user and provides custom claims. Contains custom redirection logic for SharePoint (generic realm)
- SampleApp – Sample application configured for authentication delegation to the STS. Displays all claims in the token.
I can’t share the code for the Profile Manager (DB UI) due to copyright.
The package also contains some basic deployment steps.
Disclaimer: all code can be freely used and modified as desired, but I don’t take any responsability for bad things that might occur should you do so 
April 17, 2013 - 15:32, by Steven Van de Craen
Categories: Office 2013, TroubleshootingSince a few weeks I’m experiencing an issue with Microsoft Word 2013 when I try to open a document from SharePoint 2013 (or even downloaded from SharePoint 2013). As soon as it tries to load the Document Information Panel (DIP), it crashes ugly.

If I change the internals using good old Content Control Toolkit so that the DIP doesn’t use cached data…

… it opens without loading the DIP or crashes.

It might have to do with the Taxonomy (Managed Metadata) fields that we’re using, but still it shouldn’t happen.
I tried Fiddler to see if there were requests being made but nothing turns up, perhaps I need a full network traffic monitor to see all things happening. It happens on a fresh local account as well, so it’s not that my local cache is corrupt or anything.
I’ll wait for the next updates to roll in, and hope they fix it...
February 6, 2013 - 13:42, by Steven Van de Craen
Categories: Claims, Troubleshooting, SharePoint 2010, SharePoint 2013Scenario
If a SharePoint Web Application is configured with Claims Authentication, you might run into an issue when trying to map SharePoint as a network drive.

If you only have Windows Authentication configured on the Zone…

…you’ll be either automatically signed in or get a credential prompt and you’ll see the SharePoint content just fine.

But if you’re offering multiple authentication types on a single zone…


…you might get a nasty error.

| The mapped network drive could not be created because the following error has occurred: Access Denied. Before opening files in this location, you must first add the web site to your trusted sites list, browse to the web site, and select the option to login automatically. |
Cause
If this is the case, it probably is because you’re not getting logged in automatically using the Windows Authentication option.
You can test this fairly easy by going to the URL you’re trying to map in Internet Explorer. If you get there without having to choose the authentication type, you’ll be fine for your Network Mapping.
Now if you close that browser and redo this and you have to select the authentication type *again*, it probably means your SharePoint environment is configured to use session cookies rather than persistent cookies.
PS C:\> $sts = Get-SPSecurityTokenServiceConfig
PS C:\> $sts.UseSessionCookies
True
Once you change this to use persistent cookies, you can close the browser and it will remember you as long as the cookie is valid.
PS C:\> $sts = Get-SPSecurityTokenServiceConfig
PS C:\> $sts.UseSessionCookies = $false
PS C:\> $sts.Update()
PS C:\> iisreset
Back to the issue
Once you have persistent cookies in place, you must first create it using the browser. This is required because the Network Mapping dialog doesn’t allow you to pick the authentication type. So go ahead and log in to your SharePoint site using your browser.
Now you can go create a Network Mapping and it will work as long as the cookie is present and valid.
If the cookie is removed and you reboot, you’ll get an error again.

|
An error occurred while reconnecting Z: to http://intranet.******.com/Shared Documents
Web Client Network: Access Denied. Before opening files in this location, you must first add the web site to your trusted sites list, browse to the web site, and select the option to login automatically.
This connection has not been restored.
|
To get it working again you just have to log in into the site with your browser to create the cookie. This will make the network mapping work again.
Hope this helps!
February 5, 2013 - 11:38, by Steven Van de Craen
Categories: Visual Studio, SharePoint 2013Do you have your SharePoint 2013 / Visual Studio 2012 development environment up and running ? If so, you might encounter the following error when you create a new SharePoint Project and enter the URL to your site:

Cannot connect to the targeted site. This error can occur if the specified site is not hosted on the local system. SharePoint solutions work only with locally-installed versions of SharePoint Foundation or SharePoint Server. Remote development is supported only for apps for SharePoint 2013.
If you – like me – registered the site URL in DNS (local DNS on development machine) then you’ll get this error. It seems that Visual Studio looks at the hosts file (C:\Windows\system32\drivers\etc\hosts) for fully qualified names instead of DNS.

Once you add the site’s URL to the hosts file (either to 127.0.0.1 or the local IP of the development machine) all is good and Visual Studio will connect just fine.

Hope this helps!
January 26, 2013 - 19:41, by Steven Van de Craen
Categories: SharePoint 2013The ViewFormPagesLockDown Feature (Site Collection) in SharePoint 2013 is activated and visible by default. This is not the case for previous SharePoint versions.

If you enable anonymous access to your site (or parts of it), you still need to deactivate this feature if you want those users to be able to dive into Lists or Libraries.
- Enable anonymous access in “Authentication Providers” (Central Administration > Application Management)
- Grant rights to anonymous users in “Site permissions”
- Grant rights to specific library (if applicable)
- Disable the “Limited-access user permission lockdown mode” Site Collection Feature (if applicable)
I’ve just spent the better half of the day troubleshooting this issue because it didn’t happen with a SharePoint 2010 upgraded Site Collection (because the feature is disabled by default), but was occurring on newly created SharePoint 2013 Site Collections.
Lesson learned.
January 21, 2013 - 12:44, by Steven Van de Craen
Categories: SharePoint 2013, CKS, SharePoint 2007Here’s a second post regarding the upgrade of my old SharePoint 2007 blog to a newer SharePoint version. Right now I’m running my blog on our new SharePoint 2013 infrastructure in SharePoint 2010 modus (deferred Site Collection upgrade).
CKS:EBE
I deployed the original SharePoint 2007 WSP to the SharePoint 2013 farm and lo and behold, it all seems to work just fine. I am missing a feature icon on the Web Application Features page, but that doesn’t matter.
The HttpModule and all other things seems to keep working, even in a Claims environment. Just one thing that needs fixing and that’s the MetaWeblog publishing API. It seems that in the current pipeline of the HttpApplication the claims stuff hasn’t finished initialising or whatever, but right now I get an error when trying to publish new blog posts from Windows Live Writer.
I’m working on a fix for that.
Content Upgrade
Since it was SharePoint 2007 I had to first upgrade that to SharePoint 2010 using DBATTACH. That gave the usual warnings but no big issues.
After that upgrade I noticed some views didn’t have the checkboxes for selecting multiple items. I fixed that in code by recreating those views, see more here:
» Upgrading SharePoint - Some views not upgraded to XsltListViewWebPart
I then attached the “SharePoint 2010” content database to our new SharePoint 2013 farm but didn’t do the Site Collection Upgrade yet. The deferred Site Collection Upgrade is really nice and seems stable. Not sure if there are any recommendations on moving ‘as soon as possible’ to a native SharePoint 2013 experience…
The biggest bonus I got from upgrading from SharePoint 2007 is that I can delete multiple spam comments at the same time using multiselect + delete 
Mobile View
I thought all was well (for now) but then I visited my blog on my phone and it gave me the mobile view. Sure I know you can append ?mobile=0 but that didn’t cut it for me.
I just went on disabling the Mobile View entirely for the Web Application, which can be done through the web.config (amongst other ways).
Here’s a nice PowerShell script that does that for you:
» Disable SharePoint Mobile View with PowerShell
Next steps
I will continue to work on the blog upgrade. I would like to fix the MetaWeblog issue, add some sort of image stealing protection, create a new design or work on closing the gap with the out of the box SharePoint 2013 experience.
Oh, and the blog is now available on an additional URL (which may be the single address in the future):
» http://www.sharepointblogs.be/blogs/vandest
Cheers!
January 8, 2013 - 14:14, by Steven Van de Craen
Categories: SharePoint 2010, SharePoint 2007Issue
One issue you might see when upgrading your content to a newer version of SharePoint is that not all views in SharePoint Lists and Libraries are upgraded.
What I’ve seen on multiple occasions is that some views aren’t upgraded. You can most easily spot them because there are no (multiselect) checkboxes on that view, even if you check “Tabular view” in the view settings.
Furthermore, if you append ?contents=1 to the URL you’ll see that the legacy ListViewWebPart class is used, rather than the new XsltListViewWebPart class.

Checkboxes missing:

Checkboxes present:

Manual fix
A manual fix would be to edit the page, go to the Web Part properties and just save without making any modifications. This seems to convert the legacy Web Part to the newer equivalent.
This would require quite some effort if you have many libraries of course.
Automated fix
I’ve been trying to reproduce the mechanism used by the manual fix described above, but not dice. The best I came up with is cloning the SPView and deleting the original one.
The base of the application will loop an entire Site Collection, through all sites, lists and views that match the prerequisite “IsLegacyWebPart”.
using (SPSite site = new SPSite(url))
{
// All webs in site collection
site.AllWebs.Cast<SPWeb>().ForEach(w =>
{
using (SPWeb web = w)
{
// All lists in web
web.Lists.Cast<SPList>().ToList().ForEach(l =>
{
// All legacy views
l.Views.Cast<SPView>().ToList().Where(v => v.IsLegacyWebPart()).ForEach(v => v.Recreate());
});
}
});
}
The “IsLegacyWebPart” check is an extension method that looks up the Web Part bound to the given SPView. If this is the legacy ListViewWebPart it will return true. I have yet to find a more optimized way of detecting a ‘legacy’ view.
public static bool IsLegacyWebPart(this SPView view)
{
bool result = false;
SPList list = view.ParentList;
SPWeb web = list.ParentWeb;
SPFile file = web.GetFile(view.ServerRelativeUrl);
using (MSWPP.SPLimitedWebPartManager man = file.GetLimitedWebPartManager(PersonalizationScope.Shared))
{
result = man.WebParts.OfType<MSWPP.ListViewWebPart>().Any();
}
return result;
}
Finally we have the “Recreate” algorithm for all legacy views.
public static void Recreate(this SPView view)
{
if ((view == null) || String.IsNullOrEmpty(view.Title))
return;
// Init
SPList list = view.ParentList;
string viewName = Path.GetFileNameWithoutExtension(view.Url);
string viewTitle = view.Title;
// Create temporary clone
SPView tempView = view.Clone("TEMP", "TEMP");
view.Delete();
// Create definite clone
SPView newView = tempView.Clone(viewName, viewTitle);
tempView.Delete();
}
public static void Delete(this SPView view)
{
view.ParentList.Views.Delete(view.ID);
}
public static SPView Clone(this SPView view, string newViewName, string newViewTitle)
{
SPView result = view.Clone(newViewName, view.RowLimit, view.Paged, view.DefaultView);
result.Title = newViewTitle;
result.TabularView = view.TabularView;
result.Update();
return result;
}
The “Recreate” extension method works with an intermediary temporary cloned view, because the view name has to be unique. If you clone a view with the same title/name it would be named “title1”.
The “Clone” method explicitly sets the “TabularView” property. I’m unaware if other properties need to be explicitly defined.
Download
I’ve wrapped it as a console application that needs to run locally on a SharePoint server. You need to run it as an account with sufficient permissions to manipulate views in the Site Collection.
Feel free to incorporate this in your application if you find it useful.

Note that not all hits will be solved, even with multiple runs of this tool. For example all Galleries will keep on using the ListViewWebPart. Another example are some special views on the blog site.
Hope this helps!
January 2, 2013 - 21:33, by Steven Van de Craen
Categories: SharePoint 2013, SharePoint 2010, SharePoint 2007, CKSI’ve been working during my spare time on upgrading our environments (intranet, extranet, blogs) to a brand new SharePoint 2013 platform. For the blogs this means I have to DBATTACH my content from SharePoint 2007 to SharePoint 2010, and then from SharePoint 2010 to SharePoint 2013. I’m also running CKS:EBE, a really cool community addon for SharePoint to give you just that extra (pretty urls, CAPTCHA, Modular Theme Framework, and the likes).
First I want to see how my content migrates between the different environments.
SharePoint 2007


SharePoint 2010


Note that the above screens were taken using a backup of my blog data from a few weeks ago, so some newer comments and posts aren’t showing.
SharePoint 2013


Result
The result is what you might expect from a DBATTACH upgrade, a full fidelity upgrade.

Next step will be to upgrade the CKS:EBE code. I might decide to create a light version with just the functionality that I’m using on my blog.
Stay tuned!
December 12, 2012 - 17:11, by Steven Van de Craen
Categories: SharePoint 2007, SharePoint 2010, Debugging, TroubleshootingOne of our projects makes use of Information Management Policies in SharePoint Server. We were programmatically adding these policies to Content Types, but for some reason this didn’t work when we migrated the application to SharePoint 2010.
Issue
We receive the following error:
System.ArgumentException: Invalid field name. {b0227f1a-b179-4d45-855b-a18f03706bcb} http://intranet
at Microsoft.SharePoint.SPFieldCollection.GetFieldById(Guid fieldId, Boolean bThrowException)
at Microsoft.SharePoint.SPFieldCollection.get_Item(Guid id)
at Microsoft.Office.RecordsManagement.InformationPolicy.Policy.EnsurePolicyFields(SPContentType ct)
at Microsoft.Office.RecordsManagement.InformationPolicy.Policy.CreatePolicy(SPContentType ct, Policy globalPolicy)
at VNTG.Initialisation.AddVersionLabelToContentType(SPContentType ctype)
If you dig deeper on that Field ID you quickly find that it’s the _dlc_Exempt field, one of the system fields for Policies.
At first we manually added them to our Content Types, but that didn’t feel right. It fixes the issue and allows you to work with the Content Type, but as soon as you start adding them to document libraries you’ll see strange things appearing. Fields are listed twice or missing in the List Content Type view, etc.
Solution
No need to manually start adding hidden system fields to your content types, just enable the “SharePoint Server Standard Site Collection features” feature on the Site Collection.
Next >>