Category: Hyper-V

Where is Hyper-V Server 2019? Remote Desktop for Administration Bug & ISO Download Update

C:Amie/ / Hyper-V, Microsoft, Software, Windows Server

*Update* 6th March 2019. For a workaround to create your own fixed Hyper-V Server 2019 installation media, see Create a Slipstreamed Hyper-V Server 2019 installation image with working Remote Desktop for Administration

The release of the Windows Server 2019 family has not gone well for Microsoft. Hitting RTM in September 2018 (1809), the release became available through the different distribution channels (VL, MPN, Visual Studio) from late October 2018. It was promptly pulled from the public domain and re-packaged.

Background

With Windows Server 2019, Microsoft chose to skip the RTM phase and sent the code directly to General Availability (GA). The mainstream Windows Server 1809 branch was blighted – a not necessarily fairly – by a widely publicised data-loss bug. Under some circumstances, Known Folder Redirects under upgrade installs of Windows 10 1809 would erase the  contents of the target. As a precautionary measure, Microsoft withdrew Windows Server 2019 due to it sharing the same code base as Windows 10. Reissuing it, and Windows 10 with fixes on 13th November 2018.

Despite this, there have been a spate of other reported issues in the Windows Server 2019 release. Examples include

Microsoft were vocally chided by the user community for taking until 17th January 2019 to restore the evaluation ISO for the regular release of Windows Server 2019. As well as for failing to comment on the situation with Hyper-V Server 2019. This irked many IT professionals as they lost the Christmas testing period. Interfering with opportunities for initial product evaluation ahead of the New Year. The delay will cause a deferral of adoption in many organisations; being especially true for Exchange Server 2019, which requires Windows Server 2019 as a pre-requisite.

Unlike the Windows Server 2019 evaluation ISO, the Hyper-V Server 2019 did not return and to date (2nd March 2019) it remains unavailable.

 

Hyper-V Server 2019 1809

As with the full version of Windows Server 2019. Hyper-V Server 2019 was only released for a matter of days before its withdrawal.

ISO: 17763.1.180914-1434.rs5_release_SERVERHYPERCORE_OEM_x64FRE_en-us.iso
SHA1: 04B40E7E2FD14C964086C214D6409795908F6887

The availability of the ISO was fleeting for several key reasons.

  1. Hyper-V Server 2019’s shared codebase means that it is impacted by the redirected folders bug. However as a rule, you should not be upgrade installing Hyper-V Server. See my article on upgrade installing Hyper-V Server for reasons why this is not advised.
  2. Remote Desktop for Administration does not work at all in the release [1] [2]. This has been resolved via KB4482887 from 2019-02 Patch Tuesday.
    NB: Don’t forget to enable the firewall rule:
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
  3. sconfig.cmd no-longer loads automatically after joining a domain (this is true on 2019 Server Core also).
  4. When installed in Hyper-V, the Virtual Machine Connection display fails to draw correctly, leading to frequent display corruption.

 

Windows Server 2019 has had a rough start. Many commentators are expressing concerns that Microsoft does not yet possess the experience to successfully navigate the SaaS landscape with Windows. Observationally, QA has been in decline at Microsoft for some years, but up until now we have not seen such deficits impact the mainstream Server ecosystem.

With Microsoft posting a resolution to the Remote Desktop for Administration issue via KB4482887. It is logical that Microsoft will seek to re-release Hyper-V Server 2019 in coming days and weeks. Microsoft for their part have made no comment on the issues with Hyper-V Server 2019, or any planning for its re-release. So this remains speculation, but the community may see it under a 1903 re-packaging hopefully as early as next week.

In the interim, you should continue to avoid using the original release ISO in your test labs.

View: Microsoft Evaluation Centre

Installing Plex Media Server on Windows Server 2016 or Windows Server 2019 Core

C:Amie/ / Hyper-V, Multimedia, Software, Windows Server

System Requirements

  • Windows Server Core
  • Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
  • Plex Media Server

 

