Error 0x80070001 on Windows 10 when trying to install a new app

This is slightly off topic for me, but because I spent quite a bit of time on figuring it out and could not find this documented anywhere else, I thought I would write it up quickly.

At some point I could no longer install any new apps from the Windows Store on my Surface 3 Pro Windows 10 machine. Apps already installed would update fine, but new ones could not be added. The error was:

“Try that again. Something went wrong. The error code is 0x8007001, in case you need it”.

If we translate that number to a human readable form we get:

Incorrect function.

Not much to go on. I initially thought this was something to do with either the modern app framework or Windows installation and tried things like resetting the store with (WSReset.exe) and scanning the system files with SFC.EXE. None of these things helped. In the end it turned out that is was related to my SD card. I had an  SD card installed and had previously moved a few apps to it. Apps that were so large that I didn’t want them eating up my system drive. Moving these apps somehow caused all new apps from then on to try to install on the SD card, or at least rely on it for something during the install. I shut down the computer, removed the card and could then install apps again. At this point I also reinserted the card and could now also install new apps with the card inserted. Some setting somewhere had obviously been changed. I do not know the root cause of this behavior, which is always annoying, but I am prepared to accept that I made it work.

Updating already installed apps worked because they were all on the correct (C:) drive. The default install location for apps was also set to the C: drive, which makes this even stranger…

Hope this helps someone. Happy installing!

Obtaining the latest setup binaries for the OneDrive Next Generation Sync Client

Microsoft is working on creating a unified OneDrive Windows sync client for both consume OneDrive and OneDrive for Business. This is very good news and you can read all about it here.

But the download links on the Office support pages are not for the latest version of the Next Generation Sync client (ODNGSC). At the time of this writing the latest version is 17.3.6349.0306, but the download link is for 17.3.6302.0225.  So why does this matter? The ODNGSC updates itself as part of an Office 2016 update cycle or individually. When you deploy the client you might have some issues that are blocking you, stopping you from completing setup. If that is the case the client cannot update itself, because initial setup has not been completed. So you can’t get the version that might fix your setup problem. Catch 22.

To work around this and perform initial setup with the latest ODNGSC, do this:

On a machine that has the latest version, navigate to:

%LOCALAPPDATA%\Microsoft\OneDrive\Update

In that folder you will find the setup file (OneDriveSetup.exe) for the latest client. If you look in the Update.xml file in the same directory you will also find the URL of where that client was downloaded, something like https://oneclient.sfx.ms/Win/Team/17.3.6349.0306/OneDriveSetup.exe.

New preview version of Azure AD PowerShell available (Yes, it now supports ADAL!)

I guess the title says it all!

Here is the link to the Microsoft Connect site to download:

http://connect.microsoft.com/site1164/

Connect-MSOLService now brings up the familiar ADAL prompt with MFA and ADFS support etc. Make sure to read the release notes included, and you should probably uninstall the Microsoft Online Sign In assistant.

Here are the changes:

  • Dependency on the Microsoft Online Service sign in assistant removed.
  • Name of module updated Windows Azure -> Microsoft Azure
  • Connect-MsolService parameter -CurrentCredentials removed.
  • Connect-MsolService parameter -AccessToken added to enable AAD Connect, and other callers to use the PowerShell as a client library.
  • New device management cmdlets:
    • Get-MsolDevice
    • Enable-MsolDevice
    • Disable-MsolDevice
    • Remove-MsolDevice

Few apparent changes in the list of installed products though:

Before:

aad_ps_adal_before

After:

aad_ps_adal_after

Morgan

Office Modern Authentication (ADAL) and Autodiscover

The introduction of Active Directory Authentication Library (ADAL) support in Office 2013 and Office 265 ProPlus is great news. The Office suite of applications is now able to take advantage of advanced authentication options like federated SSO and MFA. Using ADAL with Office is referred to using Office with modern authentication. Modern authentication was recently made available to everyone and all you need to do to start using it is add three registry keys. You can find all the information you need here:

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

I recently ran into a problem with using ADAL in Office, which I think is a bug. When you try to connect to a new mailbox in Outlook using Autodiscover, and who doesn’t, Outlook is unable to successfully connect to the mailbox. From my testing, this problem is present in version 15.0.4693.1002 of Office 2013/365 ProPlus (a.k.a. March 2015 Update), which is the first version to include ADAL support.

You can look at the change log for Office here: https://support2.microsoft.com/gp/office-2013-365-update

Check your Office version by going to File\Account and looking at Product Information:

image

The problem manifests itself when using the Account Setup Wizard.You enter your name, email address and password. Outlook queries Autodiscover DNS records for your domain. When your settings have been discovered you are asked to authenticate against the service. This authentication does not used ADAL in my experience, but displays an old fashioned authentication prompt. However, because of the bug, you will never get this far. Instead the wizard will inform you that it cannot find your settings.

To fix this, simply update to the latest version of Office. The most recent update, at the time of this writing, is version 15.0.4711.1003 (a.k.a. April 2015 update).

None of the fixes in this update specifically addresses this problem, as described in this post, but there is some mention about not being able to add a new account if your are using ADAL in Office and the account uses basic authentication in this KB article:

https://support.microsoft.com/en-us/kb/2965218

  • When you enter incorrect credentials for an account that makes some mailbox connections use Active Directory Authentication Library (ADAL) authentication and some connections use basic authentication, you are not prompted to enter credentials again, and Outlook cannot connect to mailboxes by using basic authentication.
  • When you enable the Active Directory Authentication Library (ADAL)-based authentication for Outlook 2013, you may be unable to add Office 365 accounts that use basic authentication. If you have enabled the ADAL-based authentication for Outlook 2013 that has an Office 365 account configured and the account uses basic authentication, you cannot connect to the account.

Anyway; updating resolves the problem.

RunAs Radio Azure RMS Podcast

I just spent half an hour talking to RunAs Radio host Richard Campbell about Azure RMS. The show will go live on May 13th.

RunAs Radio is a weekly Internet Audio Talk Show for IT Professionals working with Microsoft products. The full range of IT topics is covered from a Microsoft-centric viewpoint.

I was not aware of RunAs Radio myself but they have a lot of great content, and are now on my list of podcasts I subscribe to, If you are are a technologist interested in Microsoft products I highly recommend you do the same!

http://www.runasradio.com/

Thanks to Richard and everyone else at RunAs Radio for having me on the show,

When configuring the Azure Load Balancer for Remote Desktop Gateway…

make sure you DO NOT enable Direct Server Return on your endpoint Load Balanced Set:

image

In November of 2014 support was added for Source IP Affinity (also known as session affinity or client IP affinity) in the Azure Load Balancer. Before that it was not compatible with Remote Desktop Gateway. You could sort of load balance your RDGWs but it required you to put every RDGW server in its own cloud service and the use Azure Traffic Manager to load balance. With this approach you could not put your RDGW servers in the same availability set, so you had no guarantee that your gateways would be distributed across fault and update domains. Boldly, or foolishly, depending on your point of view, I decided to try anyway to use the Azure Load Balancer for RDGW, even though I knew it was not supported. Of course it did not work, but when eventually support was added I ran into problems.

After client IP affinity support was added to the load balancer I reconfigured my endpoints of my RDGW VMs:

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName "RDGW HTTPS" -Protocol tcp –LocalPort 443 -ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution "sourceIP"

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName "RDGW UDP" -Protocol UDP -LocalPort 3391 –ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution "sourceIP"

The sourceIP value in the LoadBalancerDistribution parameter is the critical one and it can only be set through PowerShell.

But still no connections… I tried all sorts of things. Since this had never worked I didn’t know if it was failing because of a misconfiguration or something in the Load Balancer. The only difference in setup I could find was that  my load balanced endpoints had Direct Server Return enabled. This was something I had decided to try back when I first set it up. There was not much documentation back then about what Direct Server Return actually did. But now there is a description in the portal:

DIRECT SERVER RETURN

Direct server return configures a virtual machine’s endpoint for the floating IP capability required to configure a SQL AlwaysOn Availability Group. This setting is required when using the SQL Always On Availability Groups in SQL Server. This setting can’t be changed after you create the endpoint.

So, not for RDGW at all…

Unfortunately you cannot disable DSR without deleting and recreating your endpoints. After removing and adding them again I was able to connect through the load balancer.

Since traffic to a particular instance behind the load balancer now is determined by the source IP, all traffic from the same IP goes to the same instance, you might experience an uneven distribution of load. Clients behind a proxy or NAT router will all end up on the same instance.

More information:

BTW I wish the Remote Desktop PG would stop putting all their guides in Word docs, would be so much better on a web page…

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:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability
BranchName    REG_SZ    fbl_impressive
ThresholdRiskLevel    REG_SZ    low
ThresholdOptedin    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability\RecoveredFrom
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 http://aka.ms/vmagentwin. 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: https://morgansimonsen.wordpress.com/2015/02/16/how-to-install-the-azure-operational-insights-agent-on-an-azure-vm-using-powershell/

Customized claims in ADFS

Introduction

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 == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("http://langskip.no/employeeID&quot;), 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 (https://langskip.no/employeeID) 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 == "http://langskip.no/employeeID"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = "350-00" + c.Value);

Next we check for the existence of an incoming claim of type http://langskip.no/employeeID. 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
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier 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:

Enjoy!