For me, this was a pain in the ass for a long time. When I connect to a Windows server through RDP/RDS it sometimes takes more than 2 minutes to connect to a server. Today after some waiting, and waiting and some more waiting I did a deep dive with Wireshark to figure out why it was so slow.
Azure domain joined Windows 10 device (Laptop)
Connection over a Cisco Anyconnect VPN
Remote Desktop Manager (Devolutions)
Native RDP client
Remote VS local
I know for sure the issue should be in my setup. Because when I connect first to a jump host (RDP) and then connect to other domain-joined servers everything was connected almost immediately after I put in my user credentials.
What to do (TL;DR)
There are four things you have to modify to speed up the initial remote desktop connection speed:
Disable SSL / TLS1.0
Disable Netbios on the VPN network adapter
Disable automatic proxy settings in Windows
Change the credential to domain.local\admin or [email protected] instead of domain\admin
Disable SSL / TLS1.0
No, you don’t have to negotiate what protocol you have to use to connect a server. Use TLS1.2 or I don’t want to connect with you 😉 So:
Start > Run > Regedit
Go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
If the TLS 1.0 and Client folders doesn’t exists create these keys
Create a 32 DWORD value with the name Enabled
Value data: 0 (Hex)
Restart the client
Disable Netbios on the VPN adapter
What I was seeing in my Wireshark capture is that RDP was trying to broadcast to get information over NETBIOS. You have a DNS server so you don’t need a legacy broadcast protocol! Unfortunately, I don’t have any screenshot of the capture but you can always check yourself 😉
Change the VPN Adapter and reboot the computer:
Disable the proxy
After connection to a server with RDP and you enter the credentials Windows is trying constantly to WPAD.domain.local to autoconfigure itself. WPAD stands for Web Proxy Auto-Discovery and I think you never want to autoconfigure a MITM ehh proxy device. You always want to have full control of your device. So, disable this to speed up the connection and make your device more secure.
Go to settings
Search for proxy
Switch the Automatically detect settings to Off
Change the login name
I found out that this is the most annoying and time consuming one. I always use DOMAIN\User when I connect to a server. But this is what happens:
Kerberos is doing a DNS query on _kerberos._tcp.dc._msdcs.domain.domain.tld and of course he will never can find that double domain A record. But if you change the logon name to domain.tld\admin or [email protected] Kerberos will find the A record and connects immediately 🙂
And even now it’s possible to tune the Kerberos authentication further and fix the last KRB5KDC_ERR_PREAUTH_REQUIRED error you can see in the screenshot. Maybe next time but for now I’m happy with the initial connection speed 🙂
The Windows Update Agent periodically checks the WSUS server for updates. Updates it finds, it reports state for: Installed, Not Installed, Not Applicable. If a “Not Installed” update is approved and available, the WUA queues the installation files for download if the Configure Automatic Updates policy is set to AUOption ‘3’ or ‘4’.
The download occurs via Background Intelligent Transfer Service (BITS) subsequent to the WUA finding the update as available for download.
When the download of the update is completed, the WUA does one of two things:
If the Configure Automatic Updates policy is set to AUOption ‘4’, then the WUA will schedule the update for installation at the scheduled time. This scheduled installation does NOT require access to the WSUS server to be conducted.
If the Configure Automatic Updates policy is not set to AUOption ‘4’, then the update will be retained on the client computer until a user launches the Windows Update applet from Control Panel and initiates the installation.
So bottom line; the updates must first be downloaded on the client and ONLY then will Windows apply the “Automatically download updates and install them on the schedule specified” action
After this commands BITS will download the updates and prepare the installation. When you start Windows update you can see the available update
The default of the WSUS communication check-in (report and detect) is 22 hours. If you don’t want to wait so long you can change the “automatic updates detection frequency” to every hour (do not to this every hour on production policies!)
And now wait till the magic happens 🙂
Last but now least. When you change setting in the “configure automatic updates” policy you can trigger the client with powershell so you don’t have to reboot the client
gpupdate /force net stop wuauserv net start wuauserv (new-object -Comobject Microsoft.Update.AutoUpdate).Detectnow()
You get get more information about Windows update log with the command.
OK… Even with all the tips. Sometimes you need rename the software distribition folder also so I present to you: The PLZ GIVE ME ******* UPDATES NOW SCRIPT!!!! (runas admin)
Today our domain controller had a very bad day and had a bootloop after a reboot. I used recording software to capture the blue screen error: STOP: c00002e2 Directory Services could not start
Then we found a nice article to fix this issue. We had a second working domain controller so if you have the same setup you can use this how to, to fix this problem also. All the credits go to dbutch1976
Restart the server and press F8 key, select Directory Services restore mode.
Log in with the local administrator username and password (hope you remember what you set it to!).
Type cd \windows\system32
type activate instance NTDS
If you encounter an error stating that the Jet engine could not be initialized exit out of ntdsutil.
type md backupad
type cd \windows\ntds
type copy ntds.dit c:\backupad
type cd \windows\system32
type esentutl /g c:\windows\ntds\ntds.dit
This will perform an integrity check, (the results indicate that the jet database is corrupt)
Type esentutl /p c:\windows\ntds\ntds.dit
Agree with the prompt
type cd \windows\ntds
type move *.log c:\backupad (or just delete the log files)
This should complete the repair. To verify that the repair has worked successfully:
type cd \windows\system32
type activate instance ntds
type files (you should no longer get an error when you do this)
This is a very nice tool to quickly see how fast your troughput is of your new system.
But sometimes you want to check your IOPS. Then you can use another nice microsoft commandline benchmark tool DiskSpd
You can use this parameter to benchmark:
diskspd -b8K -d30 -o4 -t8 -h -r -w25 -L -Z1G -c20G testfile.dat
This example command line will run a 30 second random I/O test using a 20GB test file located on the T: drive, with a 25% write and 75% read ratio, with an 8K block size. It will use eight worker threads, each with four outstanding I/Os and a write entropy value seed of 1GB. It will save the results of the test to a text file called DiskSpeedResults.txt. This is a pretty good set of parameters for a SQL Server OLTP workload.
Results for timespan 1:
The test was interrupted before the measurements began. No results are displayed.
Error generating I/O requests
Or file creation errors like “Error opening file: testfile.dat” please try to replace the minus “-” characters with your keyboard. Sometimes your browser copy the wrong character.
copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe to %systemroot%\System32
copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63\cleanmgr.exe.mui to %systemroot%\System32\en-Us
Run cmd > cleanmgr and remove all the nasty update files!
After I cleaned up the server I had to stop the windows installer service (trustedinstaller.exe) to remove the c:\windows\logs\cbs\CBS.log (6GB file) manually. Maybe a restart of the server do the same but I cannot test it on a production environment.