Wictor Wilen

Introduction The other day I posted about the patching procedure for the SharePoint 2013 Distributed Cache (Microsoft AppFabric 1.1) and on that post I got a great comment from Riccardo: Hi Wictor, is it possible to discover the patch level of the Distributed Cache without looking at control panel? Powershell? That is a great question Riccardo! But the answer is not that simple… Check the version using Installed Updates The easiest way to manually check what version of AppFabric you are using, or rather which CU that is applied to AppFabric 1.1, is to use the Program and Features tool in Windows Server and then click on View installed updates.

Introduction In SharePoint 2013 the Distributed Cache plays a very important role, it is a key component for performance and caching. An incorrectly configured or managed Distributed Cache will cause issues, with your farm. I’ve even seen blogs recommending turning it off, most likely due to that they don’t manage the cache properly and get into a situation where it causes even worse performance problems. One of the good things with the Distributed Cache is that is not a SharePoint service, it is a standalone service called AppFabric 1.1 for Windows Server. Initially the guidance from Microsoft was that the Distributed Cache (DC) would be patched together with SharePoint and we should keep our hands off it. But that has over the time changed and allowed us to take advantage of the fixes and improvements that the AppFabric team does to the service. So, it is our responsibility to patch the Distributed Cache. But how do we do it?

Introduction SharePoint 2013 (and earlier versions) allows you to use alternative authentication “sources” than Windows. We can part from the different options with Windows login, use Forms Based Authentication (FBA) or use a federated/trusted identity provider. Forms based authentication is a good approach if you don’t want to manage your users in Active Directory or if you don’t want to use Windows Login. The downside with FBA is that you must manually do some web.config modifications, there isn’t any UI for managing the users (yes, I know you can use LDAP or just download something from the tubez, but you get my point). Using a federated approach is more interesting, that allows you to get the identity management and authentication away from your SharePoint farm (and this is a really good thing, SharePoint admins are generally not identity management people!). A trusted identity provider is a service such as Active Directory Federation Services (AD FS), Microsoft Azure Access Control Services (ACS) or any other SAML 1.1 compatible Identity Provider (IdP).

Introduction The other week I posted an article about how to use SharePoint Hosted Apps when using SAML Claims, I did not expect that amount of feedback I had on that blog post, in e-mail, comments, tweets etc. Some of that feedback was how do you do it with Provider Hosted apps. Well you’re about to find out. It took me a while to get it properly done and there are some things that you should be aware of. In this post I will walk you through the simplest scenario and you will notice that there are a couple of moving parts. But, since I am such an influencer I thought I should make it easier for you. I will show you how to do this without the minimal changes to your current provider hosted apps – you only have to add an extension file to your solution, make a small modification to the helper files that Visual Studio gives you and a couple of web.config modifications! All the code you need will be published in a Github repository (https://github.com/wictorwilen/SharePointContextSaml) for you to consume and do all the fancy gitty stuff that you code dweebs out there like.

Introduction By now each and every SharePoint developer out there should spend their time building SharePoint Apps instead of the old trusted friend of ours; Full Trust Code. Ok, Apps doesn’t solve the equivalent of world hunger in SharePoint at the moment, but that’s a discussion for another time. I assume you get my point. We have two types of apps (we used to have three little monkeys jumping in the bed, but one just bumped his head); Provider hosted apps and SharePoint hosted apps. Without going into details, Provider hosted apps are the apps that are hosted outside of SharePoint on a specific location (URL) and SharePoint hosted apps are running on top of SharePoint (using JavaScript) on a “random” location. This location is called the App Web and is a SharePoint SPWeb with a specific randomly generated URL. That URL could look something like this:

For no one out there, in the SharePoint space or any other space, Microsoft Azure has gone unnoticed. Microsoft Azure is a really great service, or rather set of services, that for a (Microsoft or SharePoint) developer or IT-Pro is something that they should use and embrace. Personally I’ve been using Azure since the dawn of the service and I’ve been using it more and more. I use it to host web sites, host SharePoint and Office Apps, Virtual Machines, Access Control and a lots of other things.

April 1st 2014, for many a day full of jokes, but for 966 individuals this is the day they either is being awarded the Microsoft Most Valuable Professional (MVP) award or being renewed as MVPs. I’m fortunate to be one of those this time, and now for my fifth year! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in SharePoint Server technical communities during the past year.

Introduction This is the first “real” posts in the Workflow Manager Disaster Recovery series. In this post I will show you what you need to do to prepare for Disaster Recovery (DR) situations when working with Workflow Manager and Service Bus. The obvious Let’s start with the obvious pieces. You should run your Workflow Manager farm on three (3) servers (for more on this discussion see the SPC356 session). Running on three servers are important not just for high-availability it might save you from going into DR mode. DR should be considered as the last resort. You should also consider one or more SQL Server high-availability options, more on this later.

Introduction Welcome to a new series of blog posts in which we will focus on the Disaster and Recovery (DR) routines for Workflow Manager 1.0 in combination with SharePoint 2013. During SharePoint Conference 2013 me and SharePoint sensei Spencer Harbar presented a session called “Designing, deploying, and managing Workflow Manager farms” (watch the video recording). During that session we discussed different DR options for Workflow Manager and the Service Bus and we got tons of questions on that specific topic. We did not have time to go into details and we did not show any of the necessary scripts/routines you need to do when restoring a Workflow Farm or Workflow Scopes, and there is very little information available on that topic on the interwebs – so that is why this new blog series is being posted.