The Problem

“Just because you shouldn’t do something, doesn’t mean you can’t”

Plex Server, the sometimes controversial media streaming hub, is a staple of the media diet of many home-brew media centre connoisseurs. I personally keep it installed as a gateway between Smart TV’s and my music/video/photo library as it is a convenient way of getting DLNA support on the network. Where pushed due to lack of Kodi support Plex also gives a consistent alternative front-end user interface.

The problem with Plex Server is that it isn’t quite a “server”. It’s a service, but one that insists on running in the userland (as a tray icon). If you log off from its user account, it shuts down the service and you no longer have a working Plex environment.

 

Why is this a problem?

At home, the only computers that I have running 24/7 are servers and these are exclusively Hypervisors. I want Plex to be always on, but not to be sharing a with VM performing other duties. Neither do I want it be forced to leave a logged-on VM running that does something else and thus increases the attack vector.

To date, my answer has been to run Plex Server in a Windows 10 VM, but this means consuming a £120+ Windows 10 Pro license so that it can effectively molly-coddle a tray icon.

Ah ha! I hear you cry. How is consuming a £900 Windows Server license any better?

It’s not, obviously… unless you’ve got Windows Server Data Centre licenses. If you fall into this category, it literally doesn’t matter how many VMs you install on your hypervisor. The argument is academic as long as your have the horsepower on your server to keep piling on additional VMs.

More commonly however, and perhaps more practically. You may find that you have some old Windows Server 2012, 2012 R2 or 2016 Standard licenses knocking around from recent server decommissions. This may become more common again as your organisation starts migrating to Windows Server 2019.

The advantage of using even a down-version of Windows Server comes in the fact that versions of Windows from 2012 upwards all remain part of the Microsoft Long-term Servicing Branch (LTSB) support model. Consequently, by re-using the licenses your Plex install will receive security patches for many years to come, while remaining lighter than a client edition of Windows and – in the cae of Windows 10 – will save you from the 6-monthly ache of having to Feature Update Windows 10. In other words. Server Core gives you a stable platform to ‘set it and forget it’.

So, for these minority edge cases, an experiment was born to see Plex Media Server could in fact run on Windows Server Core.

 

Why Windows Server Core?

Partly because I’m a stickler for pain and partly because at ~5GB (Windows Server 2019), it represents a considerable disk and resource saving over the ~18GB of Windows 10. My Windows 10 VM Plex Server install, with Windows 10 Pro, Plex and its various database (but no local media assets) weighed in at 33GB (after defragging and compressing). Its RAM utilisation typically sitting between 1.4 GB and 1.8 GB (remember that it’s sitting at a user account lock screen most of the time, but a user is logged on non the less).

This gives us some numbers to define relevant success or failure of the experiment against.

 

How To

The new VM was setup with the following specs:

  • 3 CPU Cores*
  • 1024 MB Startup RAM with dynamic memory between 400 MB and 2048 MB
  • A 127 GB dynamic VHDX
  • Connected to the correct network
  • Set (in my case) to PXE boot and install from my build server
  • Windows Server 2019 Core as the install source

*I find that at 2 cores, Plex rides the CPU at 90% during library updates. With 3 cores, it is usually sub 40% and does make use of the available thread afforded from the extra CPU.

 

Minimising

Firstly, remove any unwanted Windows Features. My build server is configured to enable several features by default, so we’ll strip these off. Fewer features and less services mean a leaner VM footprint. Use Get-WindowsFeature in PowerShell* to view the state of play with yours and remove as appropriate. For example

Remove-WindowsFeature -Name Hyper-V

Remove-WindowsFeature -Name Windows-Defender

* At the comment prompt type “start powershell” and hit enter to launch a PowerShell console.

Simiarly, go through Get-WindowsOptionalFeature -online | ? {$_.State -eq 'Enabled'} to check for more things to disable e.g.

Disable-WindowsOptionalFeature -online -FeatureName <name>

As well as Get-Windowscapability -online | ? {$_.State -eq 'Installed'}

