Server has lost contact with failover partner server

If you see multiple events with ID 20255 “Server has lost contact with failover partner server“, this article may be able to help you.
I’ll concentrate on the actual network settings, specificially MTU settings.

Usually, when you see multiple events per minute stating that the Server has lost contact with failover partner server, followed by Server has established contact with failover partner server, the culprit is the MTU setting.

First of all, on both DHCP servers, make sure the network card’s MTU is set to 1500. You can do that by running the following command:

As you can see, the interface’s MTU in the screenshot is already set to 1500. In case yours isn’t, you can adjust it by running the following (where 12 is the Idx of your network card which you retrived earlier with netsh interface ipv4 show interfaces):

If the DHCP servers are virtualized, then make sure the virtual Switch’s MTU is also set to 1500. Here’s how it looks in the vSphere (HTML5)’s interface.

What if the DHCP servers are running on two separated hypervisors (as they should be..) and you’re still facing the same issue? It most likely is an issue related to the underlying network, so you may want your Network admin to check that, however you can still run a couple of tests.
First of all, try running a ping with 1500 bytes, in Windows you can do this with the option -l:

Try to ping from dhcp01 to dhcp02 and vice versa. Once I noticed that was that I was able to ping the DHCP servers with >1500bytes from a different network, but not within the same network and the DHCP servers weren’t able to ping each other with more than 1450ish bytes.

You can also test directly at the ESXi level with:

The other thing you can try, if these are virtualized servers, is to migrate them under the same hypervisor just to check it out and exclude an issue with the virtual network configuration.

Read More

Forcing an application to use a specific network card

Forcing an application to use a specific network card in Windows is something that may end up being super handy at times. For instance, if you’re connected to your company’s corporate [restricted] network via the Ethernet cable and also connected to the Guest [open] network via the wireless network card, you may decide to route an application through of one the two. Note that Windows uses the “metric” of a network card to choose which NIC have priority over the other, and if you want to keep that unchanged, then forcing an application to use a specific network card is what you need.

In order to achieve this, we will use a 3rd party application called ForceBindIP, available at this link

The nice thing of ForceBindIP, is that it comes as a portable application (or you can choose the installer version). If you go ahead with the portable version, make sure you keep the files (.dll and .exe) together.

Extract the zipped folder and you will find 4 files, 2 DLLs and 2 EXEs:


As you can see, two files (DLL and EXE) are for 64bit systems/applications and the other two are for 32 bit systems/applications. If you are using a 64bit OS, keep both versions. In fact, you will need to use both, depending on the application you’re going to launch. For instance, Firefox on a 64 bit OS, will still run as a 32 bit application, and for that you will need to use ForceBindIP. Instead, the Microsoft Remote Desktop tool (mstsc.exe), on a 64bit OS, must be ran with ForceBindIP64.

Let’s make an example on how ot use this application:

  • I have 2 NICs, one connected to the corporate network that has this IP address: The second NIC, is connected to the guest network and has this IP address:
  • I want firefox to use the guest network.
  • 64bit OS

Open the command prompt and type:

That’s it! It’s that simple, really. Firefox will launch and will be using the guest network.
Here’s an example if you want to run mstsc.exe (on a 64bit system) with the guest network:

Or, if you have a .rdp file saved:

Have fun! ūüôā


Read More

Enable Wake on LAN in Windows

The title Enable Wake on LAN in Windows is a bit generic on purpose as this article is targeting any system. Specifically, the screenshots are take from a DELL Optiplex Micro 3040 system, but applies to any other vendor as well (screenshots will differ). The reason why I’m specifically writing this article is because¬†I struggled a bit more than usual with a Micro 3040 model running Windows 10 and I had the 3020 working¬†with no issues. Again, these steps apply to¬†any system running Windows!

Also note that normally, you do not have to set all of the below up (like Firewall etc).

Let’s go in steps, starting with the basics BIOS settings.

  • Make sure the BIOS is up to date.
  • Go in the BIOS by starting the computer up and by pressing F2.
  • On a DELL system, go to Power Management and¬†Disable Deep Sleep Control. If you’re not configuring a DELL, find the option (if it exists) to prevent the system from fully shutting down or hibernating.
    • dell_optiplex_3040_wake_on_lan_disable_deep_sleep
  • Enable Wake on Lan (or Wan or both).
    • dell_optiplex_3040_wake_on_lan_enabled

