Home > Blogs > Eric Shupps | The SharePoint Cowboy
​The SharePoint Cowboy

SmartTrack for SharePoint Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave

photo of  Eric Shupps
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
September 30
SharePoint UK User Group Social Night - October 14th, 2015

What to do when you have a spare night in London after the Unity Connect conference? You get the SharePoint UK User Group gang together for a social event, that's what! If you are around the greater London area the evening of October 14th, please drop by and join us for a pint or two at The Old Star. Drinks are on us and we have some great prizes to give away, including a day out at the racetrack courtesy of Application Performance​. Mark your calendars and get registered now for a fun night of casual networking with fellow SharePoint professionals. See you there!

Registration link: https://www.eventbrite.co.uk/e/suguk-social-london-tickets-18837189541​

Brought to you by:  BinaryWave |  Metalogix |  Lightning Tools |  Application Performance

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 

SmartTrack Operational Analytics for SharePoint​​ 


August 24
The Future of Client Side Development in SharePoint and Office 365

Ther​e is a lot of discussion lately in the SharePoint community regarding the future of pure client-side applications (meaning those comprised entirely of HTML and JavaScript). Most of the posts I see are negative, with complaints centered around the lack of compiled code, complexity of app webs, perceived security weaknesses and inability to support forms-based authentication. Many of the detractors would have you believe that client-side applications, and specifically SharePoint Hosted apps, have no place in the enterprise and a limited future in both SharePoint and Office 365. But these complaints ignore some of the very significant advantages of client solutions and the benefits they offer developers. They also fail to account for the fact that SharePoint Hosted apps, like Sandbox Solutions before them, already have a supported lifecycle well into the 2016 release and beyond, meaning tens of thousands of SharePoint customers can and will continue to use them for the foreseeable future. But beyond that, the client solution model is at the core of every new API Microsoft is releasing in both the Azure and SharePoint space. It even forms the backbone of important applications like Visual Studio Code, the Azure portal, the Napa development toolset and many of the mobile app​​lications that Microsoft has recently released.

So on the one hand we have an admittedly less-than-ideal client solution model in SharePoint Hosted Apps but an incredibly robust set of web, mobile and even enterprise applications that use the same fundamental framework. Microsoft has made it clear that their preferred route is legacy .NET applications running on IIS outside of the SharePoint framework entirely, which makes sense considering the company wants to sell as many Windows server licenses as they possibly can. But is that approach realistic in light of the fact that the entire web is moving in the opposite direction? Are we once again going to be put in a position where SharePoint is years behind every other technology on the market (remember having to suffer through .NET 2.0 when 3.5 was already in widespread use everywhere else)? And just what is it that so many people, including those within Microsoft, seem to have against pure client-side applications? 

I’ve collected a few of the most common complaints I hear when speaking to developers about the App/Add-In model. Naturally, most of them come from existing SharePoint and .NET developers, who have a vested interest in the status quo of compiled server-side code, but I’ve even heard a few from so-called “architects”, IT professionals, system administrators, and developers transitioning from other platforms.  These are my thoughts on the subject, which will most likely generate some controversy, so feel free to add your own perspective in the comments and tell me why you think I’m right, wrong, or missing the point entirely.  

JavaScript Isn’t a “Real” Programming Language

This objection seems to be at the core of almost every complaint regarding client solutions. SharePoint hosted apps (SHA’s) by design don’t permit compiled code - that means no ASP.NET, no WebAPI, no classic MVC, no Java and so on. Proponents of Provider-Hosted Apps (PHA’s) are quite adamant that unless the code can compile then it IS a pile - of junk. They actually have a point in that JavaScript was never meant to be used the way it is being used today. Brendan Eich certainly never envisioned things like jQuery, AngularJS and Knockout when he cobbled to together the underpinnings of a simple browser-based scripting language. It doesn’t compile. It’s not strongly typed. It’s hard to debug. It doesn’t handle advanced (ok, even simple) math operations. You can’t create proper classes, namespaces and inheritance. All true (for now - ECMAScript 6 will change much of that). But guess what? NONE OF THAT MATTERS. It’s 2015 and the world runs on JavaScript. If you are clinging to ASP.NET MVC and Java the world has already passed you by. Is that to say server-side code no longer has a place? Of course not - it has a very valid place as the backbone of web services that actually make all that web and mobile front end goo work. But it’s not how front ends are written anymore and it’s not what user’s expect (when was the last time you encountered a postback from changing a value in a drop-down list?).

People can argue that real enterprise applications don’t run on JavaScript and they may have had a valid point a year or two ago. But that is rapidly changing. JavaScript is at or near the top of employer demand in every staffing survey. In Silicon Valley nearly everything runs on JavaScript and all of the various frameworks that support it. Google is a JavaScript machine and has thrown their support behind TypeScript, an abstraction framework (created by Microsoft, no less) that makes writing JavaScript much more akin to object-oriented programming. Angular 2.0, which is quite an important initiative for Google, is based on TypeScript.  The JavaScript train is gaining momentum and steamrolling everything in its path - already Angular is rocketing to the top of the GitHub and StackOverflow charts, running just barely behind ASP.NET and Ruby. It’s getting harder and harder to find a job without knowing at least one of the popular JavaScript frameworks. And some of these frameworks - like Node.js, Angular.js and React.js - are really, really good.

In the SharePoint world we have long been insulated from what is happening “on the outside”. We’ve traditionally lagged behind even the latest ASP.NET releases by at least one major version. With it’s heavyweight ASP.NET underpinnings and extensive server-side API SharePoint forced us to write compiled code if we wanted to get anything done. But all that is changing. The JSOM and REST API’s in SharePoint 2013 and Office 365 are iterating rapidly, delivering more and more functionality with every monthly release and quarterly update. Combined with advancements in the Azure space like the ADAL.JS libraries we can actually write end-to-end applications without ever clicking “build” in Visual Studio. The rest of the world has already moved solidly in this direction - you cannot argue with a straight face that sites like Facebook, Twitter, YouTube, The Weather Channel, Quickbooks Online and hundreds if not thousands of others are not “real” applications. Not to mention many popular mobile applications that have millions of daily users. And with the introduction of new ECMAScript features like classes, modules, and native promises, many of the old complaints about JavaScript fall to the wayside.