Remove-WindowsCapability -online -Name <name>

… and Get-WindowsPackage -online | ? {$_.PackageState -eq 'Installed'} using

Remove-WindowsPackage -online -PackageName <name>

Note: Do not remove WOW64 from the install as you will require it to run Plex.

 

Preparing

If you aren’t automated, patch it, join it to the domian and make any registry and config changes that you need (such as IP addressing and enabling Remote Desktop).

Decide what account your Plex Server install will run in. Obviously, you’ll be sitting in an administrator account after install, and you don’t want to run Plex in that! I have a user account on the domain that has minimal permissions and access to multimedia shares. You should decide what will work for you.

Set the Windows Firewall so that you can perform remote management. Here are some examples of functions that you may wish to enable (they may differ depending on the Windows Server Edition). We need to enable File and Printer Sharing (SMB) access so that we can copy the Plex installer over to the VM from a management workstation.

enable-netfirewallrule -displaygroup "Core Networking"

enable-netfirewallrule -displaygroup "File and Printer Sharing"

enable-netfirewallrule -displaygroup "Network Discovery"

enable-netfirewallrule -displaygroup "Performance Logs and Alerts"

enable-netfirewallrule -displaygroup "Remote Desktop"

enable-netfirewallrule -displaygroup "Remote Event Log Management"

enable-netfirewallrule -displaygroup "Remote Event Monitor"

enable-netfirewallrule -displaygroup "Remote Scheduled Tasks Management"

enable-netfirewallrule -displaygroup "Remote Service Management"

enable-netfirewallrule -displaygroup "Remote Shutdown"

enable-netfirewallrule -displaygroup "Remote Shut-down"

enable-netfirewallrule -displaygroup "Remote Volume Management"

enable-netfirewallrule -displaygroup "Windows Firewall Remote Management"

enable-netfirewallrule -displaygroup "Windows Remote Management"

enable-netfirewallrule -displaygroup "Windows Management Instrumentation (WMI)"

enable-netfirewallrule -displaygroup "Windows Backup"

Before you can run Plex Server, you will also need to enable Windows Media Foundation services.

Add-WindowsFeature -Name Server-Media-Foundation

Now jump to a Management machine, something with Windows 10 1809 and RSAT installed on it.

On the management machine, open Computer Management from the start button right click or by calling the MSC. Right click on “Computer Management (Local)” at the top of the left-hand pane and connect to the machine by hostname or IP Address. You can now:

  • Manage Task Scheduler
  • View the Event Logs
  • Manage Shared Folders
  • Manage Local Users & Groups

Note: If you are in a workgroup, you need to ensure that the user account and password used to open Computer Management matches the administrator account on the Plex VM. Otherwise you will see ‘Access Denied’. You will also need to have setup WinRM, which is beyond the scope of this article.

 

Auto Log-on

Installing on Windows Server will not change Plex’ behaviour. It will still run as a tray service even though there isn’t a systray to display its icon in. This means that the virtual machine must auto log-on at reboot in order to start Plex Server’s services.

To set auto-logon, from an administrator account add the following registry material.

Note: You can type regedit at the command prompt to gain access to the standard Windows registry editor if you prefer to do it manually.

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v "DefaultUserName" /d "Plex" /f

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v "DefaultPassword" /d "your_password_here" /f

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v "DefaultDomainName" /d "your_domain_here" /f

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v "AutoAdminLogon" /d "1" /f

To test whether you have successfully setup auto-logon, simply reboot the server VM.

Note: The password is inserted in fully readable plain text in the registry. Keep that in mind when designing the security for this account!

 

Install Plex Media Server

Use the following process to install Plex on the new Windows Server Core VM:

  1. Log onto the VM using your preferred Plex user account. For the rest of this article we will call the username for that account “Plex”. This is to create the user account structures.
  2. Download the latest Plex Server installer file from www.plex.tv.
    Note: For some silly reason at the time of writing, the download link is in the page footer with the copyright. It’s almost as if they don’t want you to download it… but I digress.
  3. In file explorer on the management machine, open a SMB share to the VM either using \\<FQDN>\c$ or \\<ipAddress>\c$. Copy the Plex installer file into \\<host>\c$\Users\Plex
  4. Return to the VM via Remote Desktop or your Hypervisor, and ensure that you are logged on as the Plex user account. You should be a command prompt “C:\Users\Plex>”
    1. If your user account is a member of the local administrators group: Type “Plex” and hit tab, it should auto complete the full file name of the Plex installer and hit return e.g.
      Plex-Media-Server-1.14.0.5470-9d51fdfaa.exe
    2. If the Plex account is a standard user: Type “runas /noprofile /user:domain\adminUsername Plex-Media-Server-1.14.0.5470-9d51fdfaa.exe” and hit return.
  5. Should you receive any errors from the installer, you can access the log file via the management machine at the following path to troubleshoot the problem:
    \\<host>\c$\Users\Plex\AppData\Local\Temp

Once the installer has finished, the Launch button will not doing anything as it is attempting to start the default web browser – and there isn’t a default web browser on Windows Server Core. Simply exit the installer to complete the installation.

 

Post-install

At this point you will have the Plex Server binary files installed, however unlike on a GUI install, Plex will not yet function correctly.

 

Drive Maps

Should you need to set up drive maps for media content you can use group policy or create local account mapped shares to your media files using

net use <driveLetter> \\server\share /persistent:yes

 

Auto-Start

Now that Plex is in installed, it is necessary to start its processes. As Windows Explorer (and the startup folder) does not exist to do this for us, you will have to set it up manually.

The obvious way would have been to use task scheduler.

SchTasks /Create /SC ONLOGON /TN "Plex Server" /TR "C:\Program Files (x86)\Plex\Plex Media Server\Plex Media Server.exe"

However, I was unable to get the event to fire at logon and the service never started.

Equally, I was unable to get an auto-run working from HKCU\Software\Microsoft\Windows\CurrentVersion\Run on a non-administrative account, although your mileage may vary if you are using an administrative account.

In the interest of time, the quickest way to achieve this is to use the following procedure:

  1. Log in as a system administrator
  2. Open Regedit
  3. Navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AlternateShell\AvailableShells
  4. Right click on the AvailableShells key, click Permissions…
  5. Click Advanced
  6. Change the Owner to the administrators group and cascade the ownership change to sub-objects
  7. Set the Administrators group to have Full Control of ‘This key and subkeys’
  8. OK back to Regedit
  9. Edit the REG_SZ under AvailableShells so that you add cmd.exe /k “C:\Program Files (x86)\Plex\Plex Media Server\Plex Media Server.exe” into the Value data string e.g.
    cmd.exe /c "cd /d "%USERPROFILE%" & start cmd.exe /c "C:\Program Files (x86)\Plex\Plex Media Server\Plex Media Server.exe" & start cmd.exe /k runonce.exe /AlternateShellStartup"
    Note: The last command (each & is the start of a seperate command) to be executed will be the window on top after the boot completes.

Note: You cannot use SC as a mechanism to invoke the auto-start as Plex requires the user account to functionally access remote file shares. If all of your media is stored locally on the Plex Server VM then technically you could use SC and in this case you would not need to auto-logon the VM at all.

If you log-off and log-on again you should get the Plex Media Server.exe process running in taskmanager.

 

Adding the ability to Shutdown the VM

If you want your non-administrative user to shutdown the VM without having to log-off, log onto an administrator account and then perform the shutdown. You need to modify the local security policy (or Group Policy) to grant your low security account this right.

You can either

  1. Export a modified policy as a template from your management machine in Local Security Policy (Security Settings > Local Policies > User Rights Assignment > Shut down the system) and then import it onto the Windows Server Core VM using secedit /configure /cfg <exportFilePath> /db secedit.sdb
  2. Use ntrights.exe from the Windows Server 2003 Resource Kit Tools and issue the command ntrights.exe -U "domain\username" +R SeShutdownPrivilege

