Microsoft’s Mixed Messaging on SharePoint 2013

Microsoft has an identity crisis with SharePoint 2013. They say one thing and does the exact opposite, only to switch sides a few minutes later.

I am, of course, talking about the development experience of SharePoint 2013. Not necessarily the hard-core stuff, but how they approach any development in general.

Before you dismiss this as a developer oriented post, however, give me a few headlines to convince you that this actually affects any SharePoint users. I’ve even included car analogies for you!

Don’t Do Custom Development!

The big shiny new toy in the SharePoint developer’s arsenal is the App model. Apparently, Apps are supposed to solve some kind of problem, although Microsoft has yet to say exactly which problem or set of problems that Apps solve.

One problem, apparently, is that people do custom development in the third tier for any minor thing that needs to be done. That, according to Microsoft, is a bad thing because, apparently again, third tier development is so damn expensive, dangerous, and unstable.

If you reading between the lines, you’ll probably realize that the problem here isn’t third tier development, but lousy third tier developers. In other words, some developers are crap, so you shouldn’t do development.

Or, some car mechanics are lousy so you shouldn’t fix your car.

This is fine, if we read deeper into Microsoft’s statements, we learn that what they are really saying is that you shouldn’t do any custom work (including modifying the design and UI) unless you know what you’re doing.

Note: I elaborated on Microsoft’s statements and what they really meant in the blog post Welcome to SharePoint 2013! (Warranty Void if Opened)

So, for the car analogy fans, you shouldn’t fix your car yourself unless you know what you’re doing. Makes sense, right? I certainly think so. Learn your trade or at least enough to not put yourself in danger.

Microsoft’s one message, though, is that they don’t think you can handle that responsibility. Developers are no told that they should default to choosing the App model because it’s safer and can’t cause as much damage. I’ll have a few things more to say about this later in this blog post.

Then, there’s the SharePoint Designer conundrum. Although there are also technical reasons, SharePoint Designer, the de-facto tool for doing SharePoint development outside Visual Studio, gets its wings clipped by the removal of the design view.

One statement I’ve seen say that the cause of the removal is that design view cannot handle HTML5. That’s funny because Microsoft contemplated removing design view from SP2010 too, long before HTML5 was generally available for SharePoint (see Paul Stork’s comment on August 2 on the infamous TechNet thread about the missing design view).

There must be another reason, and combine this action with Jeff Teper statement’s on the “Myspace problem” of SharePoint, and I strongly suspect it’s a deliberate step to prevent untrained people from causing damage.

In other words, Microsoft makes the engine less accessible for unskilled people. Much like most modern cars; you really can’t muck about unless you have the proper tools and training.

Here’s How Easy It Is to Do SharePoint Development!

Then we get the SharePoint App model and Microsoft is back to its roots with making things so easily accessible that you don’t need to know how to spell your own name before you start developing critical business solutions.

With the Napa tools, Microsoft is asking people to completely forget about tools at all. You just need a browser, how much easier can it get?

Oh, and you don’t need to learn any programming languages either, you just need to work with HTML and JavaScript, and that’s so easy, even your mom can do it. Just look at all the tutorials on making timers and manipulating the user experience with jQuery there are out there. You’ll be up and running in no time, tool and knowledge free.

Note: I still haven’t lost my knack for blowing things out of proportion to make a point.

Car analogy: you now get a programming interface for your car that you can start using without having ever driven a car or know anything about how it works. You can make your car do really cool stuff without learning anything about traffic safety, engine optimization, or why people spend decades learning development to build cars that are safe and predictable.

Instead, Microsoft feels that the real power to develop business solutions should come from the business users, who are otherwise engaged in planning quarterly budget meetings or editing papers on quantum entanglement. Those are the people who understand the problem so they should have the power to solve them.

This is also fine, except if you read the first part of this article, where they are actively discouraging anyone from solving their own problems until they know how to do it properly.

So, First It’s Bad, Now It’s Good?

Microsoft can’t seem to make up their minds on whether users should have the power to build solutions or whether it should be left up to those who do it for a living. One the one hand, they discourage modification unless you know what you’re doing and on the other hand they encourage you to build solutions as easy as you can get up in the morning.