Sorry, folks - JavaScript is real, it’s in the enterprise and it’s here to stay. As a classic server-side developer I may not like it any more than you do but it’s long past time to get over it and get on with it.

SharePoint Hosted Apps Aren’t Secure

Complaints regarding app security are really complaints about OAuth, which replaces the tried-and-true method of every app having distinct authentication with a token-based authorization scheme designed to operate - sacre bleu! - over HTTP. Is this scheme inherently secure? Of course not! It’s susceptible to all kinds of attack vectors, from Man in the Middle, to Session Fixation, Covert Redirects and more. All those tokens flying around are just begging to be hijacked and exploited.

But guess what? None of that makes any difference. All - and I do mean ALL - of the major web players have embraced OAuth as the de facto standard for interoperability. So it doesn’t really matter that it’s inherently insecure or susceptible to exploits because everyone is using it and will continue to use it until something else comes along. For years Microsoft has forged their own path in the web standards world, going it alone even when they were sometimes in the right, and they’ve been marginalized in the greater web development community for it. They have now, wisely, chosen to change their ways and go along with what everyone else is doing. That means if you’ve written apps that integrate with Facebook or Twitter you know pretty much all you need to know to write Office 365 and SharePoint apps. That’s a win for Microsoft no matter how you look at it.

Besides, those who proclaim that SHA’s are any less secure than PHA’s are dangling a massive red herring. Guess what PHA’s use for authorization? That’s right - OAuth. There’s really no difference between authorization token requests made via an HTTPWebRequest method in C# and those made from JavaScript via AJAX - the POST operation looks the same to anyone sniffing the wire. You could argue that calling a compiled web service from JavaScript and letting the web service handle token management is a better approach but since there are no credentials being passed either way, it’s really a distinction without a difference; once the client is compromised, an attacker can keep making authorization requests to the web service and collect the returned data, which is the only thing they can do if they manage to hijack the authorization process anyway. The only real difference between SHA’s and PHA’s when it comes to OAuth is the inability to explicitly establish client context - in an SHA it’s inherited from the current HTTP context whereas PHA’s go through a token exchange process to obtain the requisite context object. But this doesn’t make an SHA any less secure; in fact, the end result is exactly the same.

One thing the detractors of SHA’s often forget is that from the customer’s perspective an SHA is actually MORE secure because it runs inside of their SharePoint environment (or Microsoft’s, in the case of Office 365) and they don’t have to worry about a third-party vendor’s servers being compromised. Is this more perception than reality? Certainly. But that doesn’t change the fact that each add-in the customer installs increases their risk profile because it explicitly allows a third-party access to sensitive company data. But don’t take my word for it - sit down with a Chief Information Security Officer and tell them you are going to permit vendors to copy company data to their servers with the only barrier being a single “Trust It” button clicked by a site administrator and see what they say (it’s worth it just to watch their face turn purple). Just because an app vendor tells you they aren’t copying your data who is to say that’s the truth? Every PHA that runs on a server not owned by the company is acting with full permissions on behalf of the user or as agreed upon by the site admin; you may think all is well because your users are happily clicking away on that fancy CRM add-in but behind the scenes it’s downloading every document in every library in the site and storing it away on somebody else’s servers. And you’ll never know it’s happening because it’s all being done outside your firewall; even worse, you blindly accepted a set of generic permission statements so you gave the vendor permission to do it! Could this also happen in an SHA? Potentially, yes, but the data can’t be stored in the SHA itself so the perceived risk is much  lower (the app could, of course, just upload the data to a remote endpoint from the client). Remember, there is no cloud - it’s just somebody else’s computer and one little click can give them the keys to your kingdom. 

The App Web Concept is Terrible

On this one we can all agree. App webs ARE terrible. They make lifecycle management a nightmare because developers cannot predict the URL of each app across farms or even across multiple deployments in the same farm. Users don’t understand them because they kind of look like a regular site but they really aren’t. A nonsensical proxy method is required just to communicate with the host web, which is where we all want to provision assets in the first place. And configuration makes IT Pros gnash their teeth dealing with wildcard certificates and DNS. They really, really suck. And don’t get me started on app parts because those are even worse. But that’s what we have to work with so until the situation changes there’s no point in getting all worked up over it. 

It’s no secret that a lot of people, including many within Microsoft, would like to see the app web concept - and SHA’s along with it - go the way of Sandbox Solutions (which, when you really think about, is all the app web concept really is: Sandbox 2.0).  There’s a reason nearly every sample in the Office Dev PnP GitHub repo is a PHA even though most of them don’t require any PHA-only features like remote event receivers; however, PHA’s also require an app web if they want to communicate with the host web in any way so this problem isn’t applicable only to SHA’s. I’ll agree with half of the sentiment, that app webs do need to go away. Like, right now. Today. But just scrapping them altogether doesn’t actually solve any problems. In many (actually, most) enterprises it is very difficult to get a web server provisioned. It requires numerous approvals, business justifications, allocation of scarce resources, etc. And before you say it, no, Azure is NOT the answer. Business units and IT shops can not increase costs from a usage-based resource any easier than they can spin up a new virtual machine. Just because an EA has Azure on it doesn’t magically transform compute units into freely available (or free) resources. Those costs have to be justified and applied to a cost-center; they are coming out of somebody’s budget somewhere and whomever holds the purse strings has to approve the spend. Besides, the customer bought SharePoint in the first place so they wouldn’t have these kinds of problems. Force them into spinning up a bunch of web servers alongside it and they’ll just go back to Full Trust Solutions. Guaranteed.

SharePoint Hosted Apps Don’t Support Forms Based Authentication

Very true. SHA’s and FBA don’t play nice together. But, when you stop and think about it, PHA’s don’t actually support FBA, either. You can create a PHA that uses FBA but it’s not the same credential that’s coming from SharePoint. There is no true single sign-on for apps unless you are building Azure web applications. So even if the user can login to SharePoint via FBA they still have to log into your app separately. Which doesn’t actually achieve anything since OAuth is required to communicate back to SharePoint. So the reality is that apps don’t support FBA period. The only difference is one of perception - the user thinks FBA works because they log into SharePoint once and get redirected to a PHA that uses OAuth behind the scenes to establish context. An SHA, because it runs on a separate web application, hits them with another login prompt so it appears not to work with FBA. But apply forms auth to the PHA and the user gets the same result. What is really needed is for Microsoft to fix the FBA problem altogether instead of developers fooling users into thinking something works when it really doesn’t.

