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
BinaryWave
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
May 05
New Article - The SharePoint Customization Conundrum

My latest article for SPTechReport is now online:

"Back in the early days of mass SharePoint adoption (circa 2008), the most popular request from customers was to make their shiny new intranet “not look like SharePoint.” It was a reasonable request; after all, the product was created to simplify online collaboration and document management, not to be an internal marketing platform, so the user interface naturally reflected a utilitarian design aesthetic that many found less than appealing. Of course, that didn’t stop customers from taking the platform in all sorts of directions it was never meant to go, the result of which was a proliferation of highly-customized implementations that required a great deal of time, money and custom code to deliver..."

Read the full article on SPTechReport >>​


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​​ 


May 04
Introducing the SharePoint Framework
Today Microsoft officially announced an exciting new set of technologies known as the "SharePoint Framework". Developers everywhere should be excited about this announcement as it means we (finally!) have a proper modern web development experience for SharePoint publishing both on-premises and in the cloud. To learn more about what the SharePoint Framework is and how it functions, have a look at the overview video and read this blog post​ from the SharePoint team.

At this point, things are still in motion and there is no official release date other than "sometime later this year" but there are already a number of things to get really excited about if you are a SharePoint developer. Here are my top five in no particular order:

1. Modern Web Development Experience. We can finally move out of the dark ages of classic server-side ASP.NET development for native customizations. No more WSP's and endless IISRESET operations. We don't even need a SharePoint server to preview our customizations as the new SharePoint Workbench utility provides a sandbox test environment right on our desktop. Everything - and I do mean everything - is HTML and JavaScript based, leveraging the remote API's for platform integration and a whole new set of extensibility components for things like data management, caching and authorization. Even better, it's all open source so developers can use any JavaScript framework they like for deep, natively-supported customizations. 

2. Everything Old is New Again. Unlike Add-Ins and Azure Apps, which are designed to run outside of the pages and parts users normally interact with, the SharePoint Framework has been built from the ground up as a proper publishing platform for in-context customizations. Developers will still be working with pages and web parts, only they'll be doing it in client-side code that is responsive and mobile out of the box. There may be a bit of a learning curve for classic ASP.NET developers but the underlying artifacts are still very similar - build a web part, add it to a page, display data via the API's. This should be much easier to grasp for the average SharePoint developer than things like provider-hosted add-ins and standalone web apps. The knowledge delta is more about tools than it is about components and that's a good thing. Concerned about learning all this JavaScript stuff? Don't be - there will be plenty of guidance to get you up to speed. Heck, the SharePoint team themselves had to learn it in order to to build the new site experience - if they can do it then so can you.

3. First Class Customizations. In the add-in model customizations were an afterthought at best, with poorly implemented integration points and barely functional shims. The SharePoint Framework was expressly designed to solve these challenges by making client-side code a first-class citizen within the rendering framework. This isn't just a bolt-on it's the core technology underlying many of the new UI experiences. Developers will be building customizations in exactly the same way the SharePoint team themselves are building them. It doesn't get any more "supported" than that!

4. Microsoft Gets It. No, I'm not trying to be funny - they really do get it. Developers want to use modern frameworks like Angular, Reach, Knockout and so on. They don't want to spin up full server virtual machines just to create a quick web part. The web has moved on from the old server-side days and it's high time we caught up with what everyone else is doing. Nobody feels that pain more than the engineering team that has to build and maintain all that heavyweight legacy code in the first place. Internally, Microsoft is embracing the modern web and the greater SharePoint development community is the primary beneficiary of that change. And it's only going to get better from here on out.

