Tuesday, December 19, 2017

PowerShell cmdlet to query .NET Framework version


Whenever I'm doing new installs of Exchange, I'm annoyed when I need to figure out the .NET Framework version installed based on registry keys. You can see the documentation here:
 Just like the bad infomercial says: "There's got to be a better way!"

This has bothered me for sometime and I considered writing a small script to query and display the version. Then I thought...that would be good if I put it in the PowerShell Gallery so that I could easily access it from anywhere. Then I thought...I'm probably not the first person to have this idea.

In the PowerShell gallery, Joakim Borger Svendsen has been kind enough to create this for us as a module named DotNetVersionLister. He's also kind enough to keep it updated. There have been seven releases in 2017.

On a computer that has Internet access, you can install directly from the PowerShell Gallery:
Install-Module DotNetVersionLister
You can also save it to file for distribution to computers that don't have Internet access by using:
Save-Module DotNetVersionLister -Path C:\Temp
After you install the module, you have a single cmdlet named Get-DotNetVersion. This cmdlet is quite flexible and allows you to query the .NET Framework version from the local computer and remote systems. For remote systems, it can query the information using remote registry access or PowerShell remoting. So, it's flexible depending on your configuration.


 
Query the .NET Framework version from the local computer:
Get-DotNetVersion -LocalHost
Query the .NET Framework version from a remote computer via remote registry:
Get-DotNetVersion -ComputerName Exch01
Query the .NET Framework version from a remote computer via PowerShell remoting:
Get-DotNetVersion -ComputerName Exch01 -PSRemoting


Related links:
 

Tuesday, December 12, 2017

Docker Fails to Start on Reboot

For the last couple of weeks I've been working with Windows containers using Docker. I ran into a severe problem with the networking. I created a transparent network on the host and rebooted. After reboot, the docker service wouldn't start and had the following error in the event logs:
Log Name:      Application
Source:        docker
Event ID:      4
Task Category: None
Level:         Error
Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to get endpoints from store: failed to decode endpoint IPv4 address () after json unmarshal: invalid CIDR address:
My first fix for this issue was to delete the following file:
  • C:\ProgramData\docker\network\files\local-kv.db
After this file was deleted, I was able to start the Docker service and it stayed running. That file was recreated when the docker service started and I was able to run docker commands.
 
Running docker network ls showed me that a transparent network I had created just before the restart was broken. That network was renamed a long random string. At this point, I could delete the randomly named transparent network, but a new one came back after each restart of either the Docker service or the host.

The final fix to stop that recurrence was running:

.\WindowsContainerNetworking-LoggingAndCleanupAide.ps1 -Cleanup -ForceDeleteAllSwitches

That script is provided by Microsoft on GitHub here:
It's also worth noting that others are also having this issue: