The virtual adapter was not set up correctly due to a delay. GlobalProtect will try again soon.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

The virtual adapter was not set up correctly due to a delay. GlobalProtect will try again soon.

L3 Networker

Hi Team

 

After upgraded the Global protect from 4.1.9 to 5.1.8. Few of the Gp clients not connected. If I repair the Global protect its working fine.

 

So checked the PANGP event logs and found  the below error 

 

Tunnel is down due to disconnection.
01/28/2021 11:21:33.772 [Error]: Failed to get default route entry

01/28/2021 11:21:33.772 [Info ]: Tunnel is down due to disconnection.
01/28/2021 11:21:34.354 [Error]: 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.

 

Please help us to fix the issue. Why its showing error after upgrade the GP to 5.1.8 version

 

Regards

Mohammed Asik

1 accepted solution

Accepted Solutions

L1 Bithead

Dear PAN Engineers, Customers, seeking for help on error:

"The virtual adapter was not set up correctly due to a delay. GlobalProtect will try again soon"

We have encountered random computers who have suddenly stopped connecting to global protect.

Reinstalling Global Protect doesn't fix the issue, none of the steps discussed here fix it.

The discovery was made that Windows 10 21H1 update affects WMI 

The best diagnostics you can do is enter into start-->run-->msinfo32 or msinfo32 into cmd prompt.

If you see errors that WMI was moved or inaccessible  you can try Microsoft Article:

https://answers.microsoft.com/en-us/windows/forum/all/cannot-access-the-windows-management/75284a7d-...

 

 

What fixed my issue was 

 

Winmgmt /resetrepository

 

msinfo32 functionality restored ( I can see data )

Global Protect connects without an issue.

 

Please note, WMI service was always running.

 

View solution in original post

17 REPLIES 17

L0 Member

Any solution?

L1 Bithead

What was the solution?

L1 Bithead

Had this problem also. Uninstall/reinstall fixed it for a few weeks, but I just had one laptop have the same issue again. Machine is W10 20H2 client is 5.2.4-21

 

 

L0 Member

Does anybody knows what to do with that?

L2 Linker

I have the same issue, Did you get any solution? @MohammedAsik 

L2 Linker

@MohammedAsik @aljadot @Dekkar @bartlettj @mcloudteo GP assigning static IPs to clients 

I found a workaround/fix to this problem. 

Resolution:

1) Make sure it is not the problem with the drivers, for this check your device manager and uninstall the Virtual adapter by checking the uninstall the driver software as well and then uninstall and reinstall the GP client. If this does not fix the issue, follo these steps.

    • Disable WMI services : run - services.msc - Windows Management Instrumentation(WMI) - stop the service.
    • Delete the files under C:\Windows\System32\wbem\Repository
    • Open regedit
      Go to HKEY_LOCAL_MACHINE > Software and HKEY_CURRENT_USER > Software. Delete the Palo Alto Networks folder.
    • Delete the same if the same folder is present in any other user under HKEY_USERS.
    • Un-install GlobalProtect from Windows 'program and features'.
    • Make sure that the virtual adapter in not present in the Network adapter settings.
    • Reboot the machine.
    • Reinstall GlobalProtect with admin privileges.
    • Confirm that WMI service is running.

    This should resolve the issue.

L1 Bithead

Dear PAN Engineers, Customers, seeking for help on error:

"The virtual adapter was not set up correctly due to a delay. GlobalProtect will try again soon"

We have encountered random computers who have suddenly stopped connecting to global protect.

Reinstalling Global Protect doesn't fix the issue, none of the steps discussed here fix it.

The discovery was made that Windows 10 21H1 update affects WMI 

The best diagnostics you can do is enter into start-->run-->msinfo32 or msinfo32 into cmd prompt.

If you see errors that WMI was moved or inaccessible  you can try Microsoft Article:

https://answers.microsoft.com/en-us/windows/forum/all/cannot-access-the-windows-management/75284a7d-...

 

 

What fixed my issue was 

 

Winmgmt /resetrepository

 

msinfo32 functionality restored ( I can see data )

Global Protect connects without an issue.

 

Please note, WMI service was always running.

 

Thanks!

Using the Winmgmt /resetrepository worked for me, and I wasn't seeing any errors when launching the msinfo32
I believe the WinMgmt command stops the service for you, as initially I had an error that there were dependencies to the service.
When I stopped the service, which informed me there were two Dell services dependent on it, then I could successfully run the command.

I hadn't checked if the WMI or Dell services had restarted, so hopefully nether of these were causing the GP failure.

Sadly it didn't work for me. When I use it:

winmgmt /resetrepository
Fehler beim Zurücksetzen des WMI-Repositorys
Fehlercode: 0x8007007E

So I get an error. I tried it in user and administrator context.

L1 Bithead

Hello guys,

 

I have same problem but on MacOS. I dont find anything this issue. Has anyone had a similar problem on macOS and found a solution?We have been using version 5.2.11 for a long time in GP.

bilal_guclu

L0 Member

FYI, if resetting the WMI Repository doesn't work, and an sfc and dism repair doesn't work, disabling the Dell Data Vault services (they depend on WMI as well), and running this script and rebooting worked for us:

FIXWMI.CMD
------------------------

@echo on
cd /d c:\temp
if not exist %windir%\system32\wbem goto TryInstall
cd /d %windir%\system32\wbem
net stop winmgmt
winmgmt /kill
if exist Rep_bak rd Rep_bak /s /q
rename Repository Rep_bak
for %%i in (*.dll) do RegSvr32 -s %%i
for %%i in (*.exe) do call :FixSrv %%i
for %%i in (*.mof,*.mfl) do Mofcomp %%i
net start winmgmt
goto End

:FixSrv
if /I (%1) == (wbemcntl.exe) goto SkipSrv
if /I (%1) == (wbemtest.exe) goto SkipSrv
if /I (%1) == (mofcomp.exe) goto SkipSrv
%1 /RegServer

:SkipSrv
goto End

:TryInstall
if not exist wmicore.exe goto End
wmicore /s
net start winmgmt
:End

 

My servicedesk team ran this batch file to resolve this. So far it has worked on all PCs. We are running GP 6.0.4-c26

 

C:\Windows\System32\Wbem. @echo off sc config winmgmt start= disabled net stop winmgmt /y %systemdrive% cd %windir%\system32\wbem for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s wmiprvse /regserver winmgmt /regserver sc config winmgmt start= auto net start winmgmt for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s

Running this script and rebooting resolved the issue on a few PCs for me lately.

  • 1 accepted solution
  • 254077 Views
  • 17 replies
  • 3 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!