In order to fully Enable Wake on Lan in Windows, there are a few settings to be changed at the OS level. This process covers Windows 10’s settings, if you’re on Windows 7 or earlier, you may need to skip a setting or two as not present in these versions of Windows.

  • Upgrade the network interface card (NIC) drivers to the latest available.
  • Open the Network Card’s hardware settings and, under¬†Adavanced:
    • Make sure Speed&Duplex is set to¬†Auto Negotiation.
      • nic_advanced_speedAndDuplex_auto-negotiation
    • Enable Wake on Magic Packet.
      • nic_advanced_wakeonlan_wake-on-magic-packet-enabled
  • Go to the NIC’s Power Management tab and select¬†Allow this device to wake the computer.
    • nic_power-management_allow-this-device-to-wake-the-computer
  • In Windows 10, go to the Power Options under Control Panel.
    • On the left hand of the window, click¬†Choose what the power buttons do.
      • power-options_choose-what-the-power-buttons-do
    • Disable the option¬†Turn on fast startup (recommended).
      • power-options_turn-on-fast-startup_disabled
      • Note that this option might get reset after running Windows Update. I have not encountered this problem myself yet.
  • Go to Control Panel > Windows Firewall >¬†Advanced Settings.
    • windows-firewall_advanced-settings
    • Right click on¬†Inbound Rules and select¬†New Rule.
      • windows-firewall_new-rule
    • In the¬†New Rule Wizard, select¬†Port and click Next.
      • windows-firewall_new-rule_port
    • Under Protocol and Ports, select¬†UDP and¬†Specific local ports and type¬†9.
      • windows-firewall_new-rule_UDP_Port-9
    • See the screenshots for the rest of the steps:
      • windows-firewall_new-rule_Action
      • windows-firewall_new-rule_Profile
      • windows-firewall_new-rule_Name

This should be enough for you to get Wake On Lan configured on the machine you want.

Read More

Set up an L2TP VPN Server on Windows Server 2012

This article will describe how to set up an L2TP VPN Server on Windows Server 2012 R2 start to finish and¬†step by step including Firewall configuration and port forwarding. The way I’m going to set it up includes the NAT service as well that will allow you to not only connect to the L2TP VPN but also to access the internal LAN you’re connecting to. One of the reasons why I tried this ¬†was due security (I never did it before). I didn’t want to use Windows 10’s “Incoming connection” as that will set up an insecure VPN server using the PPTP protocol.

If you’ve already set up the VPN bit and are having issues with reaching anything within the LAN you’re connected to (even the VPN server itself), then you might have missed the NAT service.

This article might look lengthy but trust me, the actual configuration is pretty fast, I’m just adding literally every single step.

The step by step guide was performed on a clean Windows Server 2012 R2 Virtual Machine running in Hyper-V (Windows 10 Pro is the Hypervisor sharing its only network card). The steps apply also when you’re performing this on a physical Server.


The above represent more or less what the network behind the router looks like. In my specific case I have other plain switches between the wireless router and the Hypervisor (which, again, it’s not a Server but a Windows 10 desktop).

TIP: If the server you’re installing this on is a virtual machine, take a snapshot before and after every major step so that you can revert to it in case of issues without starting from scratch. Make sure you remove them once you’re happy. ūüôā


Read More

L2TP VPN not working in Windows

I’m going to skip the first troubleshooting steps because if you’re struggling with this for days I guess you’ve tried that (IE Connection, Server is up..). Now why is L2TP VPN¬† not working in Windows? That is generally when the VPN server is behind a NAT-T and here’s the reason (Microsoft KB 926179) from Microsoft:

By default, Windows Vista and the Windows Server 2008 operating system do not support Internet Protocol security (IPsec) network address translation (NAT) Traversal (NAT-T) security associations to servers that are located behind a NAT device. Therefore, if the virtual private network (VPN) server is behind a NAT device, a Windows Vista-based VPN client computer or a Windows Server 2008-based VPN client computer cannot make a Layer Two Tunneling Protocol (L2TP)/IPsec connection to the VPN server.

This actually applies to every Microsoft OS up to Windows 10’s latest release (I’m writing this on the 22nd of September 2016).

In order to resolve this, you will have to add/modify the following key in the registry and reboot afterwards. For the less experts, keep reading to see the below detailed steps in order to create/modify the Key.

Registry subkey location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
DWORD Value Name: AssumeUDPEncapsulationContextOnSendRule
DWORD Value Data: 2

For Windows XP, the Registru subkey location is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec.

See these notes about the values (from Microsoft):

A value of 0 (zero) configures Windows so that it cannot establish security associations with servers that are located behind NAT devices. This is the default value.
A value of 1 configures Windows so that it can establish security associations with servers that are located behind NAT devices.
A value of 2 configures Windows so that it can establish security associations when both the server and the Windows Vista-based or Windows Server 2008-based VPN client computer are behind NAT devices.

I’ve read on a Forum that a person had to follow the below process in order to get it working (when I tried I never had to, but I guess better mention it):

  • Add the Key above, but give it value 1.
  • Reboot.
  • Modify the Key’s value to 2.
  • Reboot

Should you have more issues with Windows 7/Windows Server 2008, try with applying this Hotfix (requires reboot):

Step by Step instructions

  • Open RUN by pressing the Windows key + R, type regedit and press Ok. Alternatively, if you’re on Windows Vista and above, click Start and type regedit and press Enter once the Registry Editor’s icon appear.
    • Regedit icon: regedit-start-search
    • From Run:
  • Navigate all the way to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent (or HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec for Windows XP).
  • Right click on PolicyAgent (or in an empty spot on the right pane) and click New > DWORD (32-bit) Value.
    • regedit-new-dword-32bit-value
  • Name it AssumeUDPEncapsulationContextOnSendRule. Note, if you saved it with the default name, you may rename it by right clickcing on it > Rename. If it already exists, go to the next step.
  • Right click on the newly created DWORD and select Modify (or double click on it).
  • Under Value data type 2 and click Ok.
    • regedit-modify-value-data
  • Close the Registry Editor and reboot your computer.

Now you should be able to connect to the VPN.

Read More