It is ok and expected behavior. By default, only few required certificates are visible in trusted root store. The rest (there are about 300 roots) are installed on demand, when you face them for the first time. There is a hidden copy of root certificates in Crypt32.dll and on Windows Update. There is nothing to worry about.
I've made internal check ...
The Trusted Root CAs are updated automatically, if the system has Internet access and the feature is not disabled. You can also use certutil to download the trusted root certificates, publish them in a share, and create a group policy to direct systems where to obtain them.
After the upgrades I went over to my Active Directory to check the
functional level and it still says Windows Server 2008 R2.
The Domain and Forest functional levels aren't raised simply by installing Domain Controllers of a later OS version. You need to specifically and directly raise both.
You can raise both to whatever level is supported by your ...
Domain (and Forest) functional levels are never automatically upgraded. Upgrading OSes and prepping the schema with newer versions just gives you the option to do so.
Also, the DFL/FFL setting has no bearing on client compatibility, only domain controllers. It's simply a mechanism to allow you to enable newer AD features.
The Forest and Domain Functional ...
The point of not running unrelated services on a domain controller is that it is a machine that controls security for your environment. If it's compromised you will be in big trouble. In that case it doesn't matter a lot whether it's a Microsoft service or a third-party one that allowed someone access they shouldn't have had.
A better approach would be to ...
Ideally, you deploy in both sites at once and compare the support requests of "it is slow". While geographically distant sites are great for business continuity, that is a large expense you might not want to spend.
"Fast" is 100 ms, "keeps user attention" is 1000 ms. While 65 ms is within budget, that assumes the application remains snappy.
Take just one ...
Well, I don't know about any third-party software to achieve this, but I would simply try with a scheduled task triggered at user logon with a delayed start set to 2 hours.
Put a powershell (or batch if you prefer) script inside to force user logoff, or simply "shutdown /f /l /t 60" (60 seconds before forced logoff).
If you wish to block user from signing ...
Similar question here.
Everyone seems to think that the \tsclient\ is a regular network share. But it is not! It's a feature of Terminal Services service. However, if you find yourself in the position where you must use the mapped drives for installing software, either copy the software first, or map the \tsclient\ first.
To map run this command:
If you want to see the script running, you have to configure the task to run with your credentials AND to run only if you are logged-on.
In the Task Scheduler: open the task properties, go to the General tab. Here, you can select "Run only when user is logged on".
If you don't want to see the script running, you can check "Run whether a user is logged on ...
I turned off dynamic memory for this VM, and the "Hardware Reserved" went away.
Which makes me think that the "Hardware Reserved" was actually that part of dynamic memory that the VM was entitled to, but was not actually allocated to it by the hypervisor, as it was not needed. Not sure if that's what it actually was.
There are dozens of options here. A favorite of mine is to look at the hardware model information on the C: drive if I'm feeling lazy.
If I'm using PowerShell, ( Get-WmiObject -Class Win32_ComputerSystem ).Model
I would give a try with the offline bundle. It often resolve strange issue that the online's bundle can have.
If the first step don't work, you can see the MSI error log too, which can give some hints.