adventures in the new and the old

Category Archives: SharePoint

One of the least used and understood features of SharePoint Online is the Partner Access License or PAL. This license allows you to invite external users to sites within your SharePoint Online tenant without you needing to issue them with an Office 365 license. The only requirement to achieve this is that the user must possess or create a Microsoft account (formerly Live ID) which includes outlook.com, live.com, hotmail.com and msn.com addresses (amongst many other regional derivatives such as live.co.uk).

You are limited in the number of users you can invite using this scheme and the number changes depending on your Office 365 license level – you can find details on this post under “Maximum number of external user invites”.

Having used these license types quite extensively over the last 12 months I thought I would share some key learnings around setting them up.

A few key concepts

The following really need to be understood or explained to understand the rest of the post.

Microsoft account: the new name from Microsoft for any publicly available login account Microsoft provides. It’s had many names and formats over the years as mentioned above.

Federation: in the context of this blog this is the process of synchronisation of an on-premise Active Directory with Azure Active Directory for the purpose of sharing on-premise user information with cloud services such as Office 365.

Cloud account: when you set up an Office 365 subscription you automatically get a chunk of the ‘onmicrosoft.com’ domain snapped off for your own use. These accounts can be used to login and typically take the form user@subscriptionname.onmicrososft.com (i.e. billy.bob@siliconvalve.onmicrosoft.com). This format is also known as a User Principal Name or UPN.

Federated account: an on-premise account that is synchronised with the cloud to allow a user to be granted access to various cloud services. These use custom domains and take the form user@customdomain (i.e. billy.bob@siliconvalve.com). In Office 365 these are an alias of a matching @subscriptionname.onmicrosoft.com account.

Now we have those out of the way, let’s get onto the core of this post.

Recommendation: Use a basic Microsoft account

Have external users register an account with one of the public forms of @outlook.com, @live.com, etc. rather than them use a custom domain. If they have an existing Microsoft account using one of the public domains that could be good to use also. Ask them to enable a second factor of authentication.

Here’s why I recommend using a basic account:

Blocked Custom Domains

Some custom domains are blocked from being used as Microsoft accounts – you can request to have it unblocked by Microsoft but it’s probably not a bad restriction to keep to ensure you keep control over your domain.

Example of a reserved domain.

Limited ability to create lots of accounts

By default you are limited in the number of new Microsoft accounts that can be created in any one day (three accounts to be precise) from an single IP address. Not exactly scalable if you have to create even a moderate number of new accounts in one go. If you try to exceed this limit you’ll get a nice error screen that reads “Sign Up Error 450: You’ve reached the daily limit for creating Microsoft accounts. Please wait a day and try to sign up again.”

Domain is already in use

The domain may already be in use on Office 365 either via Cloud or Federated accounts which leads to problems at login. The user may be able to create a Microsoft account with their custom domain but as soon as they are prompted to login to Office 365 the problems will start.

First let’s look at the three login experiences each account type can have.

When a Cloud account is entered into the login box on the Office 365 login page they must enter their password into the form as well.

Cloud account login example.

A Federated user’s experience may be similar to the above or they may be redirected to their organisation’s ADFS login page to enter their password before being redirected back to Office 365 after a successful login.

A PAL user has two ways to log into Office 365: entering their Microsoft account into the username box on the Office 365 login page or by clicking on the “Sign in with a Microsoft account” link. In both cases the user is redirected to a Microsoft account login page (shown below) for authentication. This experience is very similar to ADFS and gives you a pretty clear idea of how Microsoft accounts work with Office 365 (hint: federation).

Microsoft account login example.

The upshot of the above login experiences is this: if you create a Microsoft account that matches one that is already a Cloud or Federated account then you can only log in using the Microsoft account by clicking on the “Sign in with a Microsoft account” link.

Allowing the Office 365 login page logic to run could either prompt for a local login (Cloud) or automatically redirect the user to their organisation’s ADFS login page (Federated). In both cases the user may authenticate OK but will not have access to your SharePoint tenant as in both cases they have signed into their own organisation’s tenant. The result is they will see a page similar to the one below (click to enlarge).

Failed login due to Federated Identity not in directory example.

That’s all folks!

So, there we have it – the old KISS principle really holds here – don’t try and get fancy with custom domains and you should find you can turn PALs into your friends.

Unsurprisingly I think the way Cloud Computing is transforming the IT industry is also leading to easier ways to learn and develop skills about the Cloud. In this post I’m going to give a run down on what I think some of the best ways are to start dipping your toe into this space if you haven’t already.

Sign up for a free trial

This is easy AND low cost. Turn up to the sign-up page for most major players and you’ll get free or low-cost services for a timed period. Sure, you couldn’t start the next Facebook at this level, but it will give you enough to start to learn what’s on offer. You can run VMs, deploy solutions, utilise IaaS, PaaS and SaaS offerings and generally kick the tyres of the features of each. At time of writing these are:

Learn the APIs and use the SDKs

Each of Amazon, Azure, Google, Office 365 and Rackspace offer some form of remote programmable API (typically presented as REST endpoints). If you’re going to move into Cloud from traditional hosting or system development practices then starting to learn about programmable infrastructure is a must. Understanding the APIs available will depend on leveraging existing documentation:

Amazon Web Services: Pretty much every AWS component has its own REST API – the best thing to do is utilise the available documentation to identify the REST APIs you want to use: http://aws.amazon.com/documentation/

Office 365: as this platform is a combined offering, each of the products on offer (AD, Exchange, Lync and SharePoint) provide various APIs that can continue to be used in a relatively consistent state with their on-premise equivalents. Documentation is spread about a bit on MSDN but here’s a taster:

Google App Engine: Depending on language you have a few options for auto-deploying applications using command-line tools from build scripts. Eclipse tooling (covered above) also provides deployment capabilities.

Rackspace Cloud: no publicly available information on build and deploy.

Windows Azure: You can leverage deployment capabilities out of Visual Studio (probably not the best solution though) or utilise the in-built Azure platform support to deploy from a range of hosted source control providers such as BitBucket (Git or Mercurial), Codeplex, Dropbox (yes, I know), GitHub or TFS. A really strong showing here from the Azure platform! http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/

So, there we have it – probably one of the most link-heavy posts you’ll ever come across – hopefully the links will stay valid for a while yet! If you spot anything that’s dead or that is just plain wrong leave me a comment.

SharePoint has always been a bit a challenge when it comes to structured ALM and developer practices which is something Microsoft partially addressed with the release of SharePoint and Visual Studio 2010. Deploying and building solutions for SharePoint 2013 pretty much retains most of the IP from 2010 with the noted deprecation of Sandbox Solutions (this means they’ll be gone in SharePoint vNext).

As part of the project I’m leading at Kloud at the moment we are rebuilding an Intranet so it runs on SharePoint Online 2013 so I wanted to share some of the Application Lifecycle Management (ALM) processes we’ve been using.

Packaging

Most of the work we have been doing to date has leveraged existing features within the SharePoint core – we have, however, spent time utilising the Visual Studio 2012 SharePoint templates to package our customisations so they can be moved between multiple environments. SharePoint Online still provides support for Sandboxed Solutions and we’ve found that they provide a convenient way to deploy elements that are not developed as Apps. Designer packages can also be exported and edited in Visual Studio and produce a re-deployable package (which result in Sandboxed Solutions).

Powershell

At the time of writing, the number of Powershell Commandlets for managing SharePoint Online are substantially less those for on-premise. If you need to modify any element below a Site Collection you are pretty much forced to write custom tooling or perform the tasks manually – we have made a call in come cases to build tooling using the Client Side Object Model (CSOM) or to perform tasks manually.

Development Environment

Microsoft has invested some time in the developer experience around SharePoint Online and now provides you with free access to an “Office 365 Developer Site” which gives you a single-license Office 365 environment in which to develop solutions. The General Availability of Office 365 Wave 15 (the 2013 suite) sees these sites only being available for businesses holding enterprise (E3 or E4) licenses. Anyone else will need to utilise a 30 day trial tenant.

We have had each team member setup their own site and develop solutions locally prior to rolling them into our main deployment. Packaging and deployment is obviously key here as we need to be able to keep the developer instances in sync with each other and the easiest way to achieve that is with WSPs that can be redeployed as required.

One other item we have done around development is to utilise an on-premise setup in a VM to provide developers with a more rapid development experience in some cases (and more transparent troubleshooting). As you mostly stick to the SharePoint CSOM a lot of your development these days resides in JavaScript which means you shouldn’t hit any snags in relying in on-premise / full-trust features in your delivered solutions.

Note that the Office 365 Developer Site is a single-license environment which means you can’t do multi-user testing or content targeting. That’s where test environments come into play!

Test Environment

The best way to achieve a more structured ALM approach with Office 365 is to leverage an intermediate test environment – the easiest way for anyone to achieve this is to register for a trial Office 365 tenant – while only technically available for 30 days this still provides you with the ability to test prior to deploying to your production environment.

Once everything is tested and good to go into production you’re already in a position to know the steps involved in deployment!

As you can see – it’s still not a perfect world for SharePoint ALM, but with a little work you can get to a point where you are at least starting to enforce a little rigour around build and deployment.

The increasing adoption of Office 365 is driving a lot of traditional development on the SharePoint platform online. As you might expect there are some big differences between on-premise and cloud and the ways in which you achieve customisation and implementation of features.

Traditionally timer jobs played a large part in the way background services could be implemented in SharePoint. You will find that timer jobs are absent in SharePoint Online and that the alternative is to leverage the workflow capabilities of SharePoint to achieve the same sort of outcome.

A fairly typical scenario for timed jobs is to poll external services for some form of information to be cached locally on SharePoint. The good news is that the standard Call HTTP Web Service Action of SharePoint 2013 workflows execute the same in Office 365 as they do on-premise.

Gotcha: and a fairly big (and unobvious) one: this workflow Action can only handle calls to webservices that return responses of type text/html, text/plain and application/json. You will find you are unable to accept and process text/xml responses and the Action will only pipe the response from a webservice call to a Dictionary object so you can’t even do any string manipulation foo on the result if it’s not one of the three response types accepted!