Download: Windows Server 2003 Resource Kit Tools

 

Open Plex

To start using Plex as part of a new install. Return to your management machine and open a web browser and navigate to:

http://<ipAddress>:32400/web/

You should be presented with the beginning of the Plex configuration wizard in your browser. Do not not be surprised if Plex knows who you are based upon your IP address if you are an existing user. You should be able to  sign-in and configure Plex as required based on it being a new install.

 

Migrating your Plex Server

If you wish to migrate an existing Plex Server into the VM, use the following procedure to perform the migration:

  1. Ensure that both source and destination Plex Installs are running the same version
  2. Shutdown the Plex Media Server processes on both the source and destination Plex Installs by entering
    net stop PlexUpdateService
    tskill "Plex Media Server"
    tskill "PlexScriptHost"
  3. On the old server, export the entirety of the “HKEY_CURRENT_USER\Software\Plex, Inc.” registry key and import it onto the new server
  4. On the new server, rename “C:\Users\Plex\AppData\Local\Plex Media Server” to “C:\Users\Plex\AppData\Local\Plex Media Server-OLD”
  5. Copy the “C:\Users\Plex\AppData\Local\Plex Media Server” folder from the old server to the new server. This folder will be very large and the copy will be very slow as it contains a large number of files and folders. In my case some 662,915 files and folders totalling around 18 GB.
  6. Ensure that your old Plex install remains offline
  7. Reboot the new Plex VM
  8. Test
  9. Delete “C:\Users\Plex\AppData\Local\Plex Media Server-OLD”

 

The Results

At the beginning of the article, I outlined that the old Windows 10 VM disk was sitting at 33 GB with typical idle RAM use sitting around 1.4 GB.

After defragging and compressing the virtual disk for the Windows Server Core VM, the VHDX file size was 27 GB; a small improvement. RAM use was also better. Typical idle values of around 550 MB matched library updates sub-720 MB and observed highs around 900 MB.

Boot times for the VM are considerably faster compared to Windows 10, not that it is especially important for media consumption. As an early superficial observation, the library load times between a Smart TV and the Plex DLNA enumeration service appear snappier than under the previous install. I leave that as a subjective and not an empirical observation however.

So is it worth it? The answer to this should depend on your comfort level with managing Windows Server Core. If you want to play with Server Core to learn it, or are already familiar with it, then it is worth considering for the RAM saving alone. The promise of a long-term stable platform under LTSB servicing does allow you to “set it and forget it” and, if like me you are fed-up of contending with large 6-monthly full reinstalls of Windows 10 for no intrinsic gain. It really does offer a streamlined way to host Plex.

With that said, you do lose three practical things by using Server Core and not much else

  1. The omnipresent tray icon which lets shortcut into the web GUI or manually initiate library scans (all of which you can do from the web UI).
  2. The ability to open the web UI on the VM itself is lost.
  3. Being able to troubleshoot with a GUI in Windows Explorer is occasionally useful. You must now use an intermediate management machine/VM to do this. For any admin who already manages Server Core, they will already have this environment. They will also be used to viewing the local server console as a weapon of last resort, not first resort as will be the case with the majority of GUI administrators.

Once working on Server Core, Plex is essentially managed exclusively through the web UI. There are only very occasional needs to interact with Windows Installer on the console during version upgrades. If you want your Plex VM to do something other than just Plex, then it probably isn’t worth considering going down this route. Should you think like a server admin however and prefer task isolation, then why do you need a GUI, Game Bar and Candy Crush saga to server multimedia content to your TVs? If you think like a savvy consumer, why do you need the extra licensing overhead?

Windows NT 4.0 on Hyper-V 2016

C:Amie/ / Hyper-V, Microsoft

System Requirements:

  • Windows Server 2016, Hyper-V Server 2016
  • Windows 10
  • Windows NT 4.0 Advanced Server, Server, Terminal Server Edition, Workstation