I’m sure there are other arguments that people can raise against SharePoint Hosted Apps but those are the ones I hear most often. Now let’s move on to some of the positives, shall we?

Ease of Deployment

There is no denying the reality that SHA’s are so much easier to deploy than PHA’s, especially on-premise. Add the app, trust it, and you’re done. No certificate issues (well, no additional certificate issues, anyhow). No Client ID’s, Secrets and hidden expiration events. No PowerShell scripts with arcane TrustedSecurityTokenIssuer commands. No vendor servers and uncomfortable conversations with InfoSec. And despite the fact that they run inside of SharePoint, no WSP’s or IISRESET operations. 

It. Just. Works.

That’s not to say SHA deployment is perfect. Iterative deployments can wipe out configuration settings in the app web. That can be a real pain. And there just isn’t any effective way to perform automated deployments via a build server. Another bummer. Finally, modifications require re-provisioning of the app, a real downer if you are an ISV shipping frequent updates. All this is true. But there are some ways to mitigate these limitations. Configuration settings can be stored in the host web or a web service. Core JavaScript and resource files can be hosted in a private CDN or globally accessible location for ALM, with minimal markup in deployed HTML files to reduce update frequency. 

Most importantly, SHA’s don’t require any additional infrastructure. There is no need to request a new web server or justify additional cloud compute expenditures. They run where SharePoint stuff should run - in SharePoint (what a concept!). You can leave your resources free for those apps that actually need their own servers and which shouldn’t ever have been deployed to SharePoint in the first place. And you never need to have this ridiculous conversation:

     DEVELOPER: “We need to deploy a solution for SharePoint branding.”

     IT MANAGER: “Ok. Schedule a maintenance window and do it.”

     DEVELOPER: “Um, we need to provision a web server for our solution.”

     IT MANAGER: “What? Why? Can’t you just deploy the WSP via PowerShell?”

     DEVELOPER: “Well, Microsoft says we shouldn’t do that anymore and instead we should be building provider hosted apps now which don’t run in SharePoint. So we need a separate web server.”

     IT MANAGER: “Let me get this straight. You need to stand up a web site in order to apply branding to another web site?”

     DEVELOPER: “Um, yeah. And we also aren’t supposed to modify master pages so we have to do JavaScript injection. And, um, if a site admin removes the app the JavaScript modifications get orphaned and we have to redeploy the app in order to run our custom code to remove them.”

     IT MANAGER: “Come back to me when you have a WSP.”

Modern App Development

SHA’s run on JavaScript just like pretty much everything on the web these days (as can a PHA if you build it properly but - seriously, but - refer to my previous point). You can build them with whatever framework you fancy - Knockout, Angular, React, Breeze, it’s up to you. There are no restrictions on external web service calls like there were in the Sandbox so they can communicate with server-side endpoints hosted anywhere on any platform. There are an endless number of IDE’s for JavaScript development, from the venerable but eminently capable Visual Studio, to WebStorm, Eclipse, Sublime, and even good ol’ Notepad. And most of them run on platforms other than Windows. Microsoft even has their own play in the cross-platform segment with Visual Studio Code. If you really want to go whole hog, you can even run your server-side services on JavaScript with Node.js (which seems completely ridiculous to me, by the way - why rewrite yourself what Apache, IIS and other web servers already do very well?). 

Even better, the code you write for your SharePoint add-in can be virtually the same as what you write for that fancy mobile app that’s going to take the world by storm one of these days (as soon as you get around to writing it, of course). Have an existing mobile app that is mostly an HTML + JS front end that talks to a set of distributed web services (perhaps even running Azure)? Put it on a web server, code up a quick App solution and it runs with minimal modification as an App Part in an Office 365 site. Boom! Mic drop. 

Or, you can fire up Visual Studio and keep cranking out big, heavyweight ASP.NET applications that don’t run anywhere but on IIS and will never become mobile (or modern, for that matter). Sure, they are familiar and lots of organizations still use them but that’s not the direction the rest of the world is moving in. Even the tried and true MVC stack is becoming more JavaScript friendly with native support for Angular and other JS frameworks, along with UI methodologies like Bootstrap which is specifically designed for modern apps. We can never really know what the future might bring, and JS frameworks are notorious for not lasting any longer than a Dallas Cowboys playoff run, but what is clear is that we won’t be going back to heavy server-side code and postbacks ever again.

Availability of Resources

Just about every web developer nowadays knows at least one JavaScript framework, even if it’s only jQuery. They also know how to create and exchange data with RESTful services. Translating JSON into model objects and binding them to the UI via a ViewModel is second nature to them. The only thing they don’t know how to do is deal with the weirdness of SharePoint. That’s where we come in, all of us SP coders who have been mind-melding with the big black box for the last decade. We can show them how to turn their code into an add-in, how to get data from a list (what do you mean the field name needs to have “_x0020_” in it?), what a site collection is (wait, wait - tell me again: what’s the difference between a site and a web?), and so on. One senior SharePoint dev and a team of good JavaScript coders can crank out some seriously cool apps in far less time than it takes to get .NET web form developers to understand web parts and application pages. 

For companies trying to manage an ever-shrinking IT personnel budget (which is pretty much every organization on the planet) this is a huge boon. For years the biggest complaint about SharePoint development has been the inability to find people who actually know what they are doing. With apps, especially SHA’s, that’s no longer such a huge concern. Sure, you still need some quality SharePoint devs to lead the charge but you can now pair them up with web and mobile devs and watch the semi-colons fly about in a swarm of productivity.

Does this mean, as is often claimed, that Full Trust solutions are dead? Heavens no. Not by a long shot. On-premise SharePoint development still requires proper compiled solutions for implementing serious customizations. There just isn’t any real replacement for timer jobs, feature receivers, web parts and web templates in a real-world SharePoint deployment. But apps give you options, like not having to completely rewrite a web application as a set of application pages and web parts. Instead, that web app can continue to stand alone but gain some nice hooks into the company’s Intranet, such as remote data integration and ribbon integration. 

