Tag: windows

MSTSC and RDCMAN Crashing?

For the last 3 days we have had issues connecting with RDP through our Remote Desktop Gateway. I’ve used both RDCMAN (Remote Desktop Connection Manager) and plain MSTSC where it’s crashing. It’s been happening quite regularly with the latest build (10041) of Windows 10 but also with a Windows 8.1 client.

In my case it’s sometimes been possible to connect to some of the servers but not others. And I’ve at times been able to stay connected for shorter periods (5-30 sec) before the client crashed.

I did a quick usermode debug of the crashing application and found out that in both cases it’s a DLL file for MSTSC that’s causing the problem and it’s related to UDP Traffic.

Disabling UDP in the Remote Desktop Gateway seems to solve the problem short term. I’ll have to look into it more in depth later on, but for now I’m at least able to keep on working.

RDP Connection Crashing

 

 

Recommended hotfixes for Windows Server

A great article listing all known issues and available hotfixes for Windows Server 2012 R2 Hyper-V Network Virtualization;

KB:2974503 – Recommended hotfixes, updates and known solutions for Windows Server 2012 and Windows Server 2012 R2 Hyper-V Network Virtualization (HNV) Environments
http://support.microsoft.com/kb/2974503/

Another fantastic source of information is Hyper-V.nu that always keeps a list to the latest updates for Windows Server (Cluster and Virtualization) here; http://www.hyper-v.nu/hotfixes/

 

Reduce DNS Client Cache in Windows Server 2012 R2

I’m often using Remote Desktop Gateways to connect to various environments, including our Private Cloud. One challenge arises when I change IP-address or network settings on a computer through SCVMM. As the RDGW has cached the DNS entry and IP Address, it takes a while until that information is cleared and I’m able to eastablish a connection. Or to be fair, what I usually do is RDP into the RDGW and does a “ipconfig /flushdns” and then reconnect the first server.
It does work, but wouldn’t it be better if that was kind of done automatically. Well, I guess you could schedule a “ipconfig /flushdns” every X minutes and get the desired result.

A better solution is to reduce the DNS Cache timeout on the RDGW server! I’ve modified mine to cache entries for just 10 seconds, and then do a new DNS query.  10 Seconds might be a bit too aggressive though it works fine for me.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters maxcacheTTL
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
maxcacheTTL

Use this registry key to set the DNS Client Cache timeout;

Restart the “DNS Client” service to take effect. (net stop dnscache & net start dnscache).
I’ve only tried this on Windows Server 2012 R2, but I guess it should also work on Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.

Personally, I’ve set this key through Group Policy Preferences to make sure it’s always done, even if the RDGW Server is reinstalled.

The other two values; MaxCacheEntryTtlLimit and MaxNegativeCacheTtl are leftovers from my testing, it seems those values worked for “Windows 2000” and are not used anymore.

 

Bugcheck: DRIVER_POWER_STATE_FAILURE (9f)

I experienced a Bluescreen of Death (BSOD) on my Windows 8 Laptop (HP EliteBook 8560w) this morning when it resumed from Hibernate.
I quickly launched WinDBG and opened the crashdump.

WinDBG managed to find the driver that caused this problem by itself this time. But IF WinDBG had not been able to show me the faulty driver, the next step would have been to use the Bugcheck info (0x0000009f) to dig further into this;

The last argument is the interesting one, and which we should look into further with the !irp command.

It will show something similar to this. And it’s the e1c63x64.sys driver that were active at the time of the bluescreen. Same info as !analyze -v managed to figure out by itself.

Hmm, so what driver is that?

intel_driver1Too bad that it were unable to provide more detailed information. But some oldschool properties of the \SystemRoot\system32\DRIVERS\e1c63x64.sys file gave this;

And a quick search on Intel’s Support sites showed that there was a newer version available for my NIC;
Intel(R) 82579LM Gigabit Network Connection here.

Driver updated, and hopefully no more bluescreens due to this driver bug.

 

Howto get NAP with Server and Domain Isolation to play together

If you are trying to get NAP (Network Access Protection) and SDI (Server & Domain Isolation) to play nice, you might not get the results you are expecting. I’m going to explain howto get NAP with Server and Domain Isolation to play together

There are plenty of Blogs and Guides out there, explaining how to get either NAP or Server and/or Domain Isolation to work. And that’s basically no problem so I won’t cover that here today.
But I’ve so far not found anyone who’s tried to combine both technologies.

Background

First of all, some background for my environment. I’m working on a project where we want to implement NAP to get the health check, but also Server and Domain Isolation to make sure that only trusted clients and users can talk to the systems they have access to. There was no doubt that we would use Certificates to validate the client health state.

NAP with Server and Domain Isolation PolicyTwo Windows Server 2008 R2 Servers with HRA/NAP Roles and the Stand-Alone CA Role were installed for redundancy. Clients are getting the Health Certificates and all is good. The SA (Security Associations) policy on the servers and clients is configured to “Require Inbound and Request Outbound Authentication”, with a requirement for a Health Certificate from the organizations CA Servers. So far, so good.

The clients can now access the server when they have a valid health state, and are unable to access the server if they don’t. Yay! NAP works.

And the nice thing is that since the HRA only serves Domain Joined clients. As the servers won’t talk to any client without a Health Certificate, and only Domain Joined client can get one, we have also got “Domain Isolation”. Ok, two out of three check boxes done.

Now, try to use Server Isolation and configure a Firewall Rule to only allow ClientA to talk to connect to ServerX via RDP. That does not work. Well, it does work to create the rule, but it will never allow the traffic.
The reason is that when you use a NAP Certificate to authenticate the connection, there is no mapping to the computer account. Which makes it impossible to use a Computer Based rule.

NAP with Server and Domain Isolation - Security Associations

Notice “No Authentication”.

Okay, so if you use the check box NAP with Server and Domain Isolation - Certificate Mapping“Enable certificate to account mapping”?

Sorry, that doesn’t work either. When you use the Health Certificate feature, no certificate mapping is done in the Windows Firewall. This has been verified in the Windows source code.

This blog post does state that it should be possible to use that check box and then use a Policy  “Access this computer from the network” where you can specify which computers are able to access the server over the network. But it’s still “All or nothing”. You can’t specify that ClientA should be able to access the SQL Server but nothing else.

Solution for NAP with Server and Domain Isolation

Luckily, there is a kind of workaround. To be honest, it’s not that common that you want to restrict so only ClientA, ClientB and ClientC can access the SQL Service on ServerX. I would dare to say its more common that you want to restrict which Users can access the service. Right?

I want to control so UserD, UserE and userF can access the RDP (Remote Desktop) Service, from any Health Domain Joined Client. It doesn’t really matter which client they connect from as long as it’s healthy and domain joined. Or I could control which clients they are able to logon to.

So by using a “Secondary Authentication” NAP with Server and Domain Isolation - Secondary Authenticationoption, where we Authenticate the User, like this.
Still the same options for the Computer Authentication. Just add a Secondary Authentication on the SA for User (Kerberos v5). It’s then possible to restrict which users are able to connect to a specific service.

In your firewall RDP Rule, configure it to Require a secure connection, and specify which users should be able to access the service. Now try to connect with two different users via RDP. You should see how the rule is applied and works.

I decided to create a Firewall Rule for RDP that only allowed “TestUser” to connect to the service.
In the screenshot below, the upper RDP is started with the TestUser Account, while the bottom RDP Client is started with “Runas Domain\Administrator” which according to the rule, should not be allowed to connect. And as you see, it’s not able to connect, which is expected.

NAP with Server and Domain Isolation - Proof that it works

Summary

To get NAP to work with Server Isolation, you have to enable “Second Authentication” for the User with Kerberos Authentication, so there is Authentication done when the connection is established. Which in turn makes it possible to create Firewall Rules that can be applied to User Object, unfortunately not to computer objects.

 

 

How to launch programs from the Windows Logon screen

It does happen from time to time, that I want to start some troubleshooting tools before a user logs on to the system. For example Sysinternals Process Monitor or xperf / wpr etc.

There are several ways to do it, as with most things with IT. You can either logon with another user, start the tools and then use Fast User Switching.
Or enable Boot Logging to get the full boot sequence + logon for a user.
Or use Psexec from a remote system, etc etc
Another way to do it, is to execute any tool of your choice from the Windows logon (winlogon) screen. The nice side effect is that you will be executing the tool as System, with full permissions.

I recently had to troubleshoot a “Password Reset” solution, which launches a browser from the Logon screen and it were unable to connect to the web-service. If you ran it from within windows as a normal user account, or system account, it worked. So I had to troubleshoot the problem as it was happening.

  1. Logon as a local administrator
  2. Make a copy of %windir%\system32\utilman.exe
  3. Take ownership of %windir%\system32\utilman.exe
  4. Grant yourself full control permission on the file.
  5. Replace utilman.exe with cmd.exe (or any other tool of your choise, though CMD is good as you can execute other tools from that one).
  6. At the windows logon screen press the “Accessibility icon” in the bottom left corner.
  7. Wahoo, you now have a command prompt with System Access

This works on Vista, Windows 7 and Windows 8.

 

List computer certificates that will expire with Powershell

Just a small simple script that will list all Computer Cerificates that will expire in 90 days, to give you a heads up and time to renew them.

To list computer certificates that will expire in 90 days:

Just change “-lt 90” to some other value to adjust the expiry period.

List all Unsigned Drivers with Powershell

I had a need for getting all Unsigned drivers in a Windows 8 system to help out with some debugging.

 

As I’m still learning Powershell there might be better and faster ways of solving this problem, but this seems to work good enough for me, and hopefully for you too.

It’s a quite straight forward and easy script to use and change if there is a need, such as instead of showing Unsigned drivers, list all Signed Drivers by using IsSigned -EQ “TRUE”.
Use driverquery.exe to list all Unsigned Drivers to CSV, then import that CSV into Powershell and display all Drivers that’s unsigned (-EQUAL “False”). You will actually just get the .INF file at this point which kind of sucks, not the driverfile which we need in this case.
So for each returned .INF file, we are then opening those files in c:\windows\INF (that’s where Windows stores all installed INF/diver files) and find all .SYS files (drivers) referenced in the INF files. And after some more filtering, it then outputs a list of the unsigned drivers ($UnSigned), like this.

PS C:> $UnSigned VClone.sys nvhda32.sys nvhda64.sys nvhda32v.sys nvhda64v.sys PS C:>
PS C:> $UnSigned
VClone.sys
nvhda32.sys
nvhda64.sys
nvhda32v.sys
nvhda64v.sys
PS C:>

I’ll then use that list and pass the unsigned drivers list to “Verifier.exe /standard /driver $UnSigned” to enable some Special driver Verification for finding the cause of some blue-screens.
I guess this script should work quite well also on Windows 7, but I’ve not tried it.