Developments in Microsoft Azure: report-out from the Azure Red Shirt Dev Tour

Azure is Microsoft’s platform for cloud services and cloud computing and is a core part of Microsoft’s vision for the future. It gets a great deal of attention at Microsoft internally, which isn’t surprising if you consider that Azure sales more than doubled in recent quarters. Just to give you an idea: in Q1 of 2017 the Azure business grew by 93%. The total annual run rate of Microsoft’s commercial cloud business (which includes Office 365) now exceeds $14 billion and is expected to hit $20 billion by the year 2018.
Another illustration of Microsoft’s commitment to Azure is the recent Azure Red Shirt Dev Tour (there’s a short and rather funny introduction video of the event on YouTube), in which long-time Microsoft evangelist Scott Guthrie, one of Microsoft’s top speakers for the developer community, toured Europe for day-long presentations about all things Azure, hitting cities like London, Dublin, Oslo and Amsterdam. Registration was free of charge, and the Amsterdam venue that I attended was fully booked with around 1200 attendees.


Guthrie, famous for his red polo shirt (hence the “Red Shirt” tour – it would have been interesting if he had worn a shirt combining red and azure for the occasion, covered a number of capabilities recently added to Azure in an impressive three hour keynote full of hands-on live demos, followed by an afternoon session of tips & tricks. It was a good showcase of the many capabilities any cloud platform has to offer nowadays, and a glimpse of what is coming in the near future. These are some of the highlights:

A different VM type for each purpose

Probably the most used feature in Azure is still the capability to run a Virtual Machine in the cloud. There is a considerable number of standard VM types suited for different purposes, going from basic low-cost VM’s to high-performance monsters. Some of the latest additions are VMs that include a GPU, and a very impressive VM type that was created specifically to host big SAP databases (like SAP HANA) on Azure. This new M-series VM has some impressive specs, running up to 128 CPU cores with 3.5 TB of RAM (going up to 20 TB RAM is also an option).

128 CPU cores in action in a single M-series VM

The more powerful VM’s can also run Hyper-V, which enables them to run other VMs inside the main VM. And since things like a Linux VM are also an option in Azure, you can now for example run a Windows Server VM in the cloud which in turn hosts a number Linux VM’s.
Another new feature is an interesting way to help customers save money on licenses (which is at the same time an incentive for customers to not hesitate about creating more VM’s of course): on the VM creation screen there is now a “Save money” option at the bottom. If a customer already has a Windows Server license with Software Assurance, you are entitled to a 40% price reduction as part of the ‘Hybrid Use Benefit’ that’s part of the Software Assurance.


A striking element of nearly each demo in this event was the omni-presence of non-Microsoft technology: several demos were given from an iPhone or a MacBook using a Chrome browser, there was lots of open-source scripting, Linux, and databases other than SQL Server (like MySQL, Progress).
Also noteworthy was the complete absence of Windows Phones – the same thing happened at the recent Microsoft Build conference. I’m clearly not the only one who recently abandoned the Windows Phone platform (see my earlier blog post). Even Microsoft employees now openly use Android or iOS phones.

Azure App development and monitoring

Microsoft’s development tooling has always been a very strong part of its technology stack. The integration with Azure is also there. If there is a failure inside an Azure app, you can see it from the App monitoring functionality. Then, from the detail screen for that failure, you can directly create a new work item inside Visual Studio Team Services (VSTS).

A money-saver is the auto-scale option for Web Apps in Azure. This allows an admin to define rules that say something like:  if CPU usage is more than 70% for x amount of time, then scale up.
An option often overlooked is that you can of course also scale down (below your usual minimal spec) at the hours of the day when your app is hardly being used.

Another demo showed the option to do continuous delivery: update the code for an Azure App in GitHub, which automatically triggers a build, test and (optionally) deploy cycle. This kind of Continuous Integration & Continuous Delivery (CI/CD) pipeline can be configured from Azure portal.
Note that the build servers used for this – which you previously had to set up yourself – are included as part of the service. Azure handles this internally, so you do need to spend any time on the build server infrastructure.
Deploying apps in self-supporting containers is another fast-rising trend. Visual Studio 2017 now has integrated Docker support and tooling. You can even include ‘dockerization’ as part of your CI/CD pipeline.

Deployment slots are also a powerful feature, which allows you to deploy the new version of your app to an alternative URL so you can check the result. This second location functions as a staging slot. At a time of your choosing you can then simply swap the production slot with the staging slot. The production URL now has the app version that was in the staging slot and vice versa.

Native mobile apps

Xamarin, the development tool to create native mobile apps (purchased by Microsoft a few years back) has now been fully integrated into Visual Studio 2017. It’s also suited for iOS app development, you do not even need a MacBook for proper testing, Xamarin’s Live Player allows you to view how your app will look on a certain device. In the Azure mobile center you can test the deployment of your app on actual devices that are racked up in the cloud. This is especially useful for Android devices since there are so many different Android versions.


There are of course also important developments for databases.  SQL Server can be run as a VM but also as a service: no machine to log onto, you just get the connection string to your database. A large instance of such a database can now hold up to 4 TB of data.
Next to SQL Server, you can now also get PostgreSQL and MySQL as a service.

Microsoft recently announced the Azure Database Migration Service, which provides a Lift & Shift service for any current (on-premises) SQL Server database to the Azure database service. The migration service promises that there will no (or hardly any) need to change any code related to your database.

Azure also contains a Performance Recommendation option, which works based on machine learning. It is an easy way to tune your database. According to Guthrie, proper tuning can often prevent the need for a larger (and more expensive) database.

If you want to go beyond relational data, and store any kind of data (like key-data, documents, graphs) on a global scale, Azure now offers Cosmos DB (formerly known as DocumentDB). This is a rather impressive, globally distributed database service. In a nutshell: any data you want, synchronized across any region in the world where you need it.
Cosmos DB supports many kinds of data and you can use multiple open source API’s against it. It can scale to millions of transactions p/sec and petabytes of data. The Cosmos DB service offers a comprehensive SLA on four dimensions: there are 99.99% guarantees for availability, throughput, latency, and consistency.

Serverless computing

Why pay for a VM or even a service that is always on, when you actually just need a certain function when a customer asks for it? One of the biggest trends for the coming years is serverless computing, allowing you to trigger a piece of serverless code only when you need it, paying for only the clock cycles your are actually using. This dramatically lowers the cost to only a fraction of an average Azure Compute scenario.
The serverless code can be defined as part of Azure Functions, or you can define a serverless workflow as part of an Azure Logic App. There is already a large number of predefined event sources available that can trigger an Azure Function or a step in an Azure Logic App.

Cognitive Services

The Azure Cognitive Services are accessible quite easily through a proper API. An app was shown for example where you could upload cat images. The cognitive service determined on the fly if the image actually contained a cat, otherwise the image was rejected and moved to a separate folder.
A final demo was the Kiosk Realtime Crowd Insight (this demo is available on GitHub) that shows the estimated age, gender and mood of the person in front of the webcam.
We talk a lot about Machine Learning these days, but I still found it almost staggering how easy it has become to apply this kind of functionality in your own application at very low cost.

This article was originally posted on the Capgemini ‘Capping IT Off’ blog.


Task List types in SharePoint Online and how to use them in SharePoint Designer workflows

If you are still working with SharePoint Designer workflows, you will be familiar with a setting that has to be made for each workflow: the associated Task list.
Strangely, you need to set this even if your workflow isn’t creating any tasks.

If you open the Task list drop-down, SharePoint Designer will propose the available task list – if any are available – and an option to create a new Task list.


As you will probably know, there are two platform types available in SharePoint Designer 2013: you can create SharePoint 2013 workflows and you can still create SharePoint 2010 workflows. The latter option is still very relevant, because several useful functions like creating a copy of a document only exist in SP2010 workflows.

While working on a SharePoint Online site which has both SP2010 and SP2013 workflows, I noticed a difference in the Task lists that were being offered in the dropdown, which I couldn’t explain at first.

Then it dawned on me: SharePoint 2010 workflows come from the age of SharePoint 2010 (obviously). If you would create a Task list through the browser in SharePoint 2010, you get a different Task list compared to the one that you create through the browser in SharePoint 2013!
As a result, if you create a SharePoint 2010 workflow (in SharePoint Designer 2013) and a SP2010-style Task list is available, that is the one the dropdown will offer you.
A SharePoint 2013 workflow on the other hand will offer you both the SP2010 and SP2013-style Task lists.

You can use a SP2010 workflow with a SP2013-style Task list, but that has another nasty side-effect: the Task list is then automatically populated with a number of old-school content types, like “SharePoint Server Workflow Task” (yes, even in SharePoint Online), and all of the fields that come with it.

Another unpleasant side-effect: the SP2013 version of the Task list has several additional options, like displaying a timeline and a strikethrough option for completed tasks. But if you associate a SP2010 workflow with a SP2013-style Task list, some of those options will not work anymore (found this out the hard way).

So how do you handle this? If you have both SP2010 and SP2013 SharePoint Designer workflows on your site, my recommendation is that you create two Task lists:

  1. a SP2010-style Task list for the SP2010 workflow tasks
  2. a SP2013-style Task list for the SP2013 workflow tasks

That way each workflow gets the appropriate Task list capabilities.

Now here’s the trick: if you create a Task list through the browser in SharePoint 2013 or above – so also in SharePoint Online – you will always get the SP2013-style Task list.
The SP2010-style Task list is still available though, but you will need to create the list through script.
The main distinction to remember:

  • SP2010 Task list = TemplateType 107
  • SP2013 Task list = TemplateType 171

So now you can do something like this in CSOM:

#get the context (request the site, user and password parameters from the user)
$context = New-Object Microsoft.SharePoint.Client.ClientContext($site)
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($user, $password)
$context.Credentials = $credentials

#now we can prepare the new list object
$listCreationInformation = New-Object Microsoft.SharePoint.Client.ListCreationInformation
$listCreationInformation.Title = “My Old School SP2010 Task List”
$listCreationInformation.Description = “My Old School SP2010 Task List”
$listCreationInformation.TemplateType = 107

#then we create the list in our web site context
$list = $context.Web.Lists.Add($listCreationInformation)

And voila, you have a custom-made SP2010-style list in your SharePoint Online site.
The SP2013-style list can obviously be created in the same way, or through the browser if you like.

Why I abandoned the best mobile operating system

This is a story about how I abandoned my old mobile phone last year, even though it had the best mobile user experience available. Or actually, it’s a story about the digital workplace. Because let’s face it: considering the amount of time we spend on our phones, the smartphone is an important part of that digital workplace.

So what phone did I have you ask? It was a Windows Phone (yes, you can stop snickering now), the Lumia 830 if you want specifics; the last one branded as Nokia. It runs the Windows Phone mobile client OS that was originally released in 2010, as follow-up to Windows Mobile (formerly PocketPC). While Windows Mobile was very Microsoft-oriented in terms of connections and user interface, the new Windows Phone OS was developed from the ground up with the capabilities of modern smartphones in mind and a more universal (think cross-platform) look onto the world. This new OS arrived very late in the game, because competitors Android and iOS already had well developed operating systems for modern smartphones at the time. The advantage of arriving late though, was that Microsoft had a chance to take all lessons learned from existing mobile operating systems, and develop a whole new user interface taking all this into account.

I have always found the iOS user interface to be cluttered, with a plethora of different looking icons on your start screen. The Android interface has the same issue and was still rather clumsy around 2010 (although much improved since then). In comparison, the Windows Phone’s interface of tiles is clean, structured, intuitive, and you can get to any setting or application really fast. Also the so-called live-tiles are far superior to any widget I’ve seen on an Android phone, because of the way they fit and blend into the overall appearance. Add to that the flawless Exchange, OneDrive and Skype integration, and you get an almost unbeatable mobile digital workplace in terms of productivity.


Why abandon my phone then? That had everything to do with available apps and app support. So how did this happen? Well, do you remember the VHS vs. Betamax format war in the 80s? Or more recently HD-DVD vs. Blu-ray? SD-card vs. Memory Stick? Super Audio CD vs. regular CD? My point is: the best platform doesn’t always win. If another product gets better marketing, a better image, better distribution channels, more resellers, then an objective comparison of features and usability doesn’t have to be all-decisive. And at some point if you drop below a certain market share, the battle is lost. This is exactly what happened with the Windows Phone – for a large part I should say because Microsoft was so late in the game, and the competition had already cornered the market.

As a result nearly every company or event organizer that was building a new mobile app, made the decision to only create a version for Android and iOS, because the limited Windows Phone user base didn’t justify the cost of an additional version. There still were many Windows Phone apps of course for key applications (mobile banking, Facebook, Twitter), sometimes sponsored or even created by Microsoft, but often these were updated less frequently and had less capabilities than their (better looking) Android/iOS versions. And then over the last few years, when Microsoft basically stopped investing in phones and the Windows Phone OS altogether, focusing more on Windows 10 and the Universal Windows Platform Apps, many companies even dropped support for their existing Windows Phone apps. It was a hopeless downward spiral.

So what does this tell us about digital customer experience in general? Most of all, although user experience is important, it’s not the whole story. You may have an app or a site with a slick look & feel and the best usability around, but that’s just the storefront. Important as that is, if you don’t back it up with proper marketing, image-building, good distribution channels and continuous updates, you are unlikely to succeed. In a market that is becoming more and more digital and global, keeping both the storefront and all surrounding processes in shape takes considerable effort and attention.
And as the Windows Phone example shows us, you also need to act in time. A great digital user experience is important, but that by itself is not the killer feature that will lure customers away from one of your competitors. Gaining market share (or preventing market share loss) if you arrive late in the digital game is going to be tough.

This post was originally published on the Capgemini ‘Capping IT Off’ blog.

Permissions required to start a SharePoint Designer workflow

I’ve read in multiple blog posts that you need Contribute permission to start a SharePoint Designer workflow on a List item. That makes sense, because the workflow also generates a workflow status field on the List. And starting the workflow on an item typically alters the value of that field, which automatically means you need permission to change that item.

What I’ve found is that Contribute permission on the List itself is not enough. There are two other permissions required:

  • Contribute permission on the hidden Workflow History list
    The actions taken by a workflow are recorded in a workflow history list. By default this is the hidden List ‘Workflow History’ (URL: {site}/Lists/Workflow%20History) which is always present.
    If the user account that started the workflow cannot write anything to this history list, then the workflow will fail rightaway.
    By default the Workflow History list inherits its permissions from the site root. What typically happens is: someone needs to start a workflow from a Document Library but has only Read permission on the site root. The Workflow History list inherits that Read permission, which is not enough for a workflow to start/run properly.
    If your users who start workflows are already regular Members of the site and therefore have Contribute permission from the root, then you will not notice this problem since you automatically have the correct permission on the Workflow History list.
  • Contribute permission on the Tasks list
    Almost the exact same logic applies to the Tasks list. If (and only if) you have a workflow that creates Tasks, then obviously the user needs Contribute permission on the Tasks list configured for that workflow as well.
  • Read permission on the site root
    Please note: I am less certain about this one, but I found that the permissions on the site root also play a role. My theory is this: you need Read permission on the site root so the user can ‘see’ the available workflows and the lists (Tasks and History) attached to those workflows. Somehow that information is stored at site level, which is why you need Read permission there.

Note that the above permission requirements also apply to workflows at site level, not just for List workflows.
Get these permissions in place, and your users should have no trouble starting SharePoint Designer workflows (either manually, or automatically OnCreate/OnChange).

Limitations for external users in SharePoint Online

You can share a SharePoint Online site (or a list or document, etc.) with external users, if your global setting for the site collection allows this. Although you need to select a specific permission group for these external users (from the list of available permission groups in that site), those external user do not have the same capabilities as a ‘normal’ user of the site.

The reason for this is that external users do not have an Office 365 license linked to them, at least not unless you choose to assign that to them.
As a result there are a number of things you cannot do as an external user. Microsoft has some documentation on those limitations:

Manage external sharing for your SharePoint Online environment

I recently found that there is at least one other thing that external users cannot do, which is not documented: An external user cannot share something with another external user by inviting them.

On the one hand that makes sense, because that could potentially allow an endless string of external users in the site. On the other hand it is strange: if I am allowed into the site as an important user with broad permissions, then why can’t I share anything with another (new) external user?

What I haven’t tried yet is to see if an external user can share with new external users once an Office 365 / SharePoint Online license is assigned to his account. Will update this post if I find out.


Versioning in SharePoint when editing in Word compared to Word Online

While I was developing a workflow to be triggered on a changed Document Library item in SharePoint Online (this was a Word document), I noticed something interesting about the versioning.
In the workflow I was checking if the version number had already increased, thinking that in this way I could determine if the user was done editing.

As it turns out, it depends if you are using Word or Word Online. What happens is this:
If you are using your local MS Word installation, then you are basically working offline. You only connect to SharePoint Online when you take an explicit action like saving or checking-in a document. SharePoint will not create a new version in the version history until you click Save in Word. So even if you type lots of new text and update some properties, but close the document without saving, nothing is changed in the version history.

This is very different in Word Online. As you probably know, there is no Save button in Word Online, because any change is automatically saved for you. So that made me wonder: if I edit a document in Word Online for half an hour, making many changes, then that document is going to be saved automatically dozens of times. So does that create dozens of new versions in the history? Well, that would be awkward and luckily the answer is no.

What happens is that Word Online creates a new version in the version history (in SharePoint Online) when the first change is being saved in Word Online. So as long as you don’t touch anything in Word Online and just read the document, you get no new version. Then, on every next change in the document that is saved in Word Online, that same new version is *updated*. You can see the Modified time change in the version history.
That is actually the same behavior that we are used to in (local) Word: as long as you do not close the document, subsequent saves will be considered as an update to the same version. This is true if you use both minor and major versions, but also if you only use major versions.

So coming back to my workflow, the downside here is that a new version in the history does not always mean that the user explicitly saved his work. That depends if Word Online or (local) Word was used. Your new version will in any case appear in your version history more quickly when using Word Online.


Accessing your Audit Reports in SharePoint Online

I was used to my SharePoint audit reports index being available as a link in Site Settings > Site Collection settings.
In SharePoint Online however, that link appears to be gone. I can still edit the Audit Settings, but there is no link to open the actual reports.

I’ve seen different reasons mentioned for this. This might be done on purpose, because the Office 365 Protection portal has become the access point for audit/compliance reports.
This doesn’t help me, because in this particular case I did not have access to the Protection portal of the customer. But if I need to check something for SharePoint Online, then obviously I would like to have access to at least the reports for SharePoint Online. That seems reasonable if you are a Site Collection administrator, doesn’t it?

Luckily there is a workaround: the URL for the audit reports is accessible, you just need to know it.
After the URL to the root of your site, append the following:


and voilà, you’re there!