Brent Caskey

Re-installing WAN miniport devices

Brent Caskey — Thu, 09 Jun 2011 22:13:11 GMT

Originally posted on: http://geekswithblogs.net/BrentCaskey/archive/2011/06/09/re-installing-wan-miniport-devices.aspx

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

Remotely enable RDP

Brent Caskey — Fri, 03 Jun 2011 03:14:47 GMT

Originally posted on: http://geekswithblogs.net/BrentCaskey/archive/2011/06/02/remotely-enable-rdp.aspx

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

Setup a Windows Server 2008 R2 Server Core system for Hyper-V

Brent Caskey — Fri, 03 Jun 2011 01:45:43 GMT

Originally posted on: http://geekswithblogs.net/BrentCaskey/archive/2011/06/02/setup-for-a-windows-server-2008-r2-server-core-system.aspx

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.

You can download Core Configurator 2.0 from http://coreconfig.codeplex.com/
You can download the Sysinternals Suite from http://technet.microsoft.com/en-us/sysinternals/bb842062

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

About me…

Brent Caskey — Tue, 31 May 2011 18:22:20 GMT

Originally posted on: http://geekswithblogs.net/BrentCaskey/archive/2011/05/31/about-mehellip.aspx

My name is Brent Caskey and I have been in IT since 1999. I currently work for Dell in the Support Services group. The posts that you will see here are either related to cases I have worked or something that I have seen in the lab. I currently support Hyper-V, Windows Clustering, Exchange Server, and Windows Core Services (AD, DNS, RDS, etc.). If I’m not working on a customer case, then I am teaching or developing a training class. Currently I’m teaching Exchange Server and Hyper-V classes that I have developed.

In November 2010, I achieved the Microsoft Certified Master certification in Directory Services. I have taken and passed 30+ Microsoft certification tests and hold 5 MCITP, 3 MCSE, and 11 MCTS certifications. I also have a VCP in 3.5 and 4.0 and a current CCNA.

Blogging is something that I have thought about doing for some time now but, just decided to take the leap into it now. Hopefully, what I post will help the IT community. I am planning on posting the really interesting issues I come across in addition to some how to troubleshoot, and just general how to articles.

Please let me know what you think.

Thanks for reading!

-Brent

STOP Code 0x00000050 ( 0x50 ) pointing to cng.sys on a Hyper-V Cluster

Brent Caskey — Fri, 27 May 2011 20:34:55 GMT

Originally posted on: http://geekswithblogs.net/BrentCaskey/archive/2011/05/27/stop-code-0x00000050--0x50--pointing-to-cng.sys-on.aspx

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