5. Customizations are Cool (Again). Remember way back in the day when the "in" thing was to make SharePoint not look like SharePoint? (Ok, so it wasn't actually way back in the day - everyone still wants that)  Well, here we are in 2016 and all of a sudden deep customizations are back in vogue. With the SharePoint Framework, developers and designers can work together to build a completely customized intranet from the ground up with exactly the look and feel they want and have it run on-premises or in the cloud. Fully supported. No more fighting with the complexities of the SharePoint page structure, battling interdependent server controls or wading through mountains of conflicting CSS, either - mock it up, code it, style it and go. And you don't even have to know all the aracane inner workings of SharePoint to make it functional. Now that's cool! 


So there are my top five things to like about the new SharePoint Framework. No doubt there will be a ton of questions about the particulars as this gets rolled out to first release tenants later this year. But for now I think we can all be thankful that Microsoft has heard our concerns and given us an exciting new platform to build some really cool stuff on top of SharePoint. 


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

​​​​​​

April 22
Configuration Challenges with Office Web Applications, SSL Offloading and Default Zone URL's

Configuring Office Web Applications in a development or test environment is a pretty straightforward process: install the server bits, run a bit of PowerShell to create a WAC farm, set your WOPI bindings in SharePoint, and you're done. But doing so in a full production environment, with high availability, SSL offloading, split DNS, HTTPS redirection, fully-qualified AAM's and multiple web application zones? That's an entirely different ball game.

Consider the following real-world scenario. The SharePoint farm, which has been built following high-availability guidelines for redundancy, has both internal web servers for employees and external web servers for customers. The customer servers are in a DMZ behind a dedicated load balancer, with their own Virtual IP's, but they still have to be reached by internal employees and connect to the rest of the SharePoint farm, so they use a split-DNS scheme to provide name resolution internally and externally. The web applications were created on HTTP, with the appropriate alternate access mappings, as the SSL certificates reside on the load balancer, where any incoming requests from the outside network get automatically redirected to HTTPS but are passed to the servers as standard HTTP.


Office Web Apps Farm in DMZ with SharePoint 2013/2016

In this configuration, internal employees can browse to http://extranet.contoso.com without the need to manage certificates on the servers themselves and without ever transiting the corporate firewall. External users who forget to type "https" before hitting the extranet site get conveniently redirected to a secure connection on a load-balanced IP address and the web server traffic is isolated from the rest of the farm. So far, so good. But what about giving customers and partners the same online document viewing/editing experience as internal users? Wouldn't it be great if they could also take advantage of the Office Web Applications functionality in SharePoint? Yes, it would - but getting it to work properly is going to take a bit more planning than usual.

The first challenge is determining where the WAC servers should reside. For security and traffic isolation purposes it is best to co-locate the WAC farm with the SharePoint servers in the DMZ. Placing them on the internal network will result in direct client connections to internal resources when users open documents in Word/Excel/PowerPoint online; a situation which should be avoided and which would likely fail a security audit. It's one thing for web servers to communicate to the back end via their own connections but quite another when external users are hitting URLs from an outside network that should otherwise be off-limits.

There are, however, some significant ramifications to what is otherwise a clear choice. Since there is a one-to-many relationship between WAC farms and SharePoint farms, it means that the WAC farm must either be located entirely in the external zone or have at least two servers in the internal zone and two in the external zone (for minimal redundancy). Spanning the zones requires virtual IP's on both the internal and external load balancers along with corresponding DNS entries in both zones. Configuring the WAC farm will also require some creative DNS configuration and port rules, as the servers have to be aware of each other and be able to communicate on port 809 (if you are using the standard configuration of HTTP on 809 and HTTPS on 810). Alternatively, the entire WAC farm can reside externally and internal users would simply get flipped over to HTTPS when they try to open documents in the browser.

Configuration user connectivity to the WAC servers is actually quite simple; however, getting the WAC servers to talk to SharePoint is not quite so easy. When WAC receives a client request for a document, it attempts to load the document from the SharePoint site the user was browsing when they made the initial request. If the user is external, that means the request will go from https://extranet.contoso.com to https://wac.contoso.com with the load balancer handling the SSL portion of the communication and passing it to WAC as a standard HTTP request. This means the WAC farm must have been created using the "SSLOffloaded" switch, the WOPI zone set to "External-HTTPS" (so it creates both internal and external bindings), and the WOPI binding configured with the "AllowHTTP" options. WAC then has all the proper settings to make the request to SharePoint for the desired document.

Or does it?

This is where things start to get very interesting. The way WAC functions, it will only make a request to SharePoint on the URL for the web application's default zone. With SSL offloaded at the load balancer, this is usually an HTTP endpoint - in this case, http://extranet.contoso.com. But when the WAC servers in the external zone try to reach this URL, they will receive an IP resolution from the external DNS server that points to the external VIP on the load balancer which, when it receives such a request, automatically flips the "http" to "https". Since WAC doesn't know what to make of a redirect happening in the middle of an attempt to retrieve a SharePoint document the request will fail and the user will receive the dreaded "Sorry, there was a problem and we can't open this document" error. Adam Rhinesmith, who is a support escalation engineer on the Microsoft Office Web Client and Services team, pointed this out on a blog post back from 2014 but the ramifications of what he was saying aren't immediately apparent until you come across this general scenario.

So how can we allow both internal and external users to load documents in WAC and still maintain some level of traffic isolation? One option is to by pass the load balancers by pointing the WAC servers to internal SharePoint servers which will respond to the HTTP request using host entries on each WAC machine. Similarly, another web server could be added to the farm in the DMZ but not to the load balancer virtual IP configuration, which would make it reachable only by the WAC servers over HTTP (again, using host entries). But managing host entries, especially in the case of Host Named Site Collections, on each WAC server can be tedious and prone to error. Another option is to point the WAC severs to the internal DNS or have a separate DNS server in the DMZ with internal entries, so that the WAC requests are never routed to the external servers at all. Since WAC only needs to talk to SharePoint and the other WAC servers this is a approach that scales much easier in the context of Host Named Site Collections. In my opinion, the preferred approach is a combination of these two options, with a dedicated SharePoint web server in the DMZ that does not participate in the load balancing pool (the only function of which is to serve WAC requests) and a separate DNS server for name resolution of the WAC farm servers and HNSC hosts. In this configuration, the only WAC-related traffic that crosses from the external to the internal zone is WAC farm communication over port 809 which is, IMHO, an acceptable compromise. One final option, if you have the hardware to support it, is to create a rule on the load balancer not to translate HTTP traffic to HTTPS if it originates from the WAC servers.

NOTE: It is worth pointing out - in fact, SHOULD be pointed out - that if the entire farm were configured for HTTPS as it should be then this situation wouldn't arise at all, along with saving many other headaches and making the overall farm more secure. Bear that in mind before trying to avoid HTTPS due to minimal cost increases or supposed ease of configuration.

So the moral of this story is to carefully consider the configuration of your WAC farm when setting up SharePoint servers in a DMZ where SSL traffic is terminated at a load balancer. If external users cannot open documents in WAC but internal users can then you are very likely running up against the default URL zone HTTP/HTTPS issue. There may be other creative ways to overcome this limitation besides those I've covered above but however you do there needs to be a way for the WAC servers to communicate with the SharePoint servers using the URL and protocol associated with the web application default zone. Otherwise, external users will be forced to use desktop clients to open documents. Surely with all the goodness in Office Web Applications nobody wants that, do they?

​​



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

​​​​​

March 28
Announcing a New Version of SmartTrack - Operational Analytics for SharePoint

As many of my readers know, BinaryWave​ is primarily in the business of creating and supporting software products for the SharePoint market. Some we do just for fun, some we build for partners and some ​we sell under our own brand. In the latter category, we are especially fond of our industry-leading SmartTrack product - the only operational analytics solution built specifically for SharePoint. 

Over the last few of years we have learned quite a bit about the struggles of maintaining a mission-critical SharePoint environment within the enterprise. One of the most common complaints we hear is the lack of visibility into operational metrics. Even when we expose the mountains of data hiding within the ULS logs and make it easy to visualize, filter and process, there is still a big disconnect between what is happening on the user's desktop and what goes on behind the scenes within a server farm. Although SharePoint is really good (too good, in some cases) at filling up log files with mountains of data, it doesn't tell operational personnel much at all when it comes to the user experience. When an unexpected error occurs and gets flagged in a SmartTrack alert, administrators still have no idea how many people were affected, how the error manifested itself on the front end, or what level of interruption it caused.

We figured there had to be a way to bridge this gap so we set about finding a solution. The obvious answer was to parse the IIS traffic logs and extract the data into a more usable format. But that information alone, which is readily available from a multitude of commercial and open source tools, isn't sufficient. It has to be viewed in context with operational data from the server itself and the entire SharePoint stack. It's no good knowing a user received a 404 error without also knowing what SharePoint was doing at that precise moment which might have contributed to the problem. Plus, administrators need to know how often such errors happen and what overall effect they have on farm health metics. All those uptime tools are nice but downward red arrows on a dashboard don't actually help sysops track down the root cause of a problem.

So rather than offer another "me too" IIS log parsing utility, we decided instead to treat client requests as first-class data within the overall farm event stream. After all, shouldn't a 500 Internal Server Error be of equal cause for concern as a "System.NullReferenceException" in a publishing page? And, even better, wouldn't it be helpful to know if the two events occurred at the same time on the same server just after the average SQL query execution counter spikes upwards? Now that's the kind of information that can actually help you keep SharePoint running and prevent excessive downtime.  

After a few months spent solving this particular problem, and a some others we discovered along the way, I'm pleased to announce the general availability of SmartTrack version 1.5. Now, for the first time, on-premise SharePoint customers can easily trace errors from the desktop to the database with just a few clicks. SharePoint ULS logs, Windows Server event logs, performance counters and now IIS logs in one single, integrated event stream. No big monitoring frameworks to install, management packs to configure or rules to write - SmartTrack starts working immediately and its advanced health algorithms automatically learn farm behavior patterns without user intervention. All in an easy-to-use cloud-based application that looks great on any sized device (for those who can't yet leverage the cloud, don't worry - there's a fully on-premise version just for you). SmartTrack is the only operational analytics solution designed from the ground up for SharePoint administrators, system operations personnel and managed service providers.

