Background: We got a notice a few minutes before last week’s maintenance window that side work to configure a tool ran into a snap. Today we found out that the server intended to be used did not have the right .NET version. Why did they not just install it? Good question.
This made me curious about which of the 114 servers have which version. So I found a Stackflow post on identifying .NET version. I then wrote this Powershell wrapper script around one of the solutions. The one I picked looks at the registry keys.
# Get my list of servers
$computers = Get-Content ‘server_list.txt’# Contact each server in the list in order before moving on to next
foreach ($computer in $computers)
{
# Remote connect to current server
Invoke-Command -computername $computer -scriptblock {
# ID host name
$remotehostname = c:\windows\system32\hostname.exe
# Find largest .NET version
$dotnet = Get-ChildItem ‘HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP’ | sort pschildname -des | select -fi 1 -exp pschildname
# Write hostname and .NET version
Write-Host “$remotehostname == $dotnet”
}
}
The foreach loop essentially forces the Invoke-Command to do the test in order. This is slower as it contacts the remote server, does the commands, then closes the connection. Without it, servers would respond at about the same time and the output reside on the same line and out of order.
Probably there are better ways to do this, but I am just a beginner.
Also on the Stackflow page there are better approaches. Because uninstalling .NET does not remove the registry keys, this method is vulnerable to be incorrect. I guess that is a possibility.
Oh, on which have what: 22 have .NET2, 48 have .NET3.5, and 44 have .NET4. Not consistently obvious factors like version of the application, life cycle tiers, or anything obvious explain why which have what. Though, they do tend to be the same version within the same cluster of servers.
Leave a Reply