The Case of the Missing Technical Preview build

I am trying out the Windows 10 Technical Preview, and have been running build 9926 for some time. Today (19032015) Microsoft released build 10041 and I installed it immediately, of course. Not surprisingly I had some problems which were so bad that I reverted back to the 9926 build. I later figured out that it might not have been the new build that was the problem, but something else. So I wanted to try installing 10041 again to test that theory. Problem was that 10041 was no longer being offered to me in Windows Update. Turns out Windows keeps track of the builds you have reverted from and hides those from Windows Update. Here is how to make them visible again.

In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability.

This is where all the settings for the preview program are stored. Here is what that key looked like on my system:

BranchName    REG_SZ    fbl_impressive
ThresholdRiskLevel    REG_SZ    low
ThresholdOptedin    REG_DWORD    0x1

10041    REG_DWORD    0x1

Notice the key RecoveredFrom and the value 10041 in it. Delete the RecoveredFrom key and do another check for updates in Windows Update. The build should now be listed.

Add the Azure VM agent to existing Virtual Machines

Here is a quick rundown of how to add the base VM agent to existing Azure VMs:

  1. Find all your VMs that currently do not have the agent installed:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null }
    or this variation if you only want to get the VMs that are actually running:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null -and $_.Status -eq “ReadyRole”}
  2. Install the agent bits on the VM
    Azure does not provide a way to inject the agent into an existing VM, AFAIK, but you can use any number of ways to push it out. You can download the agent here I use the following command line to silently install the agent:
    msiexec.exe /package WindowsAzureVmAgent.2.3.1198.670.rd_art_stable.140328-0941.fre.msi /passive
    Pro Tip: Use Azure Files to store the files and scripts you use. That makes them readily accessible to you VMs, with the added benefit of not having to maintain a file server.
  3. Update your VMs to reflect that they are now running the agent:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null } | ForEach { $_.VM.ProvisionGuestAgent = $true;Update-AzureVM -VM $_.VM -Name $_.Name -ServiceName $_.ServiceName}
  4. Check the status of the guest agent for all VMs:
    Get-AzureVM  | select -Property ServiceName,Name,@{Name=”GuestAgentStatus”; Expression={$_.GuestAgentStatus.Status}}
    Every VM with the agent installed should report a value for Ready in the GuestAgentStatus column.
  5. We can now add other extension agents; like BGInfo:
    Get-AzureVM | where { $_.ResourceExtensionStatusList.Count -eq 0} | Set-AzureVMBGInfoExtension -ReferenceName BGInfo -Version 1.* | Update-AzureVM
  6. Another example would be the Azure Operational Insights extension:
    Get-AzureVM  | where {$_.GuestAgentStatus.Status -eq “Ready” } | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>” -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM
    Find your workspace key and ID in the Azure portal. More info here:

Customized claims in ADFS


The claims pipeline in ADFS is an interesting piece of software. I recently had a chance to re-familiarize myself with it. A third party SaaS application used an organizations internal employee numbers together with their own customer number for that organization to uniquely identify users. This called for issuing a claim to the SaaS app relying party (a.k.a. service provider) that picked up an attribute from Active Directory containing the internal employee numbers, prepending the SaaS app’s customer number and issuing it as a Name ID claim. Furthermore it was a requirement that the Name ID claim was the only custom claim issued. Of course I wanted the most elegant and efficient solution I could come up with, so that meant the the number of claims rules had to be as low as possible.

To do this kind of thing you have to use custom claim rules. The template rules are not flexible enough, but it is a good idea to use them to create the base claims query language syntax for you. Here is what I ended up with:

Get the employeeID LDAP attribute from Active Directory

c:[Type == ";, Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = (";), query = ";employeeID;{0}", param = c.Value);