Here are some highlights from the new version:

  • IIS log event capture across all web servers in a farm. 
  • New “servers at a glance” display in the SmartTrack dashboard that summarizes the operational health of servers in each farm right on the main page. 
  • New “Web” category for sorting, filtering and searching IIS log events in the details panel.
  • Improved event categorization and alerting.
  • For on-premise customers, an all-new management service that automates database maintenance operations to ensure optimal performance.
  • Dedicated mail server that eliminates the need for Exchange relay setup and outdated Windows Server SMTP configuration.
  • Improved event exclusion processing.
  • Enhanced user creation for secure on-premise farms that are not connected to the public internet.
  • Numerous bug fixes and performance enhancements.


Interested? Visit the SmartTrack product page​ and request a free trial. When you're ready to buy, request a quote using offer code "SPCOWBOY" for a 20% discount. Get your SharePoint environment under control and save money at the same time - can't beat that!




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

​​​​​

January 29
Document Sharing with the REST API in a SharePoint Add-In

Office 365 makes sharing documents with other users extremely easy - just select the item, click ’Share’ and enter an e-mail address or pick a user from the directory - job done. Unfortunately, replicating this behavior in code is not quite so simple. Vesa Juvonen has demonstrated an approach to this using CSOM and there is an associated sample in the Office Dev PnP repo on Github. But what if you need to do this with only HTML and JavaScript, say in a SharePoint Hosted Add-In or mobile application?