One problem I see is the use of JavaScript as one of the main new development languages. I’m not going into a language debate here, I’ll do that another time, but JavaScript is unsuited as an introduction language for anyone. JavaScript enforces no structure and assumes that the developer knows how to best structure their code. However, for the target audience of Napa for example, these developers more likely have a cursory acquaintance with development rather than being full-time developers with the Microsoft-mandated ability to separate crap from raisins.

And it’s not that Apps are safer either. You can mess up as much with the client object models as you can with a server model, with the noted exception that if you really fuck up a client side program, you only mess up the tens of thousands of browsers that access the App rather than the one server. It’s not fewer or less important problems; there are just different problems. None of the existing problems are solved; instead, you just exchange problem set A with problem set B.

The whole security model also reeks of foulness. OAuth, while a good idea, isn’t really implemented at all, in that an App cannot ask for permissions more than once (at install time). This means that if you need something as mundane as checking whether a certain content type exists, you need far more permissions for your whole app than you really need because you can’t ask the user to grant you that access on a need-to-have basis. Nor are the permissions granular enough, by far. You end up with asking for far more permissions that you really need.

Here’s an example.

Let’s say that you write an App that let’s you play Tetris. No permissions to critical data required, right? Well, let’s say you want to save the score on the site. Because there’s no way to ask for permissions to a single list when a user asks to store their score, you need to ask for permissions for the whole site when someone adds the App, essentially signing off on a disclaimer that the app can do pretty much whatever it wants.

The consequence, I believe, will be that Apps ask by default for far more permissions than they need, and users will completely ignore the actual permission requirements because they have no real way of making the decision. It will be about as useful as the EULA; you just click I Agree without having the faintest idea about what the contents of the agreement are.

I will at some point write more about this, but these are examples of why we’re not becoming safer with Apps or with Microsoft’s new attitude, we’re just exchanging problem sets that developers (and now users) need to understand.

So, my point in this, is that Microsoft seems to want to say that they’re taking security and stability seriously, but at the same time they reduce the requirements for starting to do SharePoint development and they are introducing a model that will likely lead to users becoming dulled to the need to researching what an App actually does.

Microsoft can’t seem to make up it’s mind. Should we fix our car and modify it now that you’ve made is so easy and accessible for us or should we strive to learn how to properly maintain the engine and not modify it without properly understanding all the consequences of doing so?

.b

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

SharePoint Education – Installing and Configuring

Before the public beta of SharePoint 2013, I and others, speculated about the introduction of an entirely new component in SharePoint called SharePoint Education. In fact, I wrote two blog posts about what I found on SharePoint Education in the protocol documentation, which, frankly, wasn’t all that much.

So, when the first public beta of SharePoint 2013 hit the virtual shelves, several people rushed to find the new features, but found little if anything. Severely disappointed, some of these people asked whether I could investigate to find out what happened and where SharePoint Education is.

So, I’m here to tell you where to find it, how to install and set it up, and also, to disappoint you even further. You see, in the public beta, SharePoint Education seems very much like an incomplete feature. Microsoft has written close to nothing in public about it, and there’s no documentation on how to install or how to set it up, nor descriptions of features. Even when you get it installed, as I’ll show you how, you won’t find much to inspire motivation. At present, it is a bit dull, in fact.

I’m sure that will all change in good time before RTM, but I wanted to warn you before you start on this process.

Oh, and one more thing.

Warning: These instructions are based on SharePoint Server 2013 Beta 2, so information is bound to have changed. If you read this after the RTM release, feel free to disregard anything said in here, because it probably won’t make much sense.

So, let’s get down to installation.

Prerequisites

In this guide, I’ll help you get SharePoint Education set up. Frankly, I haven’t spent much time exploring it, so I won’t show you any of the features at all. They’re there, I just haven’t explored them. As such, this guide ends after completion of the provisioning process, but I highly encourage you to explore on your own and feel free to share any findings you make in the comments below.

You’ll be messing about with your environment so I recommend having a clean VM. By clean, I mean you’ll want to start with as empty a SharePoint configuration that you can get, including having no web applications beyond Central Administration. There are some peculiarities in how the installation requires your web application to be set up, so if you’ve already configured a web application, you might as well remove it and start from scratch.

