You may observe the following error on Windows Server 2016 immediately after OS startup:
This “has stopped working” part tells us that some unhandled exception occurred, so we can switch over to Event Viewer to find some more details about it:
Exception details are the following:
Faulting application name: svchost.exe_CDPUserSvc_65df7, version: 10.0.14393.0, time stamp: 0x57899b1c Faulting module name: cdp.dll, version: 10.0.14393.1715, time stamp: 0x59b0d38c Exception code: 0xc0000005 Fault offset: 0x0000000000193cf5 Faulting process id: 0x1b14
After quick research I found out that this error was introduced with some Microsoft updates and to resolve it on Windows Server 2016 14393.1884 you just need to apply another update 🙂 More specifically you need to install KB4053579, which can be downloaded from Windows Update Catalog. Applying this update resolves this error.
I’ve recently spent some time exploring Windows Nano Server installation option and wrote detailed blog post for StarWind blog entitled “Windows Server 2016 Nano Server – Just enough OS model” you can read it here. Article covers Nano Server basic concepts and compares this installation type with conventional Full Server and Server Core installation options – if you find this topic interesting please read on @ StarWinds Blog.
All to often I see people doing wrong corrective action whenever they encounter “The trust relationship between this workstation and the primary domain failed” error, it seems that even some Microsoft documentation gives you bad advice. What you have to do if you got this error is use proper resolution methods instead of lengthy and wrong join workgroup, then join to domain again approach.
In case you working with multiple VMs joined to domain and play with snapshots you may very likely run into this error at some point. Here is the screen shot:
This error caused by the fact that your computer account secure channel is broken. All computers joined to domain have SID along with their “username” and password albeit you never touch or input those things in any explicit way. Un-join and re-join again to domain procedure will create new SID for your computer which may be not the thing you want. When you log on to domain with user name and password secure channel is being established, but it can be broken in the following scenarios:
Machine was offline more than 30 days since last computer password reset (it happens automatically for machine approximately every 30 days when it is online)
OS was reinstalled (this process creates new machine SID)
LSA on the machine is out of sync
Key thing to remember when you got this issue is never join workgroup and then to domain again as this process creates new SID and your machine will lose all its group memberships (if it had any, of course).
ADUC > Reset Computer, then rejoin machine to domain
nltest (no rejoin or reboot required): nltest /server:COMPUTER_NAME /sc_reset:domain\domain_controller_name
PowerShell way: Test-ComputerSecureChannel -Repair (no rejoin or reboot required)
I strongly recommend you to remember option 4. So if you see “The trust relationship between this workstation and the primary domain failed” you know that secure channel is broken, you just logon as local administrator on this machine and run this:
Just a quick how to post. When you do more and more remote management with PowerShell it may be necessary for you to quickly check if you run Full Server or Core or Nano. And unless you never logon locally to the box you and you only managing it via PowerShell then you may be not very sure if it is running Full Server, Minimal Management Interface, Core or Nano. There is a ServerLevel registry key available starting from Windows Server 2012, and quick look up for its value will answer this question:
dir 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Server\'
Sample output you may see in case of Nano Server:
Another use case for this key is when you writing a script and need to adjust its behavior depending on whether it is being executed on Full Server, Core or Nano.
Recently I imported some old VM into my Windows 10 Hyper-V and noticed that unlike VMs I created with latest version of Hyper-V it has an extra option named “Upgrade Configuration Versions..”:
To me option name is a bit confusing (which sometimes happens in MSFT products out of best intentions in attempts to simplify their wizards and wording). I was confused by this option name as it makes me think about configurations versioning and management rather about what it really means. To put it simply it is equivalent of what you can see in VMware Workstation as “Upgrade Virtual Hardware”/”VM hardware compatibility” (isn’t it more appropriate name? but I guess there is also differentiation needs which software vendors may have 🙂 ).
What you should know about this is in the past (prior to Windows 10) your VMs have been upgraded automatically to new configuration version, but now you have more control over this and have upgrade it manually via GUI (see screenshot above) or using Update-VMVersion cmdlet.
“Upgrade Configuration Version…” option presented in VM properties only when your VM is in offline state. Operation is almost instant and unfortunately it doesn’t give you that VMware Workstation wizard which explains available versions and why you may want to upgrade/added features. But essentially Hyper-V no longer upgrades VMs by default to allow you to move them back to older versions in case it will be necessary and upgrade is needed to enable new features for VM (see table below):
Virtual machines created on Windows 10 use version 6.2 configurations, and the highest value for now is 8.0 (Served 2016/Windows 10 Anniversary update). You can use this table to get an idea of configuration versions in different base OS versions:
To check configuration versions of VMs on your Hyper-V host:
Get-VM * | Format-Table Name, Version
To get configuration version supported by your host use (add –Default parameter to see default one):