The Problem:

For reasons that defy any sane logic, I decided that I needed to install NT 4.0.

It’s 2018 and over the last few years I have been slowly clearing out all of my old IT hardware, to the point now that I no longer have any legacy motherboards or systems in the house or office. So when I recently needed to fire up Windows NT 4.0 once again – for reasons that defy logic – you would assume that Virtualisation was the easy win.

Sadly – and especially with Hyper-V – this is not the case. Microsoft’s virtualisation solution is (and always has been) designed around its currently supported operating systems, with a little Linux added in to the mix in more recent times. Down-level operating systems are not supported and by default, are not going to work. This is especially true of what in effect is Windows 1996, the workhorse wonder that was Windows NT 4.0.

I am sure that the non-masochists of you will just use something like VMWare or Virtual Box to do thy bidding and carry on with their day… but I digress….

Note: This process is will be very similar for Windows NT 3.5 and NT 3.51 as it will be for Windows 2000 – however Windows 2000 does not have the 8GB disk/2GB partition initial size limitation.

The Fix

The following procedure will get you up and running with a working NT 4.0 install under Hyper-V 2016. I am assuming that you know your way around Hyper-V and this article is intended as a results based guide, not a step-by-step ‘click here, go here’ guide.

Create the VM

Use the following configuration when creating your VM:

  1. Create a generation 1 Virtual Machine. In our case this will be “NT 4.0 Server”
  2. Set the RAM to 512 MB (or lower)
  3. You can set it to 1 or 2 CPU cores as required
  4. Do not connect to a network. Remove the default network adapter completely. Add a new Legacy Network Adapter
  5. Create a new virtual hard drive. The drive can be fixed or dynamically expanding, however set the maximum disk size to 2GB or lower. Ensure that both the VHDX and the virtual DVD drive are connected to the IDE bus, not the SCSI bus
  6. Attach your NT 4.0 install CD/ISO to the virtual DVD drive
  7. [If applicable] attach the NT 4.0 virtual floppy boot disk to the virtual floppy drive
  8. Set the required boot order (Floppy or CD ahead of HDD)

Pre-configure Hyper-V

By default, Hyper-V will attempt to run the VM under its default modern architectures mode, compatible with Windows Vista+ systems. The 1996 Windows NT 4.0 code-base is not compatible with modern platforms or CPU instruction sets and if you attempt to boot to the NT text mode installer without addressing this issue, NT 4 will blue screen while attempting to bootstrap the installer.

To fix this, you need to enable the legacy CPU compatibility. This used to be a GUI option in Hyper-V 1.0 under Windows Server 2008, but the option was removed in later releases. Despite being removed from the GUI, the option does still exist in the Hyper-V core and can be re-enabled for the VM using PowerShell.

To enable compatibility mode, open an elevated PowerShell sessionon the hypervisor and enter the following command:

Set-VMProcessor "NT 4.0 Server" -CompatibilityForOlderOperatingSystemsEnabled $true
Get-VMProcessor "NT 4.0 Server"

Text Mode Setup

Boot your Virtual Machine from the floppy/CD and enter text mode and follow through the setup process.

  1. You do NOT need to add any additional mass storage device drivers (this includes the NT 4.0 SP4 ATAPI update, which if you attempt to add the updated driver, the installer will ignore).
  2. When prompted to choose the keyboard layout, language and confirm the computer type. Change the computer type to “Standard PC” for a single core VM or “MPS Multiprocessor PC” if you require access to two cores. Enter your preferred keyboard settings as required.
  3. In the drive partitioning section, create an NTFS partition of less than 2048MB. I would suggest 1024MB for simplicity. Do not attempt to create a larger partition. The reason for this is that NT 4.0 will initially format the VHDX as FAT16, which has a maximum partition size of 2GB. During the later installer process and before entering GUI mode setup, NTFS conversion will be run over the FAT partition, converting it into an NTFS 1.2 file system. You will patch it to NTFS version 3.0 after installing NT 4.0 SP4 or later.