The features added are available as part of SharePoint Server 2013 only, so you need that. At this point, nothing is known about licensing of any sort, so it is unclear whether SharePoint Education will be part of the Server license or available only with an add-on, but at least the bits are present.

Oh, and before embarking, you should be comfortable with PowerShell and you should be able to set up and configure the User Profile Service, including setting up the MySite host. Google it if you don’t know how.

Installation

You should start by creating a completely new web application. Use the default configuration if you want, or set it up as you please.

The PowerShell command you need to run to set up SharePoint Education is:

PS C:\Users\Administrator> Install-SPEduSites -WebApplication [your web app] -OwnerAlias [your owner user name]

You need to replace [your web app] with, well, your web application, including http://, and [your owner user name] with a user name that will be the owner of the various sites created for you during the installation. In my case, I’m using http://splab.sp.local:2000/ as the web application and SP\administrator as the site owner.

If you run said command, without doing any of the steps of the installation, you get rather unusually very useful information from the error messages. The error messages, one of which is shown below, tell you exactly what you’re missing before the installation can complete.

SPEducationPowerShellError

You can use this method, running the command, configuring the requested component, re-running the command, to get a step-by-step guide to what you need to set up. That is, incidentally, how I got this running the first time. That, and a bit of MSIL disassembly through ILSpy.

The components you need to install and the features you need to configure on the web application are:

  • One brand new web application
  • One site collection created at the root of said web application
    Template doesn’t seem to matter. I’ve used a Team Site
  • Self Service Site Creation on web application
    Configure this through Central Administration->Application Management
  • MySite host created
    Don’t forget to set up both /my and /my/personal
  • SearchCenter site created in web application
    You can use Basic Search Center or Enterprise Search Center

After you’ve completed the configuration of the above steps, running the PowerShell command will begin provisioning SharePoint Education, as shown in the screenshot below.

SPEducationProvisioning

This process will take some time and includes creating several new site collections and activating features both in Central Administration and on the new site collections.

Note: This is one example where you see the difference between having a sufficient RAM amount and working on the bare limits. In the setup for this article, I used an 8 GB RAM machine, and the PowerShell provisioning took 1,5 hours, and that’s just for the PowerShell command to run the provisioning after I had configured all the other components. I repeated the process on a VM with 36 GB RAM and the process took 22 minutes.

The provisioning creates four site collections for you:

  • Institution Site
    Default URL: [root]/sites/global
  • Admin Site
    Default URL: [root]/sites/admin
  • Study Group Site
    Default URL: [root]/sites/studygroup
  • Academy Library Site
    Default URL: [root]/sites/academiclibrary

If the provisioning succeeds, you should be able to open these sites to start exploring SharePoint Education. The screenshot below shows the Institution Site after the provisioning completes. You’ll also find several links to configuration and setup in Central Administration under General Application Settings that you may want to explore too.

As I said, I haven’t explored much on my own, and probably won’t for a while, but feel free to explore on your own and let me know what you find in the comments below :-)

.b

Pin It

Windows Azure Workflow Only in SharePoint Server 2013

This is a good news/bad news post, and I’ll make the choice for you, the good news comes first.

I was researching a claim made by several people (*armpfhMVPscough*) about the impossibility of installing Windows Azure Workflow (WAW) on a domain controller. This caused at least a bit of an outrage because people were told that they need two virtual machines to do SharePoint 2013 style workflow development.

I found those claims strange because I have successfully installed WAW on several SharePoint 2013 boxes, and I haven’t had any problems with them, beyond some trivial authentication mistakes on my first install that were quickly corrected.

So, imagine the look of eggs on my face when I set out to install a new SharePoint 2013 server, adding WAW as I had done probably ten times already, and suddenly landing flat on my stomach with error messages popping up from everywhere when I tried to run the post-install PowerShell commands to connect the two platforms.

Well, it turns out, I wasn’t so crazy after all. At least not regarding this. Let me give you a bit of background…

Workflows in SharePoint 2013

As you may or may not know, SharePoint 2013 now has two workflow engines that behave widely different. The traditional workflows, the ones we’ve used up until SharePoint 2010, are based on the .NET 3.0 framework and runs on the .NET 2.0 runtime.