This claim rule queries the Active Directory store for the employeeID attribute. If it is present a claim is added to the incoming claims pipeline by using the operator ADD. I store the value of employeeID in a custom type ( which only exists as a temporary placeholder for the value of employeeID. You can use both URLs and URIs to create custom claim types, if you don’t want to go with one of the standard ones. No claim is issued by this rule. That happens in the next rule…

Transform employeeID

c:[Type == ""%5D
=> issue(Type = ";, Value = "350-00" + c.Value);

Next we check for the existence of an incoming claim of type If it is present we now issue a claim of type nameidentifier. If the statement evaluates to False; no claim is issued. Hopefully the relying party knows what to do in that case. We set the value of the Name ID claim to the SaaS app’s customer ID number plus the employeeID from Active Directory.

The result looks like this in a test app I used for testing:

Claim Type Claim Value 350-00123456

Thoughts on improvements…

I really would have wanted to accomplish this with just one claim rule. If anyone of you reading this knows how to accomplish that; sound off in the comments.

Happy authenticating!

Slide decks from NIC conference available on SlideShare

The slide decks from my talks at the Norwegian Infrastructure Conference (NIC) event are now available on SlideShare:


How to install the Azure Operational Insights agent on an Azure VM using PowerShell

Most of the Azure VM extensions have their own specialized PowerShell cmdlets to configure them, e.g. Set-AzureAccessExtension, Set-AzureVMBGInfoExtension, Set-AzureVMMicrosoftAntimalwareExtension etc. But you can also, to some extent, use the generic Set-AzureVMExtension. The example below show how to use it to install and configure the Operational Insights agent/extension in your Azure VM:

Get-AzureVM -ServiceName <cloud service name> -Name <VM name> | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>”}’ -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM

You can find your OpsInsights workspace ID in your Operational Insights portal.

  1. Select Servers and Usage
  2. Press Configure
  3. Your Workspace ID and access keys are displayed on the right. Use the primary key.
    For servers outside Azure you can onboard them directly following these instructions:

Connecting agents directly to Operational Insights

Happy monitoring!

Microsoft Campus Days 2014 Azure RemoteApp slides available on SlideShare

I recently gave a session at the Microsoft Campus Days 2014 Event in Copenhagen, Denmark about the new Microsoft Azure RemoteApp service. Thank you to everyone that came to the session. The slide are now available on SlideShare:


Manage Azure Active Directory without an Azure subscription (sort of)

Introduction to Azure Active Directory

Azure Active Directory is Microsoft’s cloud identity platform and the identity provider for all the services in the Microsoft Cloud ecosystem. It is a multi tenant global identity platform, available in all the Azure regions. If you have Office 365, Windows Intune or Microsoft Azure; you also have Azure Active Directory. To call it Azure Active Directory can sometimes be a little misleading because although it is part of the Azure platform, it exists outside the other services we generally associate with Azure, like Infrastructure-as-a-Service or Platform-as-a-Service. Even though Azure Active Directory shares its name with the Windows Server Active Directory Domain Services role we find in Windows Server, Azure AD offers a lot more than its earthbound namesake. Azure AD is not just a directory that stores information about users and groups, and authenticates them, it also has identity lifecycle management, advanced reporting, multi-factor authentication and support for OAuth, OpenID Connect and WS-* protocols. The complete feature set is too long to list here, and outside the scope of this post anyway. Azure AD is backed by a REST API called the Graph API.

Azure AD comes in three flavors; Free, Basic and Premium. The base offering, Free, can be used by anyone for almost anything. You could build your own webapp in AWS and use Azure AD as the identity provider for example. Like I mentioned, if you already have Office 365, you also have Azure AD. The Office 365 portal offers one view into Azure AD via the admin portal (


Another way to interact with Azure AD is via PowerShell. The Azure AD PowerShell module has over 70 cmdlets:


As you can see from the list above, it is Azure AD that handles federation and directory integration with your existing on-premises directories, not Office 365.

Management of Azure AD

As we’ve seen there are several views into Azure AD; PowerShell, Office 365 or Windows Intune portals. But to manage the full set of available features in Azure AD we need to use the Azure Management Portal (


If you have an Azure subscription you either got an Azure AD tenant when you signed up, you created one in the Azure portal afterwards or you associated your existing Azure AD tenant with your Azure subscription. Either way that tenant then becomes visible in the Azure portal like in the screenshot above. From here you can manage all the base functionality of Azure AD like directory integration, domain verification, multi-factor authentication, reporting etc. You can also add users form other Azure AD tenants (provided you have access to the tenant in question) and add Microsoft Accounts (MSA).

Azure AD vs. Azure

There are several ways to get Azure AD without having an Azure subscription. Maybe you signed up for an Office 365 or Windows Intune trial, or something else. However you got an Azure AD tenant you now want to manage it from the Azure portal. But you cannot do that without a subscription. If you try to log on to the Azure Management portal with a Global Administrator from your Azure AD tenant you get an error telling you you do not have any active Azure subscriptions:


What you are experiencing here is the dichotomy between Azure and Azure AD. Azure AD is a separate service from Azure with its own roles and permissions. A user account in Azure AD can have one of several roles inside the Azure AD tenant, but no roles in Azure. The roles in Azure AD are:

Organization role Description
User Regular user without any special privileges or permissions. Can read most information in the directory (tenant).
Password Administrator Resets passwords, manages service requests, and monitors service health. Password administrators can reset passwords only for users and other password administrators.
User Administrator Resets passwords, monitors service health, and manages user accounts, user groups, and service requests. Some limitations apply to the permissions of a user management administrator. For example, they cannot delete a global administrator or create other administrators. Also, they cannot reset passwords for billing, global, and service administrators.
Service Administrator Manages service requests and monitors service health.
Billing Administrator Makes purchases, manages subscriptions, manages support tickets, and monitors service health.
Global Administrator Has access to all administrative features. The person who signs up for the Azure AD tenant becomes the first global administrator. Only global administrators can assign other administrator roles. There can be more than one global administrator at your company.

More information about the Azure AD administrative roles is available here. These roles can be granted to either Microsoft Accounts or Azure AD accounts.

As mentioned Azure has its own permissions and roles. The only two roles at present is the Service Administrator and one or more Co-Administrators. The users assigned these roles can be either Microsoft Accounts or Azure AD accounts. The Azure Preview portal ( has support for Role Based Access Control (RBAC) which gives more granular control of resources. The users assigned roles in RBAC are also either Microsoft Accounts or Azure AD accounts.

So now we know that you can have two sets of permissions and roles; one for Azure AD and one for Azure. We have also established that to fully manage your Azure AD tenant you need access to the Azure Management Portal, but for that you also need an Azure subscription. You could create a an Azure trial subscription with your Azure AD Global Administrator account, but that might be more than you bargained for and requires registering a credit card and managing that subscription. Or you could add the Azure AD Global Administrator to an existing Azure subscription you have, but that will require you to use an MSA to do the linking and the account must be added as a co-admin, thus granting full access to your entire Azure subscription. This is not a good security practice. You could also manage Azure AD directly with PowerShell, but this would not give you full access to all features.

The optimal solution to this would be to let Azure AD Global Administrators log on to the Azure Management portal without a subscription to manage just Azure AD, or to have a separate portal for just Azure AD, but that is not possible. There is however an option that comes pretty close.

Azure AD only Azure subscriptions

With a special Azure offer code we can sign up for a subscription that does not require a credit card, is not a trial subscription, and that only gives access to Azure AD. Here’s how to do that:

  1. Make sure you use a clean browser or browser tab where you are not already signed in to any Microsoft services, either Azure AD based or MSA based.
  2. Use the following URL:
  3. Select Sign in with your organizational account and sign in with the Global Administrator account of your Azure AD tenant.
  4. Complete the Azure sign up form, note that the only thing you need to do is verify your mobile phone number.
  5. Hit Sign up and you will be forwarded to the Azure Account portal while your subscription is set up.
  6. Hit Portal to be forwarded to the management portal:

You now have access to manage the full feature set of Azure AD in the management portal without having to sign up for a trial or pay as you go subscription. This subscription has the following characteristics:

  • It is a regular Azure subscription
  • It has a subscription ID that can be managed and associated with EA
  • It will not expire or incur charges
  • It can only manage Azure AD services
  • You can assign licenses for Azure AD Basic or Free since these are purchased over licensing agreements as opposed to Azure consumption
  • You cannot create any other Azure resources except those related to Azure AD; these are Directory, ACS and MFA
  • You can add other co-admins and change the service admin from the account portal
  • The account that signed up for this subscription is also the account admin and has access to the account portal

Further steps

Now that you have access to the full management experience through the Azure portal you can add other Azure AD tenants that you want to manage. The only way to accomplish this is to use a Microsoft Account (MSA). The MSA directory (formerly Live ID) is the only directory from which everyone can read user objects, both other MSAs and Azure AD users. This makes it possible to “bridge” two Azure AD tenants and make one MSA, or Azure AD account, a Global Administrator of both tenants. You still need to create a the special type of Azure subscription described in this post though. Here are the overall steps:

  1. Create an Azure AD only subscription for the first Azure AD tenant following the steps in the previous section.
  2. Select or create a suitable Microsoft Account
  3. Make the MSA a co-admin in your Azure subscription
  4. Make the MSA a Global Admin in your Azure AD tenant
  5. Make the MSA a Global Admin of the other Azure AD tenant you want to manage in your Azure subscription. This can be done either by creating another Azure AD only subscription or in the full Azure portal if the Azure AD tenant in question is associated with an existing subscription. Ask an admin for help if needed.
  6. You now have one MSA that is both a Global Admin in your Azure AD only Azure subscription, a co-admin on your Azure AD only subscription and a Global Admin in another Azure AD tenant you want to add and manage from your Azure AD only subscription.
  7. Log in to the Azure AD portal with the MSA
  8. Both directories should now be visible
  9. Since the MSA can read from both Azure AD tenants you can now add Azure AD accounts from one to the other.
  10. Create a user in the second Azure AD tenant that is sourced from the first Azure AD tenant by selecting New User and then User in another Windows Azure AD directory.
  11. Make the new user a Global Administrator of the directory.
  12. If you wish you can now remove the MSA from both directories and the Azure subscription and only use Azure AD accounts.

Azure and RFC3927 IP Addresses

RFC3927’s title is Dynamic Configuration of IPv4 Link-Local Addresses, and it describes how a host can automatically configure itself with an IPv4 address to communicate with other hosts on the same local link, when no statically configured IP address or DHCP server is available. The IPv4 address space set aside for this is Just as RFC1918 defines addresses that can be used for private, routed networks, the addresses in RFC3927 are also private, but even more restricted than those in RFC1918. The addresses from RFC1918 (10/8, 172.16/12 and 192.168/16) will be dropped by any Internet-connected router. The only way to get traffic from a host with an RFC1918 address out on the Internet is through the use of Network Address Translation. On your own network, however, RFC1918 addresses work just as public addresses and can be routed etc. But addresses from RFC3927 will not be routed anywhere, they are what is know as link-local addresses and only facilitate communications on the same link. No router will forward RFC3927 addresses. You can test this yourself by leaving your computer set to receive a dynamic IP from a DHCP server, and then making sure that no DHCP server is available, but that your still have a network link. If your computer is RFC3927 compliant it will configure itself with an address in the range. RFC3927 defines rules for how to choose an address and make sure your host can keep it once other hosts connect to the same link as you, but it is beyond this post to recite the RFC. Now let’s look at how RFC3927 pertains to Microsoft Azure.

In fact, it is very straight forward. RFC3927s addresses are blocked from use in Azure on:

  • Azure Virtual Networks
    Only RFC1918 IPv4 addresses are valid on Azure vNets
  • Local network sites
    Both RFC1918 IPv4 addresses and any public IPv4 addresses you may own, unless they are in conflict with already configured network resources in Azure, can be used.
  • Gateway subnets
    Technically a part of an Azure address space so the same rules apply as for vNets.
  • P2S subnets
    Only RFC1918 IPv4 addresses allowed

The only place in Azure that the RFC3927 addresses are in use is inside S2S VPN tunnels. When you download S2S configuration scripts from the Azure portal you will find references to As in this example for the Cisco ISR template:

int tunnel 1
  ip address
  ip tcp adjust-mss 1350
  tunnel source <NameOfYourOutsideInterface>
  tunnel mode ipsec ipv4
  tunnel destination
  tunnel protection ipsec profile vti

And here on a Windows Server 2012 R2 RRAS server you can see it in the IP properties of the PPP Link adapter:

PPP adapter 23.101.xx.yy:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : 23.101.xx.yy
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Autoconfiguration IPv4 Address. . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 587208029

So in summary, the only place you will find these addresses in Azure are inside your S2S VPN tunnels. Now you know what those strange addresses are doing there…

Quick and dirty DirSync install automation

Here are the steps required to do an automated vanilla install of the latest DirSync tool:

Download the DirSync bits using BITS (the URL always points to the latest version):
Start-BitsTransfer -Source -Destination c:\Temp\dirsync.exe

Install the required .NET 3.5 bits:
Add-WindowsFeature -Name NET-Framework-Core

Install DirSync unattended:
.\DirSync.exe /quiet

UPDATE: Regarding AADSync

Unfortunately this does not seem to work with the AADSync download.

Azure Files and IaaS Domain Controllers

Probably on of the very first VMs you deploy in your Microsoft Azure IaaS deployment are Windows Server Active Directory Domain Controllers. The Active Directory Domain Service is the foundation for pretty much every Windows server application out there, from Exchange to System Center. Running DCs in Azure IaaS works great, just remember that bit about tuning off the host caching on the disk where your DIT is.

At TechED NA 2014 Microsoft announced a new feature called Azure Files, which is currently in preview. In summary it is access to Azure storage over the SMB 2.1 protocol. Until Azure Files, if you wanted to talk to the blog, table or queue storage endpoints in Azure you had to do it via the REST API. Fine for developers, but not easliy accessible for others. What Azure Files does is introduce another endpoint for Azure storage, an endpoint that speaks the SMB protocol. So now if we want to talk to Azure Storage we can access it from any compute instance over SMB and UNC paths. So raw storage over SMB, without the need for a file server VM in between. Think of it as Fileserver-as-a-Service. Read the full announcement from the Azure Storage Group here. I wanted to use Azure Files to store a bunch of data in my lab environment in Azure, but I ran into a problem…

You access Azure Files over a UNC path where the servername is the name of the Azure Files endpoint in your storage account, the username is the name of the storage account, and the password is the access key for the same storage account. Like this:

net use \\\share /u:mystorageaccount <storage account access key>

When I tried to do this on a workgroup VM in Azure it worked great, same with member servers in my lab domain, but on Domain Controllers in the domain I got this error:

System error 53 has occurred.

The network path was not found.

All VMs I have tested are in the same region and affinity group as the storage account, which is also in the same affinity group. I have also tested with a storage account outside an affinity group, but in the same region; same result.

My preliminary conclusion is that “something” in how DCs handle the browsing for the network path is different from member servers or stand alone VMs. I have no root cause yet, I just thought I should write this up so that anyone else experienceing the same would have some information. Sound of in the comments if you have experienced the same or have a solution.


Get every new post delivered to your Inbox.

Join 203 other followers