adventures in the new and the old

Monthly Archives: April 2014

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.

Certainly if you’ve been involved in anything remotely cloud related in the last few years you will most certainly have come across the concept of on-demand or elastic scaling. Azure has it, AWS has it, OpenStack has it. It’s one of the cornerstone pieces of any public cloud platform.

Interestingly it’s also one of the facets of the cloud that I see often misunderstood by developers and IT Pros alike.

What is “Elastic Scalability”?

Gartner (2009) defines it as follows:

“Scalable and Elastic: The service can scale capacity up or down as the consumer demands at the speed of full automation (which may be seconds for some services and hours for others). Elasticity is a trait of shared pools of resources. Scalability is a feature of the underlying infrastructure and software platforms. Elasticity is associated with not only scale but also an economic model that enables scaling in both directions in an automated fashion. This means that services scale on demand to add or remove resources as needed.”

Sounds pretty neat – based on demand you can utilise platform features to scale out your application automatically. Notice I didn’t say scale up your application. Have a read of this Wikipedia article if you need to understand the difference.

On Microsoft Azure, for example, we have some cool sliders and thresholds we can use to determine how we can scale out our deployed solutions.

Scale this service based on CPU or on a schedule.

What’s Not to Understand?

In order to answer this we should examine how we’ve tended to build and operate applications in the on-premise world:

More instances of most software means more money for licenses. While you might get some cost relief for warm or cold standby you are going to have to pony up the cash if you want to run more than a single instance of most off-the-shelf software in warm or hot standby mode.

Organisations have shied away from multi-instance applications to avoid needing to patch and maintain additional operating systems and virtualisation hosts (how many “mega” web servers are running in your data centre that host many web sites?)

On-premise compute resources are finite (relative to the cloud). Tight control of used resources leads to the outcome in the previous point – consolidation takes place because that hardware your company bought needs to handle the next 3 years of growth.

Designing and building an application that can run in a multi-instance configuration can be hard (how many web sites are you running that need “sticky session” support on a load balancer to work properly?) Designing and building applications that are stateless at some level may be viewed by many as black magic!

The upshot of all these above points is that we have tended to a “less is more” approach when building or operating solutions on premise. The simplest mode of hosting the application in a way that meets business availability needs is typically the one that gets chosen. Anything more is a luxury (or a complete pain to operate!)

So, How to Realise the Promise?

In order to fully leverage auto-scale capabilities we need to:

Adopt off-the-shelf software that provides a consumption-based licensing model. Thankfully in many cases we are already here – we can run many enterprise operating system, application and database software solutions using a pay-as-you-go (PAYG) scheme. I can bring my own license if I’ve already paid for one too. Those vendors who don’t offer this flexibility will eventually be left behind as it will become a competitive advantage for others in their field.

Leverage programmable infrastructure via automation and a culture shift to “DevOps” within our organisations. Automation removes the need for manual completion of many operational tasks thus enabling auto-scale scenarios. The new collaborative structure of DevOps empowers our operational teams to be more agile and to deliver more innovative solutions than they perhaps have done in the past.

Be clever about measuring what our minimum and maximum thresholds are for acceptable user experience. Be prepared to set those CPU sliders lower or higher than you might otherwise have if you were doing the same thing on-premise. Does the potential beneficial performance of auto-scale at a lower CPU utilisation level out-weigh the marginally small cost you pay given that the platform will scale back as necessary?

Start building applications for the cloud. If you’ve designed and built applications with many stateless components already then you may have little work to do. If you haven’t then be prepared to deal with the technical debt to fix (or start over). Treat as much of your application’s components as you can as cattle and minimise the pets (read a definition that hopefully clears up that analogy).

So there we have a few things we need to think about when trying to realise the potential value of elastic scalability. The bottom line is your organisation or team will need to invest time before moving to the cloud to truly benefit from auto-scale once there. You should also be prepared to accept that some of what you build or operate may never be suitable for auto-scale, but that it could easily benefit from manual scale up or out as required (for example at end of month / quarter / year for batch processing).