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. :)
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.
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.
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. :-)
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" />
<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. :-)
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.
Import-Module MSOnlineExtended -Forceto load the module, use
Connect-MsolServicewith admin credentials to establish the connection, and type in:
$adPrincipal = Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0000-c000-000000000000 $adPrincipal.ServicePrincipalNamesIf 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.comLooking 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-000000000000and 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
AzureActiveDirectoryinstead 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
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
AzureActiveDirectorywas 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!