For this post I am relaying what I’ve discovered about trying to migrate a VM from VMware to Promox VE.

The original VM:

• 4 vCore x 1 socket
• 8 GB memory
• 1 x 250 GiB VMDK
• 1 x 1.1 TiB VMDK
• Windows 2016 Standard

Granted, I have made things more difficult by having multiple network segments.  In my last post I think I mentioned setting up multiple VLANs, Bridges, and Interfaces in Proxmox.  This was because I’ve gone back and forth between two networks, and my Synology NAS straddles both.  I ended up adding the Synology NAS to as storage to the same Promox host twice, once per network, to hopefully make network access more efficient to the mass storage device.

Over the past week I have been working with the ovftool to migrate the file server to Promox, each time taking in excess of 24 hours and inevitable session timeouts, causing the import to stall and ultimately fail.  Since you cannot pick up where you left off (that would be a sweet feature to ask for) the process has been started multiple times.  This last attempt today, however, completed in just 8 hours successfully, so evidently my theory on network traffic efficiency won out.

The first step – use the VMware ovftool (installed to Proxmox VE server) to import the desired VM:

ovftool –overwrite vi://192.168.155.81/FileServ /pve-zfs

The second step – use qm to import the VM to Promox:

qm importovf 210 /pve-zfs/FileServ.ovf /pve-zfs

Once completed, the VM showed up in Proxmox as expected, as ID 210, but without a network interface (which is also expected).

First challenge – machine is not bootable.

Referencing Promox support documentation on importing VMs:  Migrate to Proxmox VE – Proxmox VE

Convert the SCSI disks to IDE or SATA.  

• Detach disk
• Change format to IDE or Sata
• Connect 

Still no joy.  Disks were converted fine.  
I then added a CDROM to the VM and booted to a Windows Server 2016 install media ISO – confirmed that C:\ is the %systemroot%.  

I then went back to the hardware and made a few edits:

1. Converted the Machine version to q35 from default i440fx
2. Converted the SCSI Controller to PVSCSI
3. Converted the Processors from kvm64 to host

Still no joy – machine does appear to boot it just can’t find a boot partition.

Maybe the OVF will give me some insights? Before getting that desperate, I tried one last thing – I switched the BIOS from SeaBIOS to OVMF (UEFI).

Bingo – the machine instantly booted successfully.

Lesson learned – don’t rely on the qm importovf to properly read the OVF and translate it to the same profile in Proxmox.  Make sure you have your hardware profile from VMware before 

The post Proxmox – Post 2 appeared first on Wiredwolf Canada.

There are a series of steps that must be taken to ensure mail flow:

1. If using Azure AD Connect and filtering by OU or Security Group – make sure all mailbox users AD accounts are synchronized to Azure AD/Office 365
   1. Add all Mail Users
      1. In AD this can be easily accomplished with a simple Powershell script:
         

         Get-ADUser -Filter ‘Enabled -eq $true -and Mail -like “*@*”‘ | ForEach-Object {Add-ADGroupMember -Identity ‘Office365Users’ -Members $_ }

         Where “Office365Users” is your security group

   2. Add all Contacts
   3. Add all Distribution Lists
   4. Add all Mail-Enabled Security Groups

For mail from from Office 365 to Exchange On-Premises (Performed in Office 365 Exchange Admin Center):

1. Create an Internal Relay to On-Prem Exchange connector (in EAC)

For mail to Office 365 from Exchange On-Premises (Performed in On-Premises Exchange Server):

1. Create a tenant.mail.onmicrosoft.com in Accepted Domains and set to Internal Relay
2. Create an “O365 Relay” Send Connector
   1. FQDN of the connector (mail.domain.com – the FQDN public name of the On-Premises Exchange server)
   2. Address Scope – tenant.mail.onmicrosoft.com
   3. Smart Host – the MX provided by Microsoft Office 365 Domains DNS configuration (I.E. domain-com.mail.protection.outlook.com)
   4. Source Server: The On-Premises Exchange server

Make sure to check any firewall rules that restrict WAN to LAN to port 25 to specific addresses.  Use this list https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges to set up your rules to lock down unauthorized access to Port 25 inbound.

The post Office 365 Hybrid to On Premises Exchange – Mail Flow How-To appeared first on Wiredwolf Canada.

