Just ran across an issue where the miniport devices were accidently removed from a system. Not having these installed caused the system to have network driver installation and connectivity issues.
Here are the steps to re-install WAN miniport devices
Step 1: Uninstall WAN Miniport Devices
1. Open Device Manager (devmgmt.msc) and on the view menu select Show hidden devices
2. Under Network adapters, you will see WAN miniport devices (IP, L2TP, Pppoe, PPTP). If you don’t see these, skip to the Step 2 section
3. Open Registry editor (regedit.exe)
4. Browse to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318} and Export this registry subkey
5. Click each of the registry subkeys under this key. Look up the data value in DriverDesc. Find the subkey that corresponds to the miniport device for example, WAN Miniport (IP).
6. Right click the subkey (for example 005), and then click delete. Click Yes to confirm deletion
7. Go into Device Manager and right click the miniport device that corresponds to the subkey that was deleted. Select uninstall and confirm uninstallation
8. Repeat this process for all miniport devices that you need to uninstall
Step 2: Reinstall WAN Miniport Devices
9. Find netrasa.inf in c:\windows\inf
10. Make a copy of this file (netrasa.bak)
11. Open netrasa.inf and comment out the following section:
Before
[ControlFlags]
ExcludeFromSelect =\
SW\{eeab7790-c514-11d1-b42b-00805fc1270e},\
MS_IrdaMiniport,\
MS_IrModemMiniport, \
MS_L2tpMiniport,MS_PptpMiniport,\
MS_PppoeMiniport, \
MS_NdisWanBh,\
MS_NdisWanIp,\
MS_NdisWanIpv6,\
MS_NdisWanNbfIn,MS_NdisWanNbfOut
After
[ControlFlags]
;ExcludeFromSelect =\
; SW\{eeab7790-c514-11d1-b42b-00805fc1270e},\
; MS_IrdaMiniport,\
; MS_IrModemMiniport, \
; MS_L2tpMiniport,MS_PptpMiniport,\
; MS_PppoeMiniport, \
; MS_NdisWanBh,\
; MS_NdisWanIp,\
; MS_NdisWanIpv6,\
; MS_NdisWanNbfIn,MS_NdisWanNbfOut
12. Start the Add Hardware Wizard from control panel
13. Select Yes, I have already connected the hardware, then Next
14. Select Add a new hardware device, then Next
15. Select Install the hardware that I manually select from a list (Advanced), then Next
16. Select Network Adapters, then Next
17. Select Microsoft in the Manufacturer section and then on the Network Adapter, select the desired WAN Miniport device, then Next and Finish the wizard
18. Repeat 13 – 18 for each device you are re-installing
19. After the devices are re-installed, reboot the system
20. Run netsh int ip reset c:\resetlog.txt and reboot the system again (Resetting the TCP/IP stack)
21. Check the network connections in device manager and in Network Connection (ncpa.cpl)
22. Delete c:\windows\inf\netrasa.inf and rename netrasa.bak to netrasa.inf
Just a quick one here.
Sometimes I setup a server and I get everything configured but, forget to enable RDP. So – of course I could login locally to the server and make the change. BUT – I would have to go a different site (or sometimes a different room – Its not that I am lazy… I’d like to think that I am working smarter, not harder 
).
The quickest way to resolve this issue is to change the registry key that enables Remote Desktop directly. I usually have remote registry access to the system because I am an administrator on the system.
- Open up Regedit
- Connect Network Registry
- Select the computer you want to change the setting on (other server will need to be in the domain)
- On the network computer, browse to HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
- Change the fDenyTSConnections to 0
You might need to reboot the computer – I am usually able to get this to work without rebooting.
To remotely reboot a computer type the following
Shutdown –m \\<servername> -r
With Microsoft’s recommendation to use server core for Hyper-V systems, I have been seeing a lot of server core lately. With that in mind, I am posting how I set up a Server Core system (after base OS install).
1. Login to you Windows Server 2008 R2 Server Core system
2. Run sconfig from the command line. This will bring up the Server configuration text user interface shown below.
3. From the Sconfig interface, set the following
- Network Settings (option 8)
- Date and Time (if needed) (option 9)
- Remote Management options (option 4)
- Allow MMC Remote Management (option 1)
- Allow Windows PowerShell (option 2) – asks for reboot
- Allow Server Manager Remote Management (option 3)
- Remote Desktop (option 7)
- Computer Name (option 2) – reboot necessary
- Domain / Workgroup (option 1) – reboot necessary
4. Once the system comes back up, connect to the C drive administrative share (\\<servername>\c$) and copy over Core Configurator 2.0 and the Sysinternals Tool Suite into a tools folder.
5. Run Core Configurator 2.0 – cscript Start_Coreconfig.wsf
- Prompts for installation of the NetFx-ServerCore Feature
- Prompts for installation of the Powershell Feature
6. Select Computer Settings
7. Select Add or Remove Roles
8. Select Microsoft-Hyper-V Role to install – requires reboot.
9. Now you can manage the Hyper-V system remotely with the Hyper-V Manager MMC or Server Manger MMC
Thanks for reading!
-Brent
I have recently come across this issue a number of times and was unable to find any reliable information about this on the web. So, after hours of troubleshooting and some calls with Microsoft, I found the following information.
SYMPTOM:
A Hyper-V Cluster will generate a 0x50 Blue screen during normal operation. This can happen on ANY node of the cluster.
When reviewing the memory dump, you will see something similar to the following in the stack trace:
STACK_TEXT:
fffff880`0c1787d8 fffff800`02150f14 : 00000000`00000050 fffffa80`84a00000 00000000`00000000 fffff880`0c178940 : nt!KeBugCheckEx
fffff880`0c1787e0 fffff800`020ce82e : 00000000`00000000 00000000`e69d9924 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x42837
fffff880`0c178940 fffff880`014e9862 : fffff8a0`20f457c8 fffff880`e6f4f951 00000000`8a0ad368 fffff880`a295d357 : nt!KiPageFault+0x16e
fffff880`0c178ad0 fffff880`014e4a05 : 00000000`ffffffe4 00000000`00000001 00000000`00000000 00000000`00000001 : cng!SHA256Update+0xa6
fffff880`0c178b10 fffff880`08012133 : fffff880`0c179100 fffffa80`6b3d9909 00000000`00000001 fffff880`08012010 : cng!MSCryptHashData+0x65
fffff880`0c178b40 fffff880`08022280 : fffff8a0`20f45780 00000000`00000004 fffff880`0c178cd8 00000020`00000001 : CSVFilter!ShaHash::Hash+0x7b
fffff880`0c178ba0 fffff880`0800d7ed : 00000000`c0000225 fffff880`0c178cc0 fffffa80`a6fe50c0 00000000`00000000 : CSVFilter!CfspVerify+0x30
fffff880`0c178c00 fffff880`08016194 : 00000000`00000142 00000000`00000001 00000000`00000000 fffffa80`70d8ba00 : CSVFilter!CfspGetCfsEa+0x69
fffff880`0c178c30 fffff880`01499027 : 00000000`00000000 fffff880`068c0750 00000000`000000e0 fffffa80`a6fe5160 : CSVFilter!CfsPreCreate+0x18c
fffff880`0c178fc0 fffff880`0149b8ca : fffffa80`87dcd600 fffffa80`87dcd600 fffffa80`669f7b00 fffffa80`64dd5800 : fltmgr!FltpPerformPreCallbacks+0x2f7
fffff880`0c1790c0 fffff880`014b92a3 : fffffa80`bfea9840 fffffa80`bfea9840 fffffa80`bfea9840 fffff880`6d4e6f49 : fltmgr!FltpPassThroughInternal+0x4a
fffff880`0c1790f0 fffff800`023d3807 : 00000000`00000004 fffff800`023f2f30 fffffa80`99ef9440 00000000`00000000 : fltmgr!FltpCreate+0x293
fffff880`0c1791a0 fffff800`023c9c2f : fffffa80`669f7be0 00000000`00000000 fffffa80`8fff6b10 fffffa80`7281f400 : nt!IopParseDevice+0x5a7
fffff880`0c179330 fffff800`023cee4d : fffffa80`8fff6b10 fffff880`0c179490 fffffa80`00000040 fffffa80`613acc90 : nt!ObpLookupObjectName+0x32f
fffff880`0c179430 fffff800`023d5917 : fffffa80`682bf010 00000000`00000001 00000000`00000000 00000000`000007ff : nt!ObOpenObjectByName+0x1cd
fffff880`0c1794e0 fffff800`0237904b : fffff880`0c179960 00010000`00100081 fffffa80`92e0dca0 fffff880`0c179948 : nt!IopCreateFile+0x2b7
fffff880`0c179580 fffff880`0813b81e : 00000000`00000000 fffff880`0c1796a0 fffffa80`682bf010 fffff8a0`09a5e5f0 : nt!IoCreateFileEx+0xfb
fffff880`0c179620 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : srv!SrvIoCreateFile+0x31e
Notice that the CSVFilter is being called, then the cng.sys driver. The BSOD happens directly after that.
After numerous different troubleshooting steps, while working directly with Microsoft, we realized that this BSOD was only happening on the cluster node that was also hosting a Clustered File Share resource.
This Clustered File Share resource was NOT on a Cluster Shared Volume. It was on another disk in the cluster. We believed that we were still within a supported configuration.
After working with Microsoft, this was the supported fix:
FIX ACTION:
Remove the File share resource from the cluster.
After removing the File Share resource from the cluster, the BSOD’s went away, and all was well.
We were told that there would be updated documentation coming to TechNet. I will update this blog when I know more.
The reason why this has an issue is due to the fact that the CSVFilter.sys file system filter driver is attached to all disks in a cluster when Cluster Shared Volumes are enabled for the cluster – not only the disks that really are CSVs.
You can see this for yourself by running fltmc instances
Thanks for reading!
-Brent