The Blog

If you have an Office365 subscription, but login to Windows Azure with a Microsoft Account, this post will show you how to add your existing Windows Azure Active Directory from Office365 to your Windows Azure Subscription. Continue Reading →

This month I am very excited to be joining Microsoft as a SharePoint consultant in the Premier Developer group. This is a very thrilling time to be joining Microsoft – infused with fresh energy from a new CEO, the frenetic pace of releases and innovations from the Azure and Web teams led by Scott Guthrie, the cloud development opportunities with Office365 and Yammer, and the release of amazing hardware like the XBox One/Kinect and Surface Pro 3.

I had an amazing time at Blue Rooster the last 4 years – and I’ll miss my friends and the incredibly creative team over there.

In my new role, I’ll be providing guidance, mentoring, training, and samples to Microsoft’s customers on how to develop for SharePoint, Office365, Yammer, Azure, and related technologies.

I’ll continue to blog here – about Yammer, Office365, and of course SharePoint, so stay tuned – lots of great technical posts are coming.

About 9 months ago, I started experimenting with Visual Studio Online for my company’s source control system. Initial results were very promising – the system required little maintenance (mainly just adding/removing accounts and projects), and was full of great features. External collaboration with customers was a snap, as I just needed to add their Microsoft Accounts – no complicated ADFS or trust setups involved.

However, as a software consultancy working with many different clients (and having to adhere to strict confidentiality and non-disclosure agreements), several points of data leakage in the product made it unsuitable for use in this kind of an environment. We have now performed the migration from cloud back to on-prem using the time-limited export option in VSO. Following are some of the reasons for this move back.

Leaking User Information

The nail in the coffin for VSO was the leakage of User information across projects. Visual Studio Online only provides you with a single Team Foundation Project Collection (called “Default Collection”). Project Collections contain projects, users, and settings, and are a security and isolation boundary very similar to SharePoint Site Collections.

In TFS on-prem, you can create multiple project collections. If you work with multiple customers, you can have a collection per customer, and ensure that you have isolation such that only projects and users from that customer are in the collection.

In Visual Studio Online, all your users and projects are lumped into a single project collection, and this presents an opportunity for one customer to see the other customers you are working with.

I was very shocked to see that the Users tab, which is available for everyone in the collection, shows ALL the users in the collection. I assumed that the list of users would be filtered somehow to the users from the projects you had access rights to, but it is an all-up list, and completely possible for one customer to see the other customers in the system.

Users Tab

The Users tab, showing all collection users and email addresses.

In addition to the Users tab, the Assigned To fields on work items were another source of leakage. When typing in a name in the Assigned To field, it’s possible to assign users from any of the users in the project collection, not just members of the current project The autocomplete will happily resolve the names cross-project.

Once we found this out, this user leakage became a non-starter for us.

Cross-Project Work Item Linking

Since most of our consultants work on multiple client projects, they have access rights across the various projects. When working with Work Items, it is often desired to link work items via Parent-Child relationships. The Add Link dialog enables typing work item IDs, and then seeing a preview of the work item before creating the link. You can type in a work item ID from a different project and create cross-project links. In this respect, Visual Studio Online handles this better – it doesn’t allow you to see the work items from projects that you don’t have rights to access:

Cross Project Work Item Link.

However, it’s possible for our consultants to accidentally create a cross-project (cross-customer) link between work items, which can create a confusing experience for our customers. In the screen below, the linked work item shows as “getting details…”, but it never actually gets the details.

Work Item Getting Details.

It would be better if it told you that you didn’t have rights, like it does when you click into the item:

Work Item Details


While VSO is a fantastic platform, at this time it doesn’t work well as the sole repository for a software consultancy that works with multiple clients, and needs complete isolation between client information.