Some of these attacks have been pretty basic and if I didn’t have security auditing enabled may not have even noticed them.  But I do, and I get email notification when an account is locked, which prompts me to go see what’s happening.

Before you say, “Hey, RDP open to the public is just ASKING for trouble!” – I already know this.  In fact, I’ve been documenting the experiences.  However, when a lot of this was originally set up the Internet was a safer place and the tools to exploit and attack networks were far less sophisticated.  I now encourage all of my clients to pay a bit more attention to security concerns and start closing some of these transitional gaps.

Anyway, one of the biggest frustrations I’ve experienced is the ridiculous way Microsoft records Security Audit information.  

The computer attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: LIBRARY
Source Workstation:
Error Code: 0xC0000064

Note that Source Workstation is blank or NULL.  It isn’t always.  Sometimes it’s some other nonsensical entry (MSTSC, RACCESS, etc.) that cannot be resolved on the domain or network.  The point is, the information provided is basically useless.  I know someone is trying, I just don’t know where it’s coming from.  If I can’t source it, I can’t stop it.

In this particular case it was a workstation with a Public RPD connection available.  The user was actually sitting in front of the workstation for a change, but it was still being used to brute force attack a number of accounts.

While the Security Logs can’t tell me the source, NETLOGON can.  

Here’s how to go about finding the source:

Open a CMD prompt (as Administrator) on the domain controller (PDC Emulator)

nltest /dbflag:0x2080ffff

This turns on debug logging for the Netlogon service on the DC

Now go review the log entries:  Start –> Run –> “%windir%\debug\netlogon.log”

When you’re done, unless you don’t mind the netlogon.log file growing at an alarming rate, turn off the debug logging:

nltest /dbflag:0x0

Now, the netlogon.log will be completely stuffed with helpful information, but it’s information overload.  This is what you’re looking for:

SamLogon: Transitive Network logon of

Paste that into your Find and you’ll start seeing responses like this:

05/29 15:36:42 [LOGON] [10684] <<DOMAIN>>: SamLogon: Transitive Network logon of (null)\MARK from  (via <<WORKSTATION>>) Returns 0xC0000064

More sophisticated attacks don’t have a NULL domain, and we’ve been seeing a lot of very targeted attacks where the hacker network knows the custom RDP port, the domain, and the username.  I haven’t yet determined how they know this, but it is pretty accurate.  As I’ve documented though, brute force attacks against networks with progressive security policies such as account lockout policies and complex password compliance with regularly changed passwords makes this a very inefficient way to break in.  Having said that, it only takes one…  

The post Security Audits – Tracking down the Source Workstation appeared first on Wiredwolf Canada.

Recently I had a client contact me. Their primary application is Oracle-based and was no longer functioning.  I quickly logged into the server and discovered immediately that it was hit with a Ransomware bug. The whole server was encrypted.

I didn’t even bother trying to investigate.  I shut the server down immediately and started the process of a full recovery.  That’s when I discovered that the Ransomware had also encrypted all of the local backups – not just for this server, but all backups for all systems.

Fortunately, I always push for redundant off-site backups.  In this case Acronis Cloud to the rescue.  It took about 4 hours but the server was fully restored to a time prior to the hack.  In that four hour period I did some investigation.

1. The account that I found logged in was named “admin”.  I confirmed that this account did not exist in Active Directory, therefore it was a local account to the server.
2. The server was using a custom RDP port, but that port was open to the public because there are third party Oracle specialists who occasionally have to service this system.

I wasn’t too worried about the admin account returning (though I did check) since it was a fully recovery, but I did review the local accounts. I still am not certain how the hackers got in, but I’m suspecting it was a man-in-the-middle RDP brute-force attack.

Anyway, long story short, the custom RDP port was restricted (no more public access) along with any other open server, and the server was restored fully with no real harm done.

However, this is only part of the story.  Over the past few weeks I’ve been encountering issues with other client networks being attacked.  Users are being locked out, sometimes instantaneously after having their passwords changed.  The security logs on the DC’s showed the same thing – a roughly 15 minute period where an unknown system (usually came up as MSTSC) was attempting to brute-force the the password.

This ended up presenting a whole field of frustration.  Microsoft Security Logs do not appear to record much in the way of relevant information.  It showed the username, usually without the domain, but not always, and MSTSC as the ‘Workstation’.  Since there is no system on the network named MSTSC I could only surmise that these were RDP attempts.  But to which system?  Several workstations have custom RDP ports open to the public.