Fortunately, there is a REST​ endpoint for this but it is not well documented and the internal workings are a bit obscure. To begin with, you need to send a properly formatted JSON object to the proper REST endpoint in the app web. Unlike most other calls that use the app web as a proxy for resources contained in the host web, calls to the sharing endpoint do not require a parameter for the target (host) web nor does it follow the standard convention of specifying the “/web/“ path in the request URL after “/_api/“. Much like calls to the user profile service or search, this endpoint is directly accessible, which is a big reason why figuring out how to use it is difficult; standardization of RESTful endpoints and related documentation outside of the unified O365 API’s seems to be lagging behind.

In any event, constructing the URL is quite simple compared to other REST calls that require the host web token:

   var reqUrl = appWebUrl + "/_api/SP.Web.ShareObject”;

The above example assumes that your code uses the commonly documented methods for extracting the app web URL from the request parameters (for more information on how to do this, see here). However, knowing the endpoint is only half the battle. The other challenge is figuring out how to properly format the JSON data object that will be POSTed to the specified endpoint. This object has the following parameters:

   url: The full URL of the document to be shared.
   peoplePickerInput: A JSON object containing required user key/value pairs (more on this below)
   roleValue: An numerical value that specifies the desired sharing option (view or edit)
   groupId: An integer which specifies the site group the user should be assigned to.
   propagateAcl: A flag to determine if permissions should be pushed to items with unique permissions.
   sendEmail: A boolean value (‘true’ or ‘false’) used by the system to determine if the target user should be notified of the sharing operation via email.
   includeAnonymousLinkInEmail: A boolean value (‘true’ or ‘false’) which tells the system whether or not to include a link to the document that is reachable by all anonymous users.
   emailSubject: The subject of the notification email.
   emailBody: The body of the notification email.

(The full set of parameters and explanations is described in the following MSDN reference article: https://msdn.microsoft.com/EN-US/library/office/microsoft.sharepoint.client.web.shareobject.aspx)

Of these, the trickiest one to construct is the peoplePickerInputValue. As it is a full JSON object contained within another JSON object, the formatting can be a bit tricky. The entire set of key/value pairs must be contained within square brackets and curly braces and all double quotes escaped and the entire thing assigned to a variable using something like JSON.stringify(). Within the object itself, you must specify such parameters as the full user identifier (claims ID or email address), the type of entity the object represents, the target user’s FQDN, and so forth. When fully defined, the object will look similar to this:

[{\”Key\":\"i:0#.f|membership|user@somedomain.com\",
\"Description\”:\”user@somedomain.com\”,
\”DisplayText\”:\”Test User\”,
\”EntityType\":\"User\",
\"ProviderDisplayName\":\"Tenant\",
\"ProviderName\":\"Tenant\",
\"IsResolved\":true,
\"EntityData\":{\"Title\":\"\",
\"MobilePhone\":\"+1 1234567890\”,
\”Department\":\"\",
\"Email\”:\”user@somedomain\”},
\”MultipleMatches\":[],
\"AutoFillKey\":\"i:0#.f|membership|user@somedomain.com\”,
\”AutoFillDisplayText\”:\”Test User\”,
\”AutoFillSubDisplayText\":\"\",
\"AutoFillTitleText\”:\”user@somedomain.com
\\nTenant\\nuser@somedomain.com\”,
\”DomainText\”:\”somecompany.sharepoint.com\",
\"Resolved\":true,
\"LocalSearchTerm\”:\”user@somedomain.com\”}]

Building this object can be quite challenging, especially if you do not know or cannot get access to all the required information. Fortunately, there is an endpoint you can call from your add-in that returns a properly formatted object you can use in your call to the sharing service. This endpoint resides at the following url:

    http://<AppWeb>/_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.
  clientPeoplePickerResolveUser

To make use of it, you will need to pass in an object that includes a set of query parameters, like so:

var restData = JSON.stringify({

   'queryParams': {

      '__metadata': {

         'type': 'SP.UI.ApplicationPages.ClientPeoplePickerQueryParameters'

      },

      'AllowEmailAddresses': true,

      'AllowMultipleEntities': false,

      'AllUrlZones': false,

      'MaximumEntitySuggestions': 50,

      'PrincipalSource': 15,

      'PrincipalType': 1,

      'QueryString': userId

   }

});

Take note of the “userId” variable - this is the claims identifier or email address of the person the document is being shared with (if the user is not in your Azure AD domain be sure to first enable external sharing in your tenant). POSTing this data to the clientPeoplePickerResolveUser endpoint will return a user object, which can be parsed to obtain the ClientPeoplePickerResolveUser value. This value can then be assigned to the peoplePickerInput parameter.

The entire package then gets POSTed to the app web via the Request Executor. Remember to assign the appropriate value collection to the header value, which includes the “accept”, “content-type” and “X-RequestDigest” parameters. The user interface can then be updated if desired based on the success or failure handlers of the executor. To verify that the sharing operation worked, open the sharing dialog for the document and the user’s ID or email address should be displayed. Below is a full example of a simplified JavaScript function for sharing a specific document (which can also be found in SPRest.Demo repo on GitHub). It requires two inputs, the user email address and the URL of the document, and updates a DIV element on the page with a success or fail message via jQuery.

function shareDocument() {

    try {

        var userId = $("inputEmail").val();

        var docUrl = $('#inputFileUrl').val();

        var executor = new SP.RequestExecutor(appWebUrl);

        var restSource = appWebUrl + "/_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerResolveUser";

        var restData = JSON.stringify({

            'queryParams': {

                '__metadata': {

                    'type': 'SP.UI.ApplicationPages.ClientPeoplePickerQueryParameters'

                },

                'AllowEmailAddresses': true,

                'AllowMultipleEntities': false,

                'AllUrlZones': false,

                'MaximumEntitySuggestions': 50,

                'PrincipalSource': 15,

                'PrincipalType': 1,

                'QueryString': userId

            }

        });

        executor.executeAsync({

            url: restSource,

            method: "POST",

            headers: {

                "accept": "application/json;odata=verbose",

                "content-type": "application/json;odata=verbose",

                "X-RequestDigest": $("#__REQUESTDIGEST").val(),

            },

            body: restData,

            success: function (data) {

                var body = JSON.parse(data.body);

                var results = body.d.ClientPeoplePickerResolveUser;

                if (results.length > 0) {

                    var reqUrl = appWebUrl + "/_api/SP.Web.ShareObject";

                    var executor = new SP.RequestExecutor(appWebUrl);

                    var data = JSON.stringify({

                        "url": docUrl,

                        "peoplePickerInput": '[' + results + ']',

                        "roleValue": "1073741827",

                        "groupId": 0,

                        "propagateAcl": false,

                        "sendEmail": true,

                        "includeAnonymousLinkInEmail": true,

                        "emailSubject": "Sharing Test",

                        "emailBody": "This is a Sharing Test."

                    });


                    executor.executeAsync({

                        url: reqUrl,

                        method: "POST",

                        headers: {

                            "accept": "application/json;odata=verbose",

                            "content-type": "application/json;odata=verbose",

                            "X-RequestDigest": $("#__REQUESTDIGEST").val(),

                        },

                        body: data,

                        success: function (data) {

                            $("#sharingOutput").html("Sharing succeeded for '" + docUrl + "'.").css("color", "green");

                        },

                        error: function (result, code, message) {

                            $("#sharingOutput").html(message).css("color", "red");

                        }

                    });

                }


            },

            error: function (result, code, message) {

                $("#sharingOutput").html(message).css("color", "red");

            }

        });        

    } catch (err) {

        alert(err.message);

    }

}



Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack 
Take the trouble out of troubleshooting.  
Improve service levels and avoid downtime with 
​​​​
January 13
New Article - Cloud Extensibility Options: Office 365 Add-Ins or Azure Web Applications

My latest article for SPTechReport is now online:

One of the greatest strengths of the Microsoft collaboration platform, which now encompasses both SharePoint on-premises and Office 365 in the cloud, has always been its rich extensibility options. Customers who wish to enhance the platform with dynamic line-of-business solutions or organization-specific customizations have a rich set of APIs and remote interfaces to work with that provide a great deal of flexibility in designing engaging, user-centric applications. With the recent addition of Azure Web Applications, Microsoft has created yet another method for extending the cloud experience, presenting developers with a new set of application design choices...

Read the full article on SPTechReport >>​



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 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:

Content

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.

Speakers

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.

Location

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.

Cost

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​​ 


​​
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.