• Media Services at Global Azure BootCamp Finland

    I was at the Global Windows Azure BootCamp in Espoo today, rambling about the coolness of the Microsoft media platform in general and Windows Azure Media Services in particular. The event was hosted at the awesome co-workspaces of AppCampus by Teemu Tapanila and Karl Ots -- hats off for organizing the event, it was great fun!

    I'm not sure if anyone actually tried them, but I put up some lab exercises on GitHub for playing around with Azure Media Services. If you're looking for a starting point for working with Azure Media Services, go ahead and take a look. :)

  • The Anatomy of a Cloud Video Service -- My TechDays 2013 talk

    So, a few weeks back I was on stage at TechDays 2013 Finland. My topic for the day, titled "The Anatomy of a Cloud Video Service", was about the Futudent "camera + software + cloud service" solution that I've been involved with for quite a while now. I intend to cover the associated technologies in more depth in blog form later, but for now, here's the video of my presentation.

    I spent my hour talking about what the client application does, how we handle video transcoding, what it was like to build the associated video sharing service and all the challenges associated with the entire story.

    The talk is in Finnish, so obviously it's only for a limited audience. Also note that for whatever reason, the video is set to forcibly start at 3:22 and you have to specifically click on "watch the entire video" at the timeline marker in order to get to the first few minutes.

  • Upcoming breaking changes in Windows Azure Active Directory preview

    A moment ago Vittorio Bertocci wrote a post on some upcoming changes to the Developer Preview of WAAD. The changes are of the breaking sort, so if you're actively using WAAD, this is something you'll want to react to.

    The WAAD MSDN forums have a more detailed announcement about the changes, but at a glance, here are the two key things I picked up on.

    The service endpoint names are changing

    Your (most likely automatically generated) Web.config settings say something like this now:

          <wsFederation passiveRedirectEnabled="true" 
    					issuer="https://accounts.accesscontrol.windows.net/tenant-id/v2/wsfederation" 
    					....
    					requireHttps="false" />

    After the change, that will have to change to:

          <wsFederation passiveRedirectEnabled="true" 
    					issuer="https://login.windows.net/tenant-id/wsfed" 
    					....
    					requireHttps="false" />

    The metadata and JWT endpoints are changing too, which may or may not affect you -- but if you're using any of them, you'll probably know what to do anyway. :-) 

    The User Principal Name claim will no longer be included

    A while back, the claim that actually names the user principal was changed from EmailAddress to UPN. Now things are changing again, and in the future, the naming claim type will be ... name! Which means your web.config settings need to change from

    <nameClaimType value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" />

    to

    <nameClaimType value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" />

    That's pretty much it. And of course, if you can't get the settings right editing them by hand, you can always run the Visual Studio Wizard again

    Hope this helps someone. :-)

  • Blog move

    Just a quick note: I've grown tired of Blogger regularly doing a hatchet job with my post markup and the limited options they give me for customizing the look and feel of the site, so I've moved to a new host.

    I tried my best to not mess with the existing post URLs, but I'm afraid that at least the RSS feed urls will have changed.

  • Windows Azure Active Directory: Using the Graph API with an Office 365 Tenant

    In a previous post I wrote about querying the Graph API for the group memberships of a WAAD user. In yet another post, I detailed setting up a WAAD tenant, but I also noted that you don't have to do that if you've already got an Office 365 subscription, and would prefer to use that instead. While that statement is technically true, the story is far from complete. As commenter Nick Locke points out, my instructions for using the Graph API don't work for Office 365 tenants: the code throws an exception while trying to get the authorization token for the request. After a bit of trial and error, I managed to figure out a fix. Once again, open up the Microsoft Online Services Module for Windows PowerShell. Run Import-Module MSOnlineExtended -Force to load the module, use Connect-MsolService with admin credentials to establish the connection, and type in:
    $adPrincipal = Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0000-c000-000000000000
    $adPrincipal.ServicePrincipalNames
    If your Office 365 setup is like ours, the result will look a lot like this:
    00000002-0000-0000-c000-000000000000
    AzureActiveDirectory/graph.windows.net
    AzureActiveDirectory/directory_s5.windows.net
    AzureActiveDirectory/directory_s4.windows.net
    AzureActiveDirectory/directory_s3.windows.net
    AzureActiveDirectory/directory_s2.windows.net
    AzureActiveDirectory/directory_s1.windows.net
    AzureActiveDirectory/directory.windows.net
    AzureActiveDirectory/Directoryapi.microsoftonline.com
    Looking at this list, it occurred to me that the problem might be related to the fact that we construct Realm Names for our application using the GUID 00000002-0000-0000-c000-000000000000 and the domain name graph.windows.net -- the result looking like: 00000002-0000-0000-c000-000000000000/graph.windows.net@your-app-principal-id. So I figured I'd change my app to use the string AzureActiveDirectory instead of the GUID, and wouldn't you know it, I got past the authorization token error. Only now I ended up with another error: validating the token didn't work. After a bit of head-scratching and web-searching, I thought I had it backwards: it wasn't my app that was misconfigured, it was the Office 365 tenant. Suppose that the Graph API service actually identifies itself as 00000002-0000-0000-c000-000000000000/graph.windows.net and not AzureActiveDirectory/graph.windows.net, and that's why things are failing. I repeated the commands above in a MSOL PowerShell session that was connected to the WAAD domain I created before, and noted that indeed, the Service Principal Names for Microsoft.Azure.ActiveDirectory were otherwise identical, but AzureActiveDirectory was replaced by 00000002-0000-0000-c000-000000000000. So I cooked up this PowerShell bit: I then ran it against the Office 365 MSOL PowerShell session and tried again. And wouldn't you know, it worked! Apparently, we're not the only ones with this problem, so let's hope this helps save someone else the trouble!