[It’s worth sounding a bit of an alarm on this subject before anyone gets the impression that it’s all wine and roses on the other side of the Golden Gate bridge. Most JavaScript developers have no idea how to produce quality, manageable, supportable code with real lifecycle management. The senior developer skills that result in code running mission-critical things like nuclear reactors and aircraft are almost completely lacking in the “modern app” space. This has to change and change fast - all this client-side goodness will crumble to dust if we don’t get some adults in the room to show the hipsters why grey hair matters. That’s why I’d personally like to see a lot of classic .NET developers move over to the client-side space so they can show the youngsters some proper development techniques.]

So what’s the takeaway from all this? From this developer’s perspective, client-side SharePoint Hosted Apps play a vitally important role in SharePoint and Office 365 extensibility. They are modern, easy to deploy, require less infrastructure and fewer scarce personnel resources. Are they perfect? Nope, there are important security concerns and the product engineering team really needs to come up with a better solution for hosting them than the app web concept and find a way to implement PHA-only features like remote event receivers. But in my opinion the advantages (or potential advantages) outweigh the drawbacks. The deployment story alone is enough to proclaim them superior to Provider Hosted Apps for on-premise and hybrid environments in my opinion. I’m sure many people will disagree with me on this but if you find yourself coming down on my side of the argument then you need to make your voice heard to the powers that be inside Microsoft lest they really do become the next version of the Sandbox and suffer a similar fate.


May 04
A SharePoint Conference Just for Developers? Absolutely!

​If you are a SharePoint developer then you have probably resigned yourself to the fact that most conferences offer little in the way of actual content for programmers. More often than not, there are four or five tracks of IT professional, information worker and business sessions with only a single track talking about actual code. Sure, some conferences do a better job of catering to developers than others, but by and large us lowly code-slingers don't get much respect.

Until now.

The awesome team over at BZ Media have taken notice of this situation and put together an entirely new event called SPTechCon Developer Days. It's a three day conference targeted specifically at Microsoft developers writing applications that leverage the capabilities of SharePoint and Office 365​. SPTechCon Developer Days will feature Microsoft speakers and MVPs, the brightest minds in Microsoft, Web and SharePoint development, to help you either start down the path to modern application development or help you expand your knowledge.  Offering more than 40 classes, panels and keynotes, SPTechCon Developer Days will help you understand the new application model, modern Web development architecture, languages and techniques, and much more.

If your job requires any type of programming against the SharePoint or Office 365 API's - from traditional full trust code solutions to the new cloud application model - then you don't want to miss this event. The cost is a fraction of those bigger events and you are guaranteed to not only receive exceptional developer-focused content but also plenty of time to ask questions of the speakers in a relaxed, comfortable atmosphere. Just look at this line up:

​​​​Marc Anderson
Robert Bogue
Andrew Connell
Timoth Ferro
Bob German
Doug Hemminger
Scot Hillier
Chris Johnson
Christine Matheney
Sean McDonough
Dustin Miller
Eric Overfield
Scott Peterson
Mark Rackley
Paul Schaeflein
Eric Shupps
Travis Smith
Jeremy Thake
Rob Windsor

That's a lot of SharePoint development expertise all in once place. They even have a downloadable letter template you can use to request approval from your boss - how cool is that? You really don't want to miss out on three days of great developer content from the folks who know it the best.

I'll be presenting four sessions at the event:

Creating Cloud-Ready Enterprise Applications with the SharePoint 2013 App Model

Resistance to the cloud is futile. Sooner or later, you’ll be asked to write an app for the cloud. Get ahead of the game and learn the skills you need to create dynamic, cloud-ready applications using the SharePoint App Model and Office 365 APIs. Explore common on-premise application scenarios and discover how these can be reimagined using new techniques, including CSOM, JSOM, REST, OAUTH, and Azure, with a focus on real-world enterprise scenarios. 

Pushing the Boundaries: A Deep-Dive into Real-World SharePoint App Development

You need to build solid apps that deliver real business value but the Cloud Application Model in SharePoint 2013 and Office 365 is a work in progress. How do you avoid the pitfalls and limitations that can sink a project? Where does the app model shine and where does it fall short? What hidden “gotchas” are lurking behind the scenes that you need to know about before getting started? These questions and a whole lot more will be answered in a series of deep-dive demonstrations and live-coding exercises. This is a no-holds-barred session that will show you exactly which techniques are ready for prime time and which don’t quite make the cut. 

Get Some REST: Taking Advantage of the SharePoint 2013 REST APIs

The SharePoint 2013 App Model introduces a new programming framework that provides expanded capabilities for remotely-hosted sites to interact with Office 365 and on-premise environments. A key part of this new model is an expanded and updated set of REST API's. In this class, we will explore the new REST capabilities in SharePoint 2013, learn how they are used and discuss best practices for implementation, security and performance.

Developing an Intranet on Office 365

Learn how to leverage the power of the cloud to build dynamic, informative and engaging Intranet solutions with Office 365. Get real-world guidance and best practices for driving user adoption and engagement through powerful features like cross-site publishing, metadata navigation and search-driven content, along with proven techniques for custom branding, interface extensions, authorization and app development.  

Be sure to register​ early as attendance is limited and the event WILL sell out. 

We'll see you in San Francisco!

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 

SmartTrack Operational Analytics for SharePoint​​ 

March 04
SharePoint Evolution Conference 2015 - The One Event You Must Attend

There are a lot of SharePoint related conferences going on these days, from free local events like SharePoint Saturday to gigantic marketing shows and everything in between. They all offer value in one way or another but nobody has the time or resources to attend more than a few. So how do you choose? I’ve often been asked what event I would attend if I could only pick one. That’s an easy answer - the SharePoint Evolution Conference in London. Why? Because dollar for dollar (or pound for pound, as it were) there is no better source of information from real-world experts who live and breathe SharePoint every day. Period.

Need some more convincing? Fair enough. Here are some other reasons why I think you should be booking tickets to London in April no matter where you live in the world:


8 tracks. 82 speakers. 160 sessions. That’s more SharePoint-focused content than even the big marketing conferences are providing. Read that again - 160 sessions in three days. The content covers everything you want to know about - administration, development, business, end user, architecture, social, cloud, and so on. Have SharePoint on-premise and planning to keep it that way? Good, because you’ll find plenty of sessions just for you (not just a sales pitch for the cloud). Speaking of the cloud, there will be a wealth of hybrid and Office 365 sessions to choose from as well, along with Yammer, Delve, Power BI, hybrid search, and a host of other topics. If you can’t find it here you won’t find it anywhere.


