I was recently trying to locate DSC Resources to import into a freshly installed Server 2016 virtual machine and I got errors that made it seem as if I wasn’t even connected to the internet…. but I was.
Generally, I like to locate the resource using the Find-DscResource cmlet and then piping it to Import-Module cmlet. After running the command Find-DscResource -ModuleName xsmbshare, you are asked if you would like to Install the Nuget PackageProvider. If you select “No”, there will be an error stating that the provider is required (Table 1.01). Nuget is an absolute requirement for this command to operate successfully.
On the other hand, selecting the option of YES presents another error which states that there isn’t able to locate a provider with the name “NuGet” as well as other exceptions indicating that the object is unable to be found. The errors indicate that the the provider is unable to be downloaded because the site ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ is unreachable. There is even a command embedded in the error that supposedly resolves the prerequisite but that will also fail. (Table 1.02)
Running the Invoke-WebRequest cmlet with the site from the error returns a success status which confirms that we are able to connect to the site and that there is more to the error we are being presented with. (Table 1.03)
Research points to a rather well known issue with encryption mismatch between server and client systems resulting from TLS hardening. I must admit that prior to having the issue and searching the web, it wasn’t known to myself. Running the following command will show the currently used security protocol:
The results of the command when we ran it returned “SSL3 and TLS1” (Table 1.04)
Running the following command updates the security protocol to an acceptable level:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Running the commnad “[Net.ServicePointManager]::SecurityProtocol” again should now return a value of TLS1.2 (Table 1.05)
Now running the Find-DscResource cmlet should return results (Table 1.06)
This is only a temporary fix and is reserved to this specific powershell session meaning that closing this session and re-opening a new one will result in you having the same error repeated as before.
A permanent fix would be to run the following commands that will add registry keys that will update the security protocol (Table 1.07) :
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
This change is only reflected in future sessions so powershell must be closed and re-opened. Doing so and running the check command again should reveal that TLS, TLS 1.1, and TLS 1.2 are the established security protocols (Table 1.08).
Running the Find-DscResource cmlet should now run without an issue every time a new powershell session is established (Table 1.09). This should be the case anyway with the Nuget provider installed.
I hope you found this fix helpful and that it found you quicker than if found its way to me!