If you receive an installation failure because setup cannot write to the Windows folder or a setup error stating that permissions could not be created, this is most likely caused by you creating the initial VHDX larger than 8GB.

GUI Mode Setup

There are no special requirements or steps to perform during GUI Mode Setup.

Auto detection of the Network card will work with the Hyper-V Legacy Network Adapter. Ensure that you properly configure TCP/IP and remove IPX/SPX from the protocol list (unless you specifically need it).

Post Install

  1. Install SP6a (SP4 at a minimum).
  2. Turn off the machine.
  3. Increase the RAM from 512MB if required.
  4. In Hyper-V Manager/PowerShell edit the virtual disk and set the maximum size to your required size (e.g. the default 127GB).
  5. In Windows Server 2016, locate the VHDX and mount the disk. Using PowerShell or Disk Manager, expand the partition to fill the entire size of the disk.
  6. [1/2] If you want Windows NT 4.0 to turn off automatically when you click the shutdown button (instead of telling you it is now safe to turn off your computer):
    1. Use 7-zip (or similar) and extract the hal.dll.softex file from the SP6a installer, rename it HAL.dll and copy it into C:\WinNT\System32\
      Note: If you are using a multi-processor VM, rename the halmps.dll.softex to HAL.dll and do the same.
  7. Unmount the VHDX.
  8. Reboot the Virtual Machine.
  9. [2/2] If you want Windows NT 4.0 to turn off automatically when you click the shutdown button (instead of telling you it is now safe to turn off your computer):
    1. Add the following to the registry:
      REGEDIT4[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\]
      "PowerdownAfterShutdown"="1"
  10. Install Internet Explorer 6.0 SP1, patch and update the Windows install, install application and configure to your needs.

Things the inexperienced user may not know

If you are playing with NT 4.0 for the first time, then there may be some things that you are not aware of. Here are a list of a few points that are worth noting should you be the Windows equivalent of a millennial (pun intended).

  1. The total install size (less the page file), after patching and cleaning up uninstall data was ~320MB. They don’t make them like that any more!
  2. NT 4.0 does not support plug and play. If you want to add hardware, you have to do it manually via a plethora of different places in the control panel – there is no device manager!
  3. NT 4.0 is extremely insecure by default. Know that it has no built-in firewall and that the base system policy and security configuration is insecure by default (even file system permissions are a free for all). You should keep this in mind when attempting to do anything at all with NT. If it really needs to be on the network you should at a minimum harden system policy and add a firewall (ZoneAlarm Free was the go to back in the day).
  4. There are no display drivers for Hyper-V. This means that there is no mouse integration and as such you will be unable to install NT 4.0 over a Remote Desktop session. It also means that you will be stuck at a max resolution of 800×600 in 16 colour using official means.
    1. Unofficially, you can make use of the great work of the VBEMP NT project to increase the resolution and get NT 4.0 running at modern resolutions and up to ‘True Colour’ (24-bit). This does not offer any cursor integration between the VM and the Hyper-V Manager, preventing mouse use over a Remote Desktop connection and requiring the ctrl +  alt + left cursor to escape the Hyper-V Connection window.
      View: VBEMP NT (tested with NT 4.0 stable version 3.0)
  5. There are no sound drivers for NT 4.0 in Hyper-V (unlike there used to be in Virtual PC) as Hyper-V does not emulate any sound adapters.
  6. The disk performance is fairly poor, until you have patched up to SP6a + the SP6a URP (Q299444). You can further improve performance by enabling DMA Mode on the IDE adapter and write caching on the VHDX.
  7. NT 4.0 by default does not use SMB signing and uses LAN Manager authentication instead of NTLM. It can use NTLM v1/2 once it has been fully patched. However, be aware that this means that it will be unable to communicate with Windows XP SP2+ or Windows Server 2003 in their default configurations. You will have to perform some security hardening on NT 4.0 or security weakening on XP+ to get SMB working. Hint: It’s the same process in the registry on both, so security harden NT 4.0 after installing SP6a.
  8. NT 4.0 ONLY supports SMB 1.0 / CIFS (“SMB 1.5”). Microsoft have been removing support for SMB 1.0 with each successive Windows release. Under Widows Server 2016 and Windows 10 SMB 1.0 support is an optional component/feature that you may need to install manually.
    Note: You should not be using SMB 1.0 at all in 2018 as it is a 100% exploitable security risk.
  9. After you have performed the install, you may be looking for the easiest way to copy SP6a, Internet Explorer, patches and app installers to the VM. To do this as fast as possible without having to pre-harden the OS either burn the updates into an ISO or do it via Guest authenticated SMB by:
    1. Enable the guest account
    2. Create a SMB share on the root of the C Drive and set Guest access to read/write (modify) under NTFS and Share permissions.
      Note: before it is patched, you will struggle to SMB into NT 4.0 using a username and password combination unless you weaken the security policy on the calling client. Using the guest account bypasses the problem.
    3. Use an intermediate level VM/system as a bridge between newer and older SMB versions. For example I used a Windows Server 2008 VM to pull data from third server with a SMB 2.x file share of updates and drop them onto the NT 4.0 SMB 1.0 share found at c:\shared.
    4. Once NT 4.0 is patched, you should disable the guest account again, remove its permissions to the file share and authenticate into NT 4.0 using a normal user account found in the SAM database. Do note my warning above about SMB signing however, which will scupper you unless you have made mitigations via hardening.
