TLS 1.2 not explicitly set in Windows install scripts

[MichaelMcCool]

Older versions of dot net do not use TLS 1.2 or newer by default. Therefore setting the security protocol to 'SystemDefault' will not allow https connections to be made on these devices. Instead TLS 1.2 should be set explicitly and by the protocol ID as this is supported by older dot net installs even when the labels of tls12 or tls13 are not recognized. This is mainly found on server operating systems as there aren't always reasons to update dot net on these devices.

TLS 1.3 is not supported on Windows 8.1/Server 2012 R2 or older, so TLS 1.2 is the only option for these systems. With this being the lowest common denominator for all supported Windows OSes, there is no reason not to use TLS 1.2 for all devices at this time.

One suggestions is to use the following, but older dot net versions do not recognize the tls12 label even though the protocol itself is supported.
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

Instead, a compatible command should be used.
[Net.ServicePointManager]::SecurityProtocol = [Enum]::ToObject([Net.SecurityProtocolType], 3072)

The above sets PowerShell to use TLS 1.2 by its protocol ID. This value is supported in older dot net installations that don't recognize the tls12 label. This also works on newer operating systems as well, so no reason not to use this instead. Older dot net installs are likely to be found on server installations. Since the Archon agent now supports Windows Servers, the install script should be updated to work properly for these edge cases.

Additionally since these deployment scripts are often used in conjunction with a RMM and not an interactive session, the powershell process is likely terminated at the end of the script, so saving and restoring the current Security Protocol value is not needed.