In SharePoint 2013, we also have the option of using Windows Azure Workflows, which are essentially a completely rebuilt workflow engine that runs on .NET 4.0. Unfortunately, the new workflow engine can’t run the traditional workflows, at least not easily, so you need to choose whether you want SharePoint 2010 style workflows or SharePoint 2013 style workflows.

This is actually a fairly simplified view of the situation, but for the purposes of this article, it should suffice.

Now, the caveat of WAW is that unlike SharePoint 2010 style workflows it doesn’t run in SharePoint as such. To use WAW, you need to install a separate component in addition to SharePoint. This is great from performance, scalability, and flexibility perspectives, but means there’s an additional task to perform to get SharePoint 2013 style workflows up and running. And we’d all want SharePoint Designer Workflow loops and state machines, right? These features are only available in SharePoint 2013 style workflows.

And All of This Is Interesting Because..?

The story so far is pretty straight-forward. The twist comes from the fact that several people started publicly claiming that you cannot possibly install WAW and thus SharePoint 2013 style workflows on a Windows domain controller. Knowing a fair amount of SharePoint developers use only one virtual machine which includes the domain controller role, this lead several people to cry out that you now need at least two virtual machines to do SharePoint 2013 development.

If that had been true, it would have been a blow to the feasibility of SharePoint 2013 workflow development. With the SharePoint 2013 system requirements already on the edge of what is technically possible on current laptops, having to set aside additional resources to run a separate domain controller seems bad.

However, as Liam Cleary documents in his blog post Install Windows Azure Workflow Service on a Domain Controller, installing WAW on a domain controller is not just possible, it is very easy. I’ve had the exact same experiences, in fact I’ve set up WAW and run several SharePoint 2013 style workflows already as part of my research for Introducing SharePoint 2013. No problems at all, except that I forgot to use a fully qualified domain name for authentication the first time I did it.

Note: You need to use a fully qualified domain name for the Run As account when setting up WAW. You need to enable TCP/IP connections for your SQL server. Those are the major caveats.

Because several people, who should be in the know (*coughMVPsharmpft*, nasty cough I have there, sorry), claimed that it was plain impossible, I started asking around to see if anyone had even a mention of the domain controller limitation in any official documentation. Nobody could even point me in the right direction of such claims. I’ve been reading up on the Microsoft documentation on WAW and so far haven’t found anything myself either.

It is quite possible that an installation on a domain controller is not supported, but that’s a continent away from not working for the purposes of development. After all, I’ve still to hear about any SharePoint developer being worried about the supportability of their development environment. And no sane mind would install a single SharePoint farm on a domain controller in a production environment in any case, right?

So, developers, here’s the good news: Just relax. You don’t need two virtual machines to do SharePoint 2013 development, at least not at present. If anyone tells you differently, ask them to tell you exactly what isn’t working, and feel free to let me know their responses in the comments. If they can’t, tell them they’re idiots.

I’m trying to add a mild disclaimer here, but keep in mind we’re currently still in beta and things that seem to work now may not work in RTM.

What you need, though, is SharePoint Server 2013, because WAW workflows are not available in SharePoint Foundation 2013.

No SharePoint 2013 Workflows in Foundation?

Before I continue, I should point out that we’re still at the time of this writing in beta for SharePoint 2013. It is quite possible that Microsoft will change their stance on features and components before RTM.

However, at present, you cannot get WAW workflows to run with SharePoint Foundation 2013. You’ll notice this when you try to run a required PowerShell command towards the end of the installation, and you’ll know it because you get a message stating that the PowerShell CMDLet was not found.

You can get WAW installed just fine. In fact, when I wanted to prove that you could install WAW on a domain controller, I did just that, but because it was a quick setup, I didn’t go with a SharePoint Server install.

Part of the setup of WAW in SharePoint 2013 is to run a PowerShell command to connect SharePoint 2013 to your WAW installation. However, the entire installation of the features required for that connection exists only in SharePoint Server 2013, specifically in the OSFSERVER install files. Those files do not ship with SharePoint Foundation, so there’s no way to set up the infrastructure for connecting to WAW.

So, there you have it, good news and bad news. You don’t need a second VM, but you can’t accomplish what you may want without having Server installed.

.b

Pin It