A really good conference is more about the content than the people presenting it but having said that many of the best SharePoint speakers in the world will all be in London. There will also be community contributors who have tremendous insights to share but who don’t often get a chance to speak at big events. These are the people who spend all day every day working with customers of all sizes to implement, extend, maintain, migrate and manage SharePoint (both on-premises and in the cloud). You can’t get any more real-world than that. This isn’t about marketing messages or sneak peaks of new features - it’s about giving you the very best information possible from the people who know it best. Still not convinced? Here are some of the fantastic speakers you will hear from in London but won’t hear from at the super-sized marketing shows:

Alex Pearce
Andrew Woodward
Ant Clay
Aonghus Fraser
Ben Curry
Ben Robb
Benjamin Niaulin
Bill Ayers
Bob Fox
Bradley T. Smith
Brian Alderman
Brett Lonsdale
Cathy Dew
Chandima Kulathilake
Chris Casingena
Chris O’Brien
Christina Wheeler
Eric Harlan
Eric Shupps
Gary Lapointe
Ian Woodgate
Joel Oleson
John Holliday
John Timney
Kimmo Forss
Kirk Evans
Marc Anderson
Mark Macrae
Mark Rackley
Mark Stokes
Martin Hatch
Matt Bremer
Michael Noel
Miguel Wood
Neil Hodgkinson
Paul Hunt
Paul Schaeflein
Paul Turner
Penny Coventry
Peter Baddeley
Rob Foster
Rob Pratt
Robert Schifreen
Sandra Mahan
Steve Smith
Symon Garfield
Ted Pattison
Todd Baginski
Todd Bleeker
Virgil Carroll
Wes Preston
Wesley Hackett
Wictor Wilén

Production Value

The Combined Knowledge​ crew do an amazing job putting together quality content and entertainment. The venue is intimate and inviting - no long hikes down endless corridors and exhibit halls you could park a jumbo jet in. The food is top notch, the staff are amazing and the parties are legendary. You won’t find a better organized, more accessible and hassle-free conference experience anywhere.


Come on, it’s London. L-O-N-D-O-N. And not out in some remote location only vaguely in the vicinity of the city - it’s directly across the street from Westminster Abbey. It just doesn’t get any better than that. The conference facility is amazing and there are endless opportunities for networking and casual conversation. And the parties? Oh, the parties - you won’t have more fun at a technical event EVER. Yes, you’ll learn a lot but you’ll also be entertained and have direct access to the speakers and organizers in a relaxed setting.


Conferences are expensive. The big ones are budget-busting expensive. But the Evolution conference is only £795 (that’s around $1,200 US dollars). Flights to London from most US cities are less than $1500 and much less from any location in Europe. Four nights in a London hotel can be had for as little as £500. That’s the entire conference, flights and lodging included, for about the same price as the cost of a single ticket to the big marketing events. Now that’s value for money you simply won’t get anywhere else.

So what’s the bottom line? It’s a no-brainer. For the best content, best speakers, best location and best price there is only one conference you should attend this spring. And that is the SharePoint Evolution Conference in London on April 20th through the 22nd. Make your plans now and reserve your spot because I guarantee you it will sell out soon.

I’ll see you in London!​

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 

SmartTrack Operational Analytics for SharePoint​​ 

January 29
The Dangers of JavaScript Injection in SharePoint Apps

The latest guidance from Microsoft suggests that the use of client-side API's is now the preferred technique for customizing the user interface in SharePoint 2013 and SharePoint Online. This is a distinct departure from the tried-and-true approach of using custom master pages to create a branded SharePoint experience. Naturally, this has stirred up quite a debate in the design-oriented segment of the SharePoint community - refer to this excellent blog post on the subject from Cathy Dew, get some additional thoughts from Heather Solomon, and see Chris O'Brien's developer-oriented take here. Leaving aside for a moment the pros and cons of this approach as it relates to branding, one thing is clear – UI customizations are being pushed quite forcefully back into the hands of developers. This is almost certainly not a good thing, as developers are notoriously poor designers, so it will be imperative that designers and programmers develop a close working relationship in order to ensure that customer requirements are met. Customers, for their part, must be prepared to pay an even higher "customization tax" than ever before, as significant changes will require both branding and development expertise on a single project, or leave aside all requirements for modifying the SharePoint UI (which, for many, will mean just giving up on SharePoint altogether).

To be clear, this doesn't mean that custom master pages are no longer supported (they are) or that branding is not important (it is) but rather that the pace of change in the cloud product makes the maintenance of custom master pages much more difficult. Remember, SharePoint online is a service not a product – as such it is subject to a much faster update cycle than the on-premise version. To be perfectly frank, if you want complete control over the SharePoint interface, then go with the on-premise product. Your customizations will last longer, breaking changes will be far less frequent and the only time you'll have to pay the customization "tax" is during the next upgrade cycle. And no, that doesn't mean you will be stuck with maintaining all those pesky SharePoint servers yourself – there are plenty of vendors willing and able to take that task on for you. But it does mean you will give up online-specific features like Delve in favor of a branded Intranet; whether or not that's worth the trade-off is a decision each customer will have to make on their own. Based on my experience many customers want both the flexibility of the cloud and the ability to implement some level of interface customizations, which is certainly achievable – within certain limits.

Which leads me to the point of this post - if you decide you want to be in the cloud (or be "cloud ready") but still want some interface customizations, then read on, as there is one big "gotcha" that you absolutely must know about before you move forward.

The technique Microsoft is now recommending for customizations is known as "JavaScript Injection". Simply put, this means pushing client script into a page through the manipulation of existing elements, much as you can do with compiled code and Delegate Controls in an on-premise, full-trust environment. Leveraging the power of client-side frameworks such as jQuery, this technique allows designers to hide, remove, replace, or insert DOM objects as they see fit. There is a good example of this technique in the JavaScript Injection Sample on the Office Developer Patterns and Practices GitHub site. In the sample description, the designer wishes to hide the "new subsite" link on the Site Contents page, which can be accomplished by adding the following JavaScript into the site master page:



In order to "inject" the code programmatically the developer must leverage the Custom Actions functionality of SharePoint within an App. This is the same set of API's that permit the addition of custom buttons and links to the Ribbon, Menus and Edit Control Block (for more on how to create custom actions refer to the following MSDN Article: https://msdn.microsoft.com/en-us/library/office/jj163954(v=office.15).aspx). There is an existing location identifier in the Custom Action framework named "ScriptLink". It is accessible via the UserCustomActions collection on the parent SPWeb object. By adding a new custom action to the UserCustomActions collection and targeting the ScriptLink element, the code is then inserted into all pages on the site which contain the target element. This can be achieved using the following CSOM code (from the same JavaScript Injection Sample on GitHub referenced above):

public void AddJsLink(ClientContext ctx, Web web)


string scenarioUrl = String.Format("{0}://{1}:{2}/Scripts", this.Request.Url.Scheme,

this.Request.Url.DnsSafeHost, this.Request.Url.Port);

string revision = Guid.NewGuid().ToString().Replace("-", "");

string jsLink = string.Format("{0}/{1}?rev={2}", scenarioUrl, "scenario1.js", revision);


StringBuilder scripts = new StringBuilder(@"

var headID = document.getElementsByTagName('head')[0];




newScript = document.createElement('script');

newScript.type = 'text/javascript';

newScript.src = '{0}';

headID.appendChild(newScript);", jsLink);

string scriptBlock = scripts.ToString();


var existingActions = web.UserCustomActions;



var actions = existingActions.ToArray();

foreach (var action in actions)


if (action.Description == "scenario1" &&

action.Location == "ScriptLink")







var newAction = existingActions.Add();

newAction.Description = "scenario1";

newAction.Location = "ScriptLink";


newAction.ScriptBlock = scriptBlock;


ctx.Load(web, s => s.UserCustomActions);




This is where things start to get interesting. Take note of the fact that the above code is CSOM in a Provider Hosted App – this is a very important point we will be returning to shortly. For the moment, bear in mind that any script inserted programmatically must also be removed programmatically. The following code will reverse the insertion action by removing the script from the UserCustomActions collection:

public void DeleteJsLink(ClientContext ctx, Web web)


var existingActions = web.UserCustomActions;



var actions = existingActions.ToArray();

foreach (var action in actions)


if (action.Description == "scenario1" &&

action.Location == "ScriptLink")









It is now time to discuss the "big gotcha" I referenced at the beginning. It stands to reason that if code is injected when an app is added to a site then that same code should be removed when the app is removed. This is an essential element in maintaining a healthy relationship between the developer and the site administrator. If the code is not removed gracefully then it will become orphaned with no way to remove it other than via more code. So the developer must take into account how the functionality they introduced will be retracted when it is no longer required or must be replaced by newer code. There is a very easy way to make sure this happens without requiring any additional effort – use a declarative element to insert the custom action instead of doing it programmatically. The functionality certainly exists within the app model – that's how Ribbon customizations are performed. Here is an example of how to achieve the same result using a CustomAction element within an App project:


<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">




    Sequence="100" />



Easy, isn't it? The best part is that declarative elements are automatically removed when the app is removed – no need for code to handle the removal process. So the obvious answer is to deploy a declarative instead of a programmatic custom action, right?

Not so fast.

Try doing this via an App and you will get – nothing. No errors, no deployment failure, no feedback whatsoever. The script is simply never added to the page. This is due to the fact that the parser specifically blocks SharePoint Apps from deploying declarative custom actions containing the "ScriptLink" value for the Location element. So the built-in mechanism for automatically handling the retraction of deployed artifacts is intentionally blocked in an App scenario.

Great. So what now?

Well, if the App in question is a Provider Hosted App, then - in theory - a remote event receiver could be used to call a method that is responsible for deleting the CustomAction element from the host web user actions collection when the app is removed. A remote event receiver is simply a WCF service with an endpoint the App can call in response to an AppInstalled or AppUninstalling event (an example of remote event receivers can be found in the Core.EventReceiversBasedModifications sample). Assuming the service can establish context with the host web and execute the requisite CSOM code then we would have an automated method for script retraction. But wait – is this really a viable solution? Be sure to read the "Dealing with Uninstall" section of the ReadMe page in the sample. It clearly points out that removing an app from the Site Contents page may not fire the AppUninstalling event or may do so with inadequate permissions. So there is no guarantee that a remote event receiver will solve the retraction problem.

Unfortunately, the story only gets worse from here. If the App in question is SharePoint Hosted then there are no options for automatic removal of injected scripts. None. The developer must provide a manual removal method and hope that the site administrator remembers to use it BEFORE removing the app. You read that right – any CustomActions created programmatically in a SharePoint Hosted App cannot be removed except by explicit execution of code. With no ability to add interaction to the app tile in Site Contents there is absolutely no way to notify the user removing an app that additional steps must be taken for graceful removal. The deployed code will remain resident in the master page until additional code is run to remove it.

SharePoint Hosted Apps have many advantages – they are easy to deploy, require no infrastructure on the part of the developer, eliminate the need to write code for establishing and managing context, automatically get provisioned in an app web, and have an integrated navigation experience. The second point is perhaps the most important – developers don't need to stand up a separate web site just to deploy their app. Sure, spinning up web sites in cloud services is easy and relatively cheap, but it still costs money, especially if a lot of people are hitting it, and not every developer has access to Azure, AWS or Google. As anyone who has ever worked on Enterprise development team can attest it is extremely difficult to get even a simple web site provisioned. Not to mention the hassle and headache of getting S2S trusts set up in on-premise scenarios or opening ports in the firewall for inbound connections for mobile/remote users. SharePoint Hosted Apps are a perfect solution in these scenarios yet they cannot be used for JavaScript injection because there is no mechanism for code retraction.

So where does this leave us in attempting to manage script injection in a responsible manner? Nowhere good, I'm afraid. Declarative actions cannot be used at all because their deployment is blocked. Provider Hosted Apps have an event automation mechanism but it is limited and unreliable. SharePoint Hosted apps have no automation options at all, instead requiring manual code execution without the ability to notify the user. Not to mention the fact that deploying custom actions in both SharePoint and Provider Hosted Apps requires Full Control permissions – a requirement not likely to get past Information Security and explicitly disallowed in apps published to the Office Store. And yet, despite the complete inability to effectively manage the deployment and retraction process, the script injection method via the app model is THE method being promoted by Microsoft for UI customizations in SharePoint 2013 and especially SharePoint Online.

Lest you suffer from the false impression that this is only a customization problem, allow me to correct that misconception. What about developers who rely upon script libraries like jQuery and its multitude of plugins to be present on every page in a site? How about custom style sheets, font libraries, navigation menus, and legal disclaimers? What happens if, for example, you need to invoke a full-page lightbox overlay from an app part? Or pass parameters from an app web page to a host web page via the postMessage API? All of these require script injection and the more of them you have the more orphaned code there will be lurking in the markup of every page.

Is that a big enough "gotcha" to get your attention? I sure hope so. Because if you follow the advice and samples currently being published you will eventually end up with orphaned code in your site(s).

And now for the coup de grâce.

At present, the only viable solution for elegantly managing script injection in all scenarios is…

…are you ready for it?

Sandbox Solutions.

Only script injection performed via a declarative sandbox solution is guaranteed to a) get past the parser in both on-premise and online scenarios, and b) get removed when the solution is deactivated. How is that for coming full circle? The very model for code isolation that was hyped in 2010, then quickly set aside to be replaced by the even more hyped up Cloud App Model in 2013, is the only solution that fully supports the "new" injection method. Of course, Sandbox Solutions come with their own raft of limitations and are considered to be "deprecated" so their use is no longer encouraged. But if you must inject JavaScript into pages in SharePoint then the sandbox is the only safe and reliable method for doing so.