After some searching I came up with a plan.

1. I need to see where the attacks are coming from and hopefully block them.  Are the attacks from a compromised PC on the network or from the outside?  To do this, I need to see what traffic is coming in on the router.  This will be a different blog entry.  Most of my clients have SonicWALL routers and as I discovered SonicWALL routers do not log Firewall Rule Hits.  I did find a way to monitor the traffic, but it wasn’t directly obvious so I’ll blog how to get monitoring working on SonicWALL routers.
2. I need to start monitoring the DC for invalid login attempts.  That’s what this blog entry is all about.
3. I need to be notified when attacks are happening.
4. I need to start pro-actively blocking the attacks.  I’m actually still looking for a solution for this.

So, monitoring the DC turned out to be an exercise in frustration. The Security Logging cannot be adjusted or adapted to provide more information. 

TCPView

A solution that I found proposed was to run TCPview.  Which I did and found it to be less than helpful.  For one thing, TCPview, while a fantastic tool, is also a bit of a pig, like most network monitoring utilities, and the overworked DC had issues running the program.  It’s also a reactive solution – you have to know the attack is happening to know to use the tool.

RDPGuard

I tried installing RDPGuard.  This is another excellent utility (Trial for 30 days only though) but discovered that unless the attacks were directed against the server itself, it wasn’t really going to help source the attack.  The attacks were against the workstations, not the servers, so while it functioned as expected, it didn’t really help.

Microsoft Network Manager

I installed the Microsoft Network Manager 3.4 and configured it for parsing Windows TCP captures.  However, this isn’t ideal either as again, this is a reactive solution that is based around extensive network monitoring, which is also a bit of a pig, and unless you capture huge amounts of data to parse, it’s window is too small.  Capturing even 5 minutes of data can be more than 1 GB of logging.  I did manage to run a capture while an attack was happening but was unable to determine exactly what protocol I should be monitoring.  I read that I should filter using ProtocolName == “NRPC” but that showed absolutely nothing.

Logon Auditing

Logon Auditing is a good idea regardless of whether you are having issues or not.  All administrators should know if user accounts are being accessed incorrectly, even if only to know which users are having trouble logging in.  Administrators shouldn’t be waiting for accounts to get locked out to determine if there’s an issue.  An issue could be there without getting to that stage.

This is the process I use to set up auditing:

1. GPO – Default Domain Controllers Policy
   (Click on the thumbnails to get the full picture)
    
2. GPO – Default Domain Policy
   
3. Download/Install Netwrix Account Lockout Examiner
4. Configure Account Lockout Examiner
   1. File –> Settings
   2. Managed Objects – Edit – set to All DC’s
   3. Notifications – Send notifications to a monitored email address and provide the SMTP server configuration (server and port)
      – does not do authenticated SMTP
   4. Add all users you want to monitor – including Administrator and Guest
      (I just add every user – you just know it’s the one you’re not watching that’s being hacked)

That’s it.  Wait for emails to come in or check on it regularly.  It runs as a service so even if the console is not running it’s still collecting data and sending notifications.

By turning on the Password Lockout settings hackers only get 10 attempts before the account is locked out for (at least) 15 minutes.  With enforced password complexity requirements, this would make brute force attacks pretty difficult.

The post Hardening RDP Security – Logon Auditing appeared first on Wiredwolf Canada.

When I wrote the blog post below, I had not actually experienced any issues.  I already locked out access to servers I manage by using IP restrictions, and I wasn’t generally too worried about workstations because I do push my clients to adhere to good password policies.  Given that I manage 30 networks and over 600 systems, this seemed to be pretty safe.

Recently I had an issue where user accounts were getting locked out, but not by the user.  Not just one user, and not just one network, but different users on unrelated networks.  When I started digging into it, I discovered that IP’s originating from countries all over the world were actively trying to brute force passwords using RDP.

What concerned me the most was how specific the attacks were.  They were targeting workstations with custom RDP ports (Port Redirections as described below) and even monitoring for changes in the custom ports.  For one user I grew concerned that the redirect port 3344 was too low and too easy to find, so moved it up to 25698.  Without skipping a beat the attacks resumed on the new port.  In addition to the port, they were targeting a specific username – the actual user of that PC.  The only thing they were missing (most of the time) was the domain itself, and obviously the password.