Once you have done all of the above, and have a fully patched system. You will have something resembling the below running in Hyper-V 2016.
NT 4.0 in Hyper-V 2016
NT 4.0 on Windows 10 via Windows Server 2016 Hyper-V install

“RPC server unavailable. Unable to establish communication between and ” when connecting to Hyper-V 2008, 2008 R2, 2012, 2012 R2 from Hyper-V Manager version 1709

C:Amie/ / Hyper-V, Microsoft, Windows Server

System Requirements:

  • Windows 10 1709
  • Windows Server 2016
  • Hyper-V Management Console
  • RSAT 2016/1709 for Windows 10 version 1709

The Problem:

After upgrading to Windows 10 version 1709 and installing the updated Windows Server 2016 (version 2016 or version 1709) RSAT tools for Windows 10 1709. On attempting to connect to a down-level Windows Server 2012 R2, 2012, 2008 R2, 2008 Hyper-V Server via the Hyper-V Manager MMC snap-in. You receive the error even though no configuration changes have been made on the Hyper-V hosts:

"RPC server unavailable. Unable to establish communication between <management host> and <Hyper-V host>"

At this point you are unable to manage down-level version of Hyper-V from Windows 10. This issue does not impact the management of remote Windows Server 2016 or Windows Server 1709 Hyper-V instances.

View: Remote Server Administration Tools for Windows 10 (RSAT)

The Fix

This appears to be related to a change in the default firewall behaviour on Windows 10 1709 installs. to fix the problem. On the client system, where you have installed RSAT to remote manage the hypervisor (i.e. not on the hypervisor itself):

  1. Open ‘Administrative Tools’ in the Windows Control Panel
  2. Open ‘Windows Defender Firewall with Advanced Security’
  3. Select ‘Inbound Rules’ from the left hand side
  4. Scroll down until you get to ‘Windows Management Instrumentation (ASync-In)’
  5. Enable the rule for domain/private/public networks as required
    Note: By default the Windows firewall MMC will only display WMI rules for domain and private networks. If you are not running against a domain and Windows has not been explicitly told that you are on a private network, Windows will assume that you are on a public network. Check in network settings in the settings app to ensure that you are not running on a public network, or if you are edit the firewall rule to include public networks. In general, it is a bad idea to open WMI up to traffic on public networks.
  6. Restart Hyper-V Manager

You should now find that you can connect to down-level versions of Hyper-V from Windows 10 1709.