Let's discuss a virtual adapter error with GlobalProtect that can affect it connecting properly after an upgrade.
Hello there everyone! I know from firsthand experience that issues with GlobalProtect after upgrades can be frustrating and confusing—especially when things were working perfectly fine before things were upgraded.
This DOTW blog covers a discussion about an error message that started appearing after upgrading their GlobalProtect software.
Discussion talking about the GP Virtual interface error
As Mohammed explains in the original message, everything was working fine with GlobalProtect 4.1.9, but after upgrading to 5.1.8, the VPN tunnel failed to connect.
The specific error being referenced is:
"The virtual adapter was not set up correctly due to a delay. GlobalProtect will try again soon. If the issue persists, please restart your system."
Many things have been tried to help resolve the issue, even going as far as to uninstall and reinstall of GP, but nothing seemed to work. That is until @PiankaMariuszchimed in with some help and a solution.
@PiankaMariusz noted that a Windows update was actually part of the issue. I've looked into it as well since reading the discussion.
It appears that the Windows 10 21H1 update affects part of WMI and can affect GlobalProtect.
WMI is actually the Windows Management Instrumentation service, which is the infrastructure for management data and operations on Windows-based operating systems. So, it can also affect the GlobalProtect service.
One of the diagnostics that can be performed is looking into msinfo32, which can be accessed via the CLI or via the "run" command in Windows.
Sysinfo32 running, showing the WMI service
There, you can verify that WMI is running properly.
Pianka then continued and provided a solution that worked for them, which I will also try to explain what happened and why this resolved the issue.
Since the WMI controls the management of Windows services, as well as components that GlobalProtect needs to function properly, any corruption in the WMI repository can cause issues.
In order to reset the WMI repository, you can run the following command via the CLI
Running that command will reset the repository to the initial state when the operating system is first installed. MOF files that contain the #pragma autorecover preprocessor statement are restored to the repository. After Pianka ran that reset command, they were able to connect again with GP without issue.
Not only is this a good and quick solution, it is a nice troubleshooting step for anyone in the future trying to troubleshoot similar issues.
I want to take a second and thank @PiankaMariusz for their help with finding a resolution for this issue.