Welcome to the new model. Same as the old model. Only it's new! And in the cloud!!!

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 

SmartTrack Operational Analytics for SharePoint​​ 











December 12
SharePoint Saturday DFW 2015

​It's back! SharePoint Saturday 2015 will be held at the Microsoft campus in Las Colinas on March 7th. As always, the event is free for attendees and we will have a full roster of deep-dive sessions from MVP's, Microsoft personnel, community members and other subject matter experts. It will be full day of education education and networking covering a wide range of SharePoint and Office 365 topics. Reserve the date now and don't miss out!

For more information, visit the official SharePoint Saturday DFW site at http://www.spsevents.org/city/DFW/DFW2015/home​​

See you there!

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 
SmartTrack Operational Analytics for SharePoint​​
December 03
Access Denied Errors Activating Publishing Features in a SharePoint Team Site

Access Denied SharePoint Cowboy eshupps Eric Alan Shupps BinaryWaveMany organizations have a governance policy in which certain individuals are granted Full Control permissions of individual sites, usually after completing some training or demonstrating proficiency in site administration skills. In such a scenario, it is quite common for a number of different users to be site owners throughout a wide or deep site hierarchy without having any permissions beyond the sites the administer or to the parent site collection(s); in fact, they may not be any more than a common Visitor in the root site collection even though they are in the Owners group of their own site(s).

While this is an effective strategy for delegating site administration and support duties to non-IT personnel it can sometimes lead to unexpected permissions issues. Case in point: activating the SharePoint Server Publishing feature on a site. This feature, which provisions the various artifacts required for publishing and enables various publishing-related settings, is dependent upon a site collection scoped feature called "SharePoint Server Publishing Infrastructure".  Site owners without administrative site collection permissions must first request activation of the dependent feature by the site collection owner before attempting to activate the publishing feature on their own site. In theory, this should be sufficient but unfortunately, activiation of the dependent feature is not enough to enable publishing on a child site - the site owner must also have a minimum set of permissions on at the site collection level.  

If you have ever encountered this situation, then you have likely recieved the standard "Sorry, you don't have access to this page" screen when attempting to activate the publishing feature. This error can be misleading, as attempting to activate a feature doesn't have anything to do with trying to navigate to a page, but the underlying cause is the same - a System.UnauthorizedAccessException error is being thrown and the custom errors mode parser always redirects to the /_layouts/15/AccessDenied.aspx page if the "Allow access requests" option is checked under Access Requests Settings. The ULS log entry for this would look something like the following:

Event log message was: 'Failed to initialize some site properties for Web

 at Url: 'http://portal/sites/test/newsite''. Exception was: 'System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    

 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)    

 at Microsoft.SharePoint.Library.SPRequest.SetWebMetainfo(String bstrUrl, Object varMetainfo)    

 at Microsoft.SharePoint.SPWeb.Update()    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.SaveNoMobileMappingsInfoToRootWeb(SPSite site, SPWeb currentWeb, Boolean mappingsFileExists, Boolean hasNoMobileMappings)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.<>c__DisplayClassc.<UpdateFile>b__a(SPSite elevatedSite)    

 at Microsoft.SharePoint.Publishing.CommonUtilities.<>c__DisplayClass1.<RunWithElevatedSite>b__0()    

 at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3()    

 at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)    

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)    

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.UpdateFile(Dictionary`2 mappingsToBeSaved)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.Update(Dictionary`2 mappingsToBeUpdated, Boolean forceOverwrite)    

 at Microsoft.SharePoint.Publishing.CustomMasterUrlProperty.SetDirectChannelSpecificValue(SPWeb web)    

 at Microsoft.SharePoint.Publishing.CustomMasterUrlProperty.SetDirectValue(String value, SPWeb web)    

 at Microsoft.SharePoint.Publishing.InheritableProperty`1.SetInherit(Boolean inherit, Boolean forceAllSubWebInherit, String successUrl, String failureUrl, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.InheritableProperty`1.SetInherit(Boolean inherit, Boolean forceAllSubWebInherit, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.Internal.AreaProvisioner.SetMasterPageProperties(PublishingWeb area, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.Internal.AreaProvisioner.SetLayoutRelatedProperties(PublishingWeb area, Boolean& updateRequired)  

There are numerous posts on the Internet which indicate that the solution to this problem is to give the user attempting to activate the feature at least "Read" permissions to the "DeviceChannels" list in the parent site collection. This is due to the fact that DeviceChannels, along with several of the other publishing-related lists such as "PublishedLinks" and "ReusableContent", have permission inheritance broken when they are created and the user in question won't have the ability to even read these lists. While activiation of the site-level publishing feature does, in fact, read from the DeviceChannels list, applying permissions only to this list may be insufficient. Testing on 2010 RTM/SP1/SP2 and 2013 RTM has shown that the site owner must also have "Member" rights plus the following site permissions on the root site collection in order to activate the publishing feature:

  • Add and Customize Pages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Microsoft SharePoint Foundation-compatible editor. 
  • Apply Themes and Borders - Apply a theme or borders to the entire Web site. 
  • Apply Style Sheets - Apply a style sheet (.CSS file) to the Web site. 

Esssentially, this is the same permission set as the "Designer" role with a few exceptions, such as "Use Self-Service Site Creation", "Browse User Information", etc.  If assigning site owners full Design permissions is considered too permissive for your environment, you can create a custom permission level and group, then assign site owners to that group. Unfortunately, this means the site owners will also have rights to modify styles, master pages, and so on at the site collection root, which will probably not comply with the governance policy in most organizations. Other alternatives are to handle feature activiation via a PowerShell script or custom code. Alternatively, the site collection administrator could create a site template that already has the SharePoint Server Publishing feature activated and use that template for the creation of subsites as the design permissions are only required when activating the feature not for using the publishing components after it has been activated. Temporary assignment of these permission is also a potential workaround but it requires active participation by the site collection administrator. If you are using an advanced workflow solution like Nintex or K2 you might also be able to automate the process using an app step or elevated permissions within a workflow.

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 
SmartTrack Operational Analytics for SharePoint​
November 14
New Podcast: SharePoint Search on RunAs Radio
It's strange how things in your career come together over time. Way back in 2008 I was attending TechEd in Orlando, Florida (as documented here). We had a booth the first week to lauch our Sonar product (which eventually became part of SharePoint Diagnostic Manager​) and I was lurking about the Office kiosks the second week answering SharePoint development questions when I got roped into something called Speaker Idol. It was a fun little competition in which speakers are given five minutes to do a presentation to a panel of judges and a small audience. The winner of each heat went on to the finals with the prize being a speaking slot at the next TechEd. By pure luck I managed to win the competition and along the way met some really great people - the irrepressible Rachel Appel, the eloquent Alan Stevens, and the brilliant Amanda Leigh, to name just a few. But perhaps the best connections to come out of that event were with Richard Campbell and Carl Franklin, a dynamic duo who have brought us such great technical community resources as .NET Rocks, RunAs Radio, and The Tablet Show, not to mention speaking, producing, traveling cross-country on insane road trips and, oh yeah, making some killer music.   

Richard and I have gotten together a few times over the years, both virtually and in person, to chat about various techincal topics - usually SharePoint - and I'm always amazed how much he knows about the technology industry in general and especially about our little corner of it. You would think his mind is already overflowing with general tech-related buzz but somehow he keeps his finger on the pulse of the SharePoint world as well. I really don't think he sleeps. Like, ever. I had another opportunity to chat with Richard recently on the topic of SharePoint search (and SharePoint/Office365/Azure/Cloud stuff in general) for RunAs Radio. I always enjoy our conversations and we never seem to have enough time to talk about everything on our minds. In any event, have a listen if you are so inclined and be sure to check out all the other things Richard is involved in.  It's quality stuff!  

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 
SmartTrack Operational Analytics for SharePoint
October 03
New IT Unity Article: Content Query Versus Content Search in SharePoint 2013 and Office 365
One of the most common requirements in any SharePoint environment is the aggregation and summarization of content across lists, libraries, sites and site collections. Administrators could not easily achieve these requirements without custom code until the introduction of the Content Query Web Part (CQWP) in SharePoint 2007/2010. The CQWP gave administrators a useful out-of-the-box method for collecting data from various lists into a consolidated view. Even better, it could aggregate data from different sites – something the built-in List View Web Parts could never do. But, the CQWP certainly has its limitations – the number of sites it can query is limited, modifying the display requires expert XSL transformation skills, and the behind-the-scenes heavy lifting required to execute its queries can place a significant load on the infrastructure, especially when used on heavily trafficked pages...

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 
SmartTrack Operational Analytics for SharePoint
September 15
SharePointalooza Slides and Demos

This past weekend hundreds of SharePointers descended upon the wilds of Branson, Missouri for SharePointalooza. Despite being in the exact center of absolutely nothing we sill managed to have a good time, deliver some SharePoint knowledge, and listen to some great music. This was a labor of love and devotion to the community by Mark Rackley (supported by his long-suffering family) and he did an excellent job pulling everything together.

A big Texas "Thanks, y'all!" from myself and Miguel Wood to all those who attented our SharePoint 2013 High Availability workshop. Below are links to the slides and the demo script for configuring WSFC and SQL AlwaysOn Availability Groups.

Slides: A Real World Guide to Building Highly Available Fault Tolerant SharePoint Farms 

Demo: Configuring Windows Server Failover Clustering and SQL 2014 AlwaysOn Availability Groups


P.S. - A special shout-out to Eric Harlan and Naomi Moneypenny for acting as co-pilots on our epic road trip to the Middle of Nowhere. They never panicked as they were drug through the backwoods of Oklahoma and Arkansas. They even managed to stay awake through all my stories which is an epic feat of endurance. Good times with good friends makes it all worthwhile.


Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with
SmartTrack Operational Analytics for SharePoint

1 - 10Next

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave 
Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave 

Twitter Counter for @eshupps 

Eric Shupps LinkedIn Eric Shupps Twitter Eric Shupps Facebook Eric Shupps Google+


BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence

Copyright © 2013 BinaryWave, Inc. All rights reserved.
This site is brought to you by BinaryWave in cooperation with Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy. We hope you enjoy the SharePoint-related content on topics such as performance, monitoring, administration, operations, support, business intelligence and more for SharePoint 2010, SharePoint 2013 and Office 365 created by Eric Shupps The SharePoint Cowboy. We also hope you will visit our product pages to learn more about SmartTrack, Operational Analytics for SharePoint, SharePoint monitoring, and SharePoint administration, while also discovering great offers from our partners. Please visit the blog of Eric Alan Shupps, Twitter handle @eshupps, for more information on application development, the SharePoint community, SharePoint performance, and general technology topics. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational support solutions for SharePoint. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. He is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.binarywave.com/blogs/eshupps.