For those of you out there who are fortunate enough to have a personal lab environment for tinkering about with all things Microsoft, there is a wealth of learning opportunities that this can afford. Typically, this will help to reinforce your knowledge within areas relevant to your current job role, but I often find myself learning about all sorts of weird and wonderful things that I would never have the courage to interact with during a normal working week, such as:
- Active Directory Domain management.
- Server upgrades (for example, I recently went through an upgrade from Windows Server 2015 to 2019 on one of my VM’s and, in the process, learned about how you need to run the adprep command when upgrading domain controllers)
- DHCP
- Hyper-V
- Managing SQL Server and on-premise Dynamics CRM/365 Customer Engagement instances
- Routing and Remote Access configuration
Invariably, there will be a high degree of trial and error involved here, with the added benefit of having nobody shouting at you if you make a goof that could have catastrophic effects within a live production environment. As a trade-off, you may find yourself hitting a brick wall with frequent issues, with no effective recourse (except the most obvious one) to resolve your problems.
An excellent example of an issue like this can be found in some long-standing problems I was having with a Windows Routing and Remote Access VPN configuration. It would intermittently have problems connecting up successfully, leading to timed-out connections or error messages like the one displayed below within Windows 10:
Inspecting the Event Viewer logs with the VPN type option set toĀ AutomaticallyĀ orĀ Point to Point Tunnelling Protocol (PPTP) would produce more informative error messages, as indicated below:
Error Message: RoutingDomainID- {: No IP address is available to hand out to the dial-in client.
Error Message: RoutingDomainID- {00000000-0000-0000-0000-000000000000}: CoId={4B23BE14-CCDF-4D5A-A44D-EAE70475D1A0}: The user DOMAIN\User connected to port VPN4-223 has been disconnected because no network protocols were successfully negotiated.
In this particular setup, the machine configured with the Routing and Remote Access server had two network adapters - one being used by a Hyper-V adapter & for DHCP and a separate one, with an assigned IP from a different routers DHCP server. Based on this fact and the error messages above, I can only assume the server was having difficulty obtaining an IP address for any new VPN clients from the DHCP server on the same machine. Fortunately, there is a way in which we can tell the Routing and Remote Access service which IP address(es) to assign to new VPN connections. And, thankfully, the steps involved are straightforward:
- Open theĀ Routing and Remote Access Microsoft Management Console (MMC) snap-in.
- Right click on the server name and selectĀ Properties.
- Navigate to the IPv4 tab.
- Under theĀ IPv4 address assignmentĀ error, ensure that theĀ Static address pool option is selected and then press theĀ Add…Ā button.
- Based on your DHCP configuration, enter a range of IP addresses that will be assigned to clients connecting to the machine. In the example screenshot below, we have allocated six addresses from the range 192.168.89.150 through toĀ 192.168.89.155. Adjust the range to suit your particular needs. Make sure you select a range that isn’t already dished out or could be consumed by other clients:
- Press OK and thenĀ Apply to confirm the assignment.
Now, when you attempt to reconnect to the VPN, it should work as intended:
Whether the suggested solution in this article is suitable for a production environment, I cannot advise further on, but hopefully, the steps here might help somebody else who has come across the same issue when tinkering around within a lab/test environment š