[SP2013] Recipe: one SP2013 development machine in Azure

When you are a developer who’s looking for an easy way to create a development machine, this is the post you want to read. Especially when you also have an MSDN subscription lying around somewhere. What we’re going to do is setup a ready to use developer box in Azure. This recipe will require approximately an hour of your time.


  • A valid Azure subscription. We’re going to create an A4 (x-large) virtual machine. When you turn it off and on again, that should fit into any MSDN subscription level.
  • An MSDN subscription.
  • Some scripts, download.
  • The Azure Powershell environment, download.
  • Your Azure publishing profile, download.


  • Downloads all the bits and install the Azure Powershell package.
  • Start the Windows Azure Powershell prompt.
  • First, make sure Azure is connected to your account. You can do this by running Add-AzureAccount.
  • Then, run Get-AzureSubscription to find the name of your subscription, you’ll need it in the next command.
  • Navigate to the folder where you downloaded the scripts.
  • Run the following command:
    .\CreateSharePointDeveloperMachine.ps1 -imageName "03f55de797f546a1b29d1b8d66be687a__Visual-Studio-2013-Premium-Update2-AzureSDK-2.3-WS2012" -azurePublishSettingsFile C:\users\repsaj\Downloads\my.publishsettings -subscriptionName "Windows Azure MSDN - Visual Studio Premium" -storageAccountName "repsaj" -vmName "repsajdev" -vmSize "ExtraLarge" -adminUserName "jasper" -adminUserPassword "Pass@word1" -localSPFarmAccountName "sp_farm" -localSPFarmAccountPassword "Pass@word1"
  • Things to review:
    • The image name includes the type of Visual Studio instance (Premium in the example), you might want to change that according to your subscription.
    • The publish settings file; this is the one you downloaded as a prerequisite.
    • Your subscription name; as stated above.
    • You should change the passwords obviously.

That’s all! Run the command and it will spin up a brand new VM in Azure. That VM will have SharePoint and Visual Studio installed. The installation will be in vanilla state, so you can configure it the way you like. My advise: start with copying a spautoinstaller folder to the machine and using that to configure the SharePoint instance. That way you have a repeatable result for the next time you want to spin up a device with similar config.

For more information about the scripts, along with instructions how to setup a box with AD or other types of machines (like Web and SQL), check out this link: http://visualstudio2013msdngalleryimage.azurewebsites.net/.

Bon apetit!


WCF service using Azure relay and ADFS authentication (1/2)

What I’m going to write about in this two-part article is what could be considered quite a common scenario. Your company wants to expose data to its employees outside of the internal network. Take a mobile app (or Windows 8 app) for instance, which gets its data from a legacy back-end system. In “old fashioned” scenario’s, you could:

  • Create a WCF webservice to host the data.
  • Deploy the webservice into some kind of secured network zone (DMZ).
  • Kindly ask the firewall admins to open up a port to your service.
  • Register a DNS address which makes it easier to call your service.
  • Request SSL certificates and secure your service so only encrypted data is sent.

In this article, I’ll write about how Azure can make your life easier by handling some of these things in a different way. You, as a reader, should be familiar with WCF and have a basic understanding of authentication schemes. Some knowledge of what ADFS is would be handy too.

There’s two Azure topics I want to talk about: relay and ACS. In the first part of this article, we’ll talk about relay. How to setup ACS with ADFS will be topic of the second part.


Setting up the service bus in Azure

Relay is a technique which enables you to register your WCF service with Azure. Once registered, clients are able to call Azure instead of your service directly. And because the service initiates the communication, you only need access to the Internet, not from it. In Azure, this is handled by the service bus, which is a multifunctional messaging system. Relay is only a part of the functionality.

Here’s what happens in general:

  1. The service registers itself with Azure .
  2. Azure acknowledges the registration. The connection is kept open for future use.
  3. A client now connects to the endpoint registered with Azure and sends a webservice request.
  4. The request is relayed to the local WCF service.
  5. The result is passed back to Azure.
  6. The service bus passes the result to the client.

For you as a developer, this has some advantages:

  • The call to Azure is https secured, so all data going to Azure is always encrypted. No need to purchase an SSL certificate.
  • Same goes for data going to the client, encrypted as well.
  • No need to open up any firewall ports. Default internet access is enough to make this work
  • Although I haven’t thoroughly tested this, it should work in all kinds of proxy-enabled scenario’s too.

Ok, cool. So what do you need to make this work? To begin with, you’ll need a Windows Azure account. Open up the management portal (https://manage.windowsazure.com/) and go to the “service bus” section. Click “Create” and choose a namespace for your service bus instance:

You can request the access key once you created the service bus instance. This key is used to authenticate server / client with the service bus. In part 2, we’re going to use ACS / ADFS for that, in which case the shared secret access key is irrelevant.

Creating a relayed WCF service

Once you’ve got your service bus namespace setup, it’s time to create a service. Most easy way is to create a console application which will use a ServiceHost object to self-host the service. The most important thing here are the bindings. You will have to use two bindings:

  • One normal binding (like BasicHttpBinding) which hosts the service in a normal way, for instance on http://localhost:1234.
  • A matching relay binding (in this case BasicHttpRelayBinding) which is used to connect to Azure and relay the service.

Assuming some WCF knowledge, creating a service host should be easy:

Registering the endpoints and bindings:

The things to notice:

  • The bindings need to match. So use a BasicHttpRelayBinding in combination with a BasicHttpBinding and not a WsHttpBinding for instance.
  • Both endpoints register the same interface class, so both endpoints know which methods your service will provide.
  • For the relay binding, you specify the service bus address with the help of the CreateServiceUri method. This asks for a scheme, the namespace you created earlier and a service path which can be anything you like.

In the example for part 2 (ADFS), we’ll switch from using a SharedSecretTokenProvider to a SamlTokenProvider used with SAML tokens.

Basically, that’s all you need to do on the server side. Simple, right? You could create one extra endpoint to provide a mex metadata exchange binding. The code to do that:

I would advise to use the mex endpoint only in development environments and leave it out for production. But that’s up to you, it doesn’t really matter that much.

Add a serviceHost.Open(), run your console app and see if it properly registers itself with Azure. Once it does, you should be able to create a client and connect with it.

Creating a client to match

Creating a client follows the same principles. The client counterpart of a ServiceHost is the ChannelFactory. Because it shares the interface definition, it’s wise to keep that class in a shared library. But you could also make use of the local endpoint and the “Add Service Reference” functionality of Visual Studio, which will generate an interface class for you. As long as the interface class has the same methods and signatures as your service has, you’re good.

Now, as we did with the service, we need to specify the endpoint behaviour:

And with that setup, you can simply create a channel and call the method of choice!

So the cool thing is, apart from some configuration and setup, it’s really not that hard to setup a relayed service. In my opinion, this is far less complicated than convincing the firewall guys to open up ports for you 😉

This service is secure. All the communications are encrypted via SSL and both client and server need to know the shared access key to be able to connect to the service bus. But this method of authentication is pretty limited and not really usable in mobile apps scenario’s (how do you prevent some unauthorized user from using the app?). So in the follow-up of this article I will explain how to extend the sample with ADFS integrated authentication. That article will also contain a full code sample.

Update: and here’s part two.

SP2010: All SharePoint cloud scenarios

Okay. It’s 2012. You’re hearing all this talking about the cloud and you’ve studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I’ll try to list all the options you’ve got at this moment (mind you: the options will probably change over time).

Read More