After ramping up some security measures, enhanced router logging and reporting, and turning on some auditing policies, it became clear that this is a widespread issue that was quietly targeting almost every network I manage.  Before I knew it, one of my clients who had an old 2003 server that was unfortunately exposed to the Public interface, got hacked and encrypted with Ransomware.

The fundamental issue I found with RDP security, while it does utilize SSL encryption, is that Microsoft has not hidden or even randomized the salt used for the encryption.  The “Man in the Middle” attack can therefore insert itself into the connection and collect all kinds of data about the connection state, including last used username.

So ignore the post below where I say RDP is secure.  It’s wrong.  RDP is not secure in and of itself.  If you cannot restrict access by IP then use something else.  VPN appears to be the favored approach (client VPN to the router/gateway) or move to a third party connection broker such as TeamViewer.

I am leaving the old post as a reminder that I do not know everything, and in this case I was wrong.  The MSP was right to recommend against RDP and possibly should have even refused to do the work. 

However, since they did do the work, they should have at least inserted some measures to ensure getting in one machine did not mean being able to get into all machines.  The processes I describe in this article should be followed regardless as best practices for security. I say this because the same issue happened to one of my networks (described above) but they were not able to get any further than that one server.  The MSP in question still did crappy work, but I will give them credit for making the recommendations to not use RDP in the first place.

I had a friend contact me recently about concerns using Remote Desktop Services.  Staff at his office wanted to be able to work from home.  RDP is built in to all Professional/Business Class operating systems, and it’s free. 

Apparently the IT company they use recommended against it, declaring that Remote Desktop Protocol is highly insecure.  The company did end up getting their RDP connections but no attention to improving security was observed.

Months later, the network was hacked.  Ground Zero was a conference room PC that had an open RDP connection to the public and was somehow compromised.  The IT company used this opportunity to say, “See? We told you this would happen.”

This is my blog so I feel I am entitled to have an opinion on this.

1. RDP itself is not insecure.  It is an encrypted connection (128-bit) that requires an authenticated connection.  It has policies in place that prevent things like user accounts with no passwords from connecting.  User accounts must either be local administrators or be added to the Remote Desktop Users security group.  
2. In my opinion the IT company in question here was right to inform the client of the security risks, but instead of just setting up the RDP connections should have also taken steps to harden the network security around the workstations that were opened up for remote connectivity.  Stepping up now with “we told you so” is a dick move.  If I was a decision maker at this company, I would be deciding to find another IT company.

Common security pitfalls setting up RDP:

• All Windows PC’s have a local built-in Administrator account as well as an initial administrator-level user account that was created when the PC was set up.  Typically Administrator is disabled, but equally typically on a Windows domain network, the initial user account that was created when the PC was set up has a weak or non-existent password.  This local user account is in the local Administrators group which is by default a member of the Remote Desktop Users group. (It should be noted that the username for this account could be anything – avoid using “user” or the PC name as the username for setting up the PC so it can’t be easily guessed.)
• Default RDP port is 3389.  It is possible to override this port in the registry but typically there’s no need.  However, if you have 1 public IP address and 3 remote desktop users each wanting to connect to his or her own workstation, you have to set different ports for each workstation.  This is done on the router and it’s called Port Redirection:
  • Workstation1 – Local IP: 10.0.0.11 RDP 3389 – Public IP 206.56.98.125 Port 56896
  • Workstation2 – Local IP: 10.0.0.12 RDP 3389 – Public IP 206.56.98.125 Port 56897
  • Workstation3 – Local IP: 10.0.0.13 RDP 3389 – Public IP 206.56.98.125 Port 56898 
• Some ISP’s change the Public IP’s for their customers frequently.  This can make using RDP access difficult if the Public IP changes – the users won’t know that the IP changed and the connection will be broken.  There are two solutions for this:
  • Obtain a Static IP from your ISP and/or
  • Utilize DDNS (Dynamic Domain Naming System)DDNS allows you to register a hostname.domain that links to your Public IP, no matter what your Public IP may be today.  This is accomplished by installing an agent on the network that sends a constant heartbeat to a public service that tracks the IP changes.  Utilizing DDNS is a good idea and many commercial and even some consumer level routers support it from common DDNS providers.  It’s anywhere from reasonably cheap to completely free. 

