RRAS won’t start with 8007042a or event ID 7024, aka the “routing remote access unable to load Iprtrmgr.dll”

(This is KCotreau's original answer, but he included it in the question. Re-posting as an actual answer)

Cause: There are two basic causes for this error.

1. An incorrect key in the registry if you are running IPv6.
2. TCP/IPv4 corruption.

Related causes

This has happened to me on a couple of Dell Windows 2003 R2 64-bit servers that had Broadcom NetXtreme II adapters. My problem was the second cause above, TCP/IP corruption, which I believe that happens for some reason when you install the driver for the Broadcom adapter. It certainly may happen with other adapters, but there were definitely a high number of unsolved cases on the Internet with various Broadcom adapters.

Additional factors

This happened even on clean installs as I tested using both the Dell-specific Windows Server 2003 R2 media, and Microsoft media downloaded from the Volume License site. It happens with either media.

Troubleshooting that did not work for me, or most people on the Internet:

1. Reinstalling clean.
2. Running sfc /scannow (I got no errors).
3. Comparing, and replacing, the iprtrmgr.dll’s from a working server.
4. Reinstalling the NIC’s after deleting them from Device Manager.
5. Running NETSH INT IP RESET C:\reset.log or NETSH RESET WINSOCK.
6. Running NETSH WINSOCK RESET.
7. Checking for ghost adapters after setting devmgr_show_nonpresent_devices=1 and then showing hidden devices in Device Manager (I had none).
8. Reregistering Oledb32.dll and Oledb32r.dll , and renaming C:\Windows\System32\ias \dnary.mdb, and ias.mdb files and restarting RRAS. Those files are located in the C:\Windows\SysWOW64 directory on 64-bit systems. This was in KB840696 http://support.microsoft.com/kb/840686.

Solutions

1. If you have Server 2008, and are running TCP/IPv6, your problem is probably not TCP/IPv4 corruption, but rather that you have this extra key, HKEY_LOCAL_MACHINE\System\currentcontrolset\services\remoteaccess\routermanagers\IPV6, which you will remove after you back it up by exporting it. Removing this key was an easy solution that widely helped many people on the Internet. If you still want to use the TCP/IPv6 protocol you may have to do more. Since I did not apply to my server, and I could not test it, you may still have IPv6 corruption, and may want to troubleshoot by removing and reinstalling the TCP/IPv6, akin to the solution below. The above solution may just be masking potential corruption by avoiding the issue.

2. If you are not running IPv6, the chances are that you have TCP/IPv4 corruption, and the solution is to reinstall it. If you have never noticed, if you try to uninstall TCP/IP, it is grayed out. To get around that, I followed KB 325356: http://support.microsoft.com/kb/325356 . That says it is for a domain controller, but works on member servers also. The steps are:

   • Just in case, disable RRAS in the RRAS mmc, as this will uninstall it.
   • Backup your registry.
   • Ignore steps 1-4, and step 21 if you are just on a member server.
3. Restart the domain controller.
4. When the BIOS information appears, press F8.
5. Select Directory Services Restore Mode, and then press ENTER.
6. Use the Directory Services Restore Mode password to log on.
7. Click Start, and then click Run.
8. In the Open box, type regedit, and then click OK.
9. Locate the following registry subkeys:
   • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock
   • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock2
10. Right-click each key, and then click Delete.
11. Click Yes to confirm the deletion of each key.
12. Close Regedit.
13. Locate the Nettcpip.inf file in %winroot%\inf, and then open the file in Notepad.
14. Locate the [MS_TCPIP.PrimaryInstall] section.
15. Edit the Characteristics = 0xa0 entry and replace 0xa0 with 0x80.
16. Save the file, and then exit Notepad.
17. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then select Properties.
18. On the General tab, click Install, select Protocol, and then click Add.
19. In the Select Network Protocols window, click Have Disk.
20. In the Copy manufacturer's files from: text box, type c:\windows\inf, and then click OK.
21. Select Internet Protocol (TCP/IP), and then click OK. (Note: This step will return you to the Local Area Connection Properties screen, but now the Uninstall button is available).
22. Select Internet Protocol (TCP/IP), click Uninstall, and then click Yes.
23. Restart your computer, and then select Directory Services Restore Mode as mentioned in steps 2 - 4.
24. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then select Properties.
25. On the General tab, click Install, select Protocol, and then click Add.
26. In the Select Network Protocols window, click Have Disk.
27. In the Copy Manufacturer's files from text box, type c:\windows\inf, and then click OK.
28. Select Internet Protocol (TCP/IP), and then click OK.
29. Restart your computer.

Configure and Enable Routing and Remote Access. At this point, your RRAS should start.

Related problem and solution:

When I would enter a static IP address, although it would hold the static, the properties would reset back to "Obtain an IP address automatically". Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network and delete the Config key. Reenter your static settings, and they should hold, and rebuild that Config key.

I hope this solves this difficult problem for many of you.

I know this is a hecking old post, but the same unhelpful error comes up even in Server 2016.

Luckily, for me the cause was mismatched certificates between IIS and RRAS.

The fix was to use the same certificate for the default IIS site as I was using in RRAS.

RRAS on Server 2019 and 7024 or 20269/20153 events from RemoteAccess, after 4405 event from NPS

I changed the LogFile path in NPS -> Accounting. Afterwards RRAS started.

The solution in my case was quite simple:

• Deactivate Routing and Remote Access server
• Reactivate and configure Routing and Remote Access server. Fortunately, we do not have a complicated configuration...