Thursday, May 21, 2020

Unable to Install Azure Powershell Module

I had an issue where i was unable to install the Azure PowerShell Module on Windows Server 2016.  When attempting to install the module the following error was experianced.

PackageManagement\Install-PackageProfider : No match was found for the specified search criteria for the provider 'NuGet'. The package provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.

To fix this issue i needed to enable Strong Crypto on the .NET framework to ensure TLS 1.3 was supported.  This was done with the following commands.

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type Dword
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type Dword



After making this change, we were successfully able to install the Azure PowerShell module.

Tuesday, May 5, 2020

Direct Access not working with Windows Firewall Enabled on Client

We had an interesting issue with Microsoft Direct Access on Windows 10 latest build 1909.

  • When Windows Firewall is disabled, Direct Access works on the client.
  • Enabling Windows Firewall on the client breaks Direct Access resulting in no connection.
Symptoms of Issue

Here is the symptoms we were receiving:

Get-DAConnectionStatus returned "CouldNotContactDirectAccessServer"

netsh interface httpstunnel show interface shows the Interface is Active

IPHTTPS interface active
Last Error Code 0x0

The issue appears to be with Name Resolution Policy Table (NRPT).  When Windows Firewall was enabled on the client, you were able to ping IPv6 addresses on the Direct Access server through the tunnel but all name resolution failed.

For example, you can ping the tunnel endpoints discoverable using the Get-DAClientExperianceConfiguration cmdlet on the client.  You can also ping IPv6 addresses of hostnames previously resolved when the Windows Firewall was in a disabled state.  For example, whilst Windows Firewall was in a disabled state, ping domain.local (your AD forest name), copy the IPv6 address, re-enable Windows Firewall and you will notice you can resolve it by the IPv6 address, not by hostname using NRPT.


The issue was caused by Windows Firewall set to a disabled state on the server.

What we found was when the Windows Firewall is disabled on the server, Windows Firewall must be disabled on the client.

If DA Server Firewall is disabled, but DA client Firewall is enabled - Direct Access breaks.
If DA Server Firewall is enabled, but DA client Firewall is disabled - Direct Access breaks

You must have Windows Firewall disabled on both the DA Server and DA Client, or enabled on both the DA Server and DA Client.

We also identified another issue on the DA server with regards to Windows Firewall being disabled.  In our environment, disabling Windows Firewall on the DA Server breaks Direct Access reporting in the "Remote Access Management" console.

As a result, it is strongly recommended to keep Windows Firewall enabled on both the DA Server and DA clients.