There are a number of easy-to-do tasks that can help prevent unauthorized access.  On a Windows Domain this can done by using Group Policies but if you don’t have a Windows Domain you can still do a lot at the workstation level by getting familiar with the Local Policies.

1. Ensure all local accounts are secured with strong passwords:
   1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Account Policies -> Password Policy
      
      I actually recommend a “Minimum password length” of ’10’ but the important bit is the “Password must meet complexity requirements”.  This ensures that users cannot just put in “1234567” or “password” as a password.
      Remember to reset the passwords of the local accounts, and disable the Administrator account if it’s not already.
2. Set an account lockout policy:
   1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Account Policies -> Account Lockout Policy
      
      This is a solid way to prevent brute force attacks.  With complicated passwords and getting locked out 30 minutes at a time it’s next to impossible to guess a password.
3. Limit which accounts can log in using Remote Desktop:
   1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
      1. Open Allow log on through Remote Desktop Services
      2. Remove Administrators
   2. Add users to the Remote Desktop Services Security Group manually

If you find a user account is constantly locked due to attempts to brute-force the password, start logging the IP’s of the attackers and set up additional firewall rules to block future attempts from these sources.  Unless it’s from bots on many systems specifically attacking your systems this should put an end to the attacks pretty quick.

This is the easy stuff and if you are using a Windows Domain then using Group Policies makes it easier to apply these settings to all workstations, or if that’s too intrusive then you can separate out only the PC’s and Users who require RDS (Remote Desktop Services) and apply to only those systems.

More complex considerations are:

• Two Factor Authentication
• Signed Certificates – Password Protected
• IP restrictions (limit which public IP’s can remotely connect)*

Two Factor Authentication just means that two authentication methods must be passed successfully to connect.  In this case, the user connects to the PC, logs in successfully using the Windows credentials, but is blocked from getting a desktop until another password prompt is successfully passed.

Two Factor Authentication is not built into connecting directly to Windows workstations and is a third party application that must be purchased or subscribed to.  If security is important to you then the costs associated shouldn’t really stop you.  I did some digging and found the costs to be generally quite reasonable. (I looked at Duo)

Signed Certificates (as opposed to Self-Signed Certificates) can be used but this is far more complicated to set up (and more costly).  The idea is to limit RDP access to the host PCs by requiring a signed and authenticated certificate using pre-shared keys to be installed to the remote PCs.  Basically, both ends of the connection must have the same certificate installed or the connection is dropped, even if Windows Authentication is successful.

On a workstation level this is probably not very practical.  I’ve never tried it either so I’m not even sure it would work, but in theory it should.  It’s a good idea but really only if you are also implementing RDP Gateway technologies to add additional security layers – in which case you have other options as well.  Plus to do it properly you shouldn’t use the same certificate for each system but rather purchase individual certificates for individual systems – which is a substantial yearly cost even at $100 per workstation.

IP Restrictions is probably one of the easiest ways to secure RDP connections but it can also be a bit inconvenient.  Basically, your router firewall rules specify which IP’s are permitted to connect to which PC’s.  Anyone probing your network looking for a way in will never even see an open port because the router will drop all traffic that doesn’t come from the specified IP’s.  The downside is the remote user must always be using the same IP to connect from.  The remote user can’t take his or her notebook to the local Starbucks to use the free WiFi to remotely connect.

I had a thought about this though.  In the same way that you can use DDNS to make the host network easy to find for the end user, you may be able to use the same concept in reverse to allow users to connect from anywhere by using a DDNS client on each workstation.  The connection is still restricted by IP but the IP can now be dynamic because it’s using the remote users DDNS client to get constant updates.  As long as the router can resolve names to an IP (internal DNS) and allows you to specify a host name vs strictly IP’s, I can’t see why this wouldn’t work.  I do this with VPN connections all the time in SonicWALL routers.

Getting back to the original reason for the post – the IT company mentioned above did none of these things.  The ground-zero PC was hacked into, then used to plant malicious software that spread throughout the network.  The hackers were able to get different types of remote connectivity to the other workstations and presumably the server to further compromise the security of the network.  Even if the original door was closed (the conference computer), access was still assured by way of the other systems.  Egg cracked wide open.

In addition to hardening the security of the RDP connection, it’s critical that systems are well protected by up-to-date antivirus software.  One in particular AV suite I like is from Kaspersky.  It’s protection is first class and it has features that renders it virtually bulletproof from tampering.  Even if there is unauthorized access to the PC, the remote user can do nothing to defeat the antivirus.  Somehow the hacker got in the door but got blocked at the elevator.

The final consideration is always the big picture.  Let’s say the hacker does somehow get past all of this security and manages to get a desktop session.  At this point, how secure is your network from malicious activity?  The AV software on the PC may prevent the hacker from installing malicious software, but will that stop data theft?  This is where, on business networks with Windows domain management, I tend to push to get user data away from the workstation. Using Group Policies I redirect user data to the file servers and I lock down all the shares to prevent ‘public’ access.  Even if a hacker finds himself on a desktop without a domain account, there’s virtually no corporate data he or she can access. 

Anyway, the scope of this post is to harden RDP connectivity.  I’ll talk about how to secure internal networks in separate posts.

The post Security – Hardening RDP connections appeared first on Wiredwolf Canada.

For some reason, the ESXi host always wants to assign the Intel E1000 virtual NIC.  Yet if you do any reading on this, you’ll quickly find that actually using this driver is frowned upon. Exactly why, I can’t remember.  Just don’t use it.

Instead you are supposed to select the VMXNet 3 driver.  This is a fully feature-packed driver and in my experience it does operate very well in Windows environments… but not without some tweaking.

The biggest issue seems to be related to some of the Offload features that are always on by default:

• IPv4 Checksum Offload – set to Disable
• Large Send Offload V2 (IPv4) – set to Disable
• Large Send Offload V2 (IPv6) – set to Disable
• Receive Side Scaling – set to Disable
• Recv Segment Coalescing (IPv4) – set to Disable
• Recv Segment Coalescing (IPv6) – set to Disable
• TCP Checksum Offload (IPv4) – set to Disable
• TCP Checksum Offload (IPv6) – set to Disable
• UPD Checksum Offload (IPv4) – set to Disable
• UDP Checksum Offload (IPv4) – set to Disable

The other item that can cause issues is the Receive Side Scaling.  Based on what I read, Receive Side Scaling is for when you want to distribute your network connectivity CPU load across all CPU cores.  In theory this should work great, but in practice I have found it doesn’t work very well.  I always turn it off.

I have found not all features for the VMXNET3 adapter are present on older Windows Server installations.  Server 2012 – 2016 have the Receive Side Scaling and Recv Segment Coalescing features where Server 2008 R2 doesn’t.

There are other Offload features that you shouldn’t touch or should ensure they are turned on:

• Offload IP Options
• Offload Tagged traffic
• Offload TCP Options

Particularly with Active Directory, some of these features are actually required for the server to process correctly.

Hope this helps someone else out there who’s struggled constantly with ESXi network efficiency issues. 

• edited Thursday June 14, 2018 (missing Recv Segment Coalescing and Receive Side Scaling) – encountered abysmal network connectivity on two separate host server VM’s because I missed this the first time around – cost me many hours of painful file copying until I resolved it (again)

The post VMware ESXi – Network Interfaces appeared first on Wiredwolf Canada.

The most recent was an issue with a client SBS 2011 server that was running horribly slow.

This server has been an issue for the client for years.  A particular application that uses SQL seems to cause the most issues prompting a reboot of the server every week.  The server runs anywhere from a day to a few days before bogging down so badly it needs to be rebooted again.

As usual I started looking through the performance monitor, checking for disk thrashing, high CPU usage, and memory pigs.  This server is running MS Exchange and MS SQL, both of which are performance hogs, but I’ve already curtailed their resource access to prevent the server from completely tanking.

Anyway, I started digging into the networking and discovered something odd.  The server has two Network Adapters (which is normal) and one of those network adapters is disabled (also normal).

What wasn’t normal was what I found in the Advanced –> Advanced Settings

Local Area Connection 2 was being given order preference despite the fact that the NIC was currently disabled.

In the Provider Order the Microsoft Remote Desktop Session Host Service was also being given higher preference.

What?? That’s BACKWARDS! In my office, that’s a pseudonym for “Microsoft”.

Trust me – changing the order of preference to Microsoft Windows Network and setting the active/dominant NIC to the top of the order makes a huge difference in the performance of the server.

The post Slow Servers appeared first on Wiredwolf Canada.