Juniper Networks Virtual Adapter suddenly disappeared, can't be fixed via MSI Repair or reinstalling   Just happened out of the blue. This is an enterprise managed endpoint. I'm a Domain Admins with local admin privileges. No other VPN Client on here, nothing Cisco.   jnprvamgr.sys exists in "C:\Windows\System32\drivers" The other .sys files (jnprns and jpnrva) don't exist in that location   I tried repairing using the MSI, tried uninstalling and cleaning out and Pulse-related files and registry entries, tried (re)installing various clients (9.1R12, 9.1R15, ISAC 22.2R1.0), they all installed except the Juniper Network Virtual Adapter just isn't there (yes, I forced Device Manager to show hidden device).   Box has Ethernet only.   Also tried without McAfee ENS 10.7, same results, so it's not AV interfering.   C:\>sc query jnprvamgr SERVICE_NAME: jnprvamgr TYPE : 1 KERNEL_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0   C:\>sc query jnprns [SC] EnumQueryServicesStatus:OpenService FAILED 1060: The specified service does not exist as an installed service. C:\>sc query jnprva [SC] EnumQueryServicesStatus:OpenService FAILED 1060: The specified service does not exist as an installed service.       Here are the entries of "C:\Windows\INF\setupapi.dev.log" initially, all showed success but the Juniper Network Virtual Adapter still not installed   When repairing then it will show:   >>> [Deinstall network driver] >>> Section start 2022/12/08 18:33:12.834 cmd: C:\WINDOWS\system32\netcfg.exe -v -u jnprns dvi: Driver still has references, so no changes made <<< Section end 2022/12/08 18:33:12.881 <<< [Exit status: FAILURE(0x0004a023)]   >>> [SetupCopyOEMInf - C:\WINDOWS\System32\DriverStore\FileRepository\jnprva.inf_amd64_441cf03fe65c02d4\jnprva.inf] >>> Section start 2022/12/08 18:33:14.526 cmd: C:\Windows\System32\MsiExec.exe -Embedding 02FAB73841FBDB7F299CA3396A2E159A E Global\MSI0000 inf: Copy style: 0x00000008 inf: Driver Store Path: C:\WINDOWS\System32\DriverStore\FileRepository\jnprva.inf_amd64_441cf03fe65c02d4\jnprva.inf inf: Published Inf Path: C:\WINDOWS\INF\oem60.inf <<< Section end 2022/12/08 18:33:14.526 <<< [Exit status: FAILURE(0x00000050)]   >>> [SetupCopyOEMInf - C:\WINDOWS\System32\DriverStore\FileRepository\jnprvamgr.inf_amd64_f7b27300cbd1f456\jnprvamgr.inf] >>> Section start 2022/12/08 18:33:14.947 cmd: C:\Windows\System32\MsiExec.exe -Embedding 02FAB73841FBDB7F299CA3396A2E159A E Global\MSI0000 inf: Copy style: 0x00000008 inf: Driver Store Path: C:\WINDOWS\System32\DriverStore\FileRepository\jnprvamgr.inf_amd64_f7b27300cbd1f456\jnprvamgr.inf inf: Published Inf Path: C:\WINDOWS\INF\oem61.inf <<< Section end 2022/12/08 18:33:14.947 <<< [Exit status: FAILURE(0x00000050)]   etc   ... View more

KB45227 on June 06, 2022 was about the "Pulse Desktop Client disconnects with Password Expiration Prompt and connects back automatically" (24855 Days) issue which Pulse acknowledged in  PRS-411805.   If PRS-411805 has in fact been fixed in ICS/PCS 9.1R16 supposedly to address the issue described in KB45227, why wasn't KB45227 updated to reflect that?   Instead KB45227 article appears to have been taken down completely, even though many running ICS/PCS 9.1R15 are still experiencing this issue. This behavior by Ivanti / Pulse internal documentation team puzzles us.   Would anybody from Ivanti/Pulse please chime in to enlighten us about the above subject? ... View more

This is just an FYI for forum users/other admins. We have already opened a case with Support.  It's affecting a bunch of new users.   -----------------------------------   This is affecting users of ALL of our virtual appliances, both those appliances running the latest PCS 9.1R15 and those running previous PCS 9.1R12   After Microsoft Internet Explorer has been retired, an issue starts occurring to new user who connects over the web to use Terminal Services (using any browser e.g. Chrome, Edge, Firefox). PSAL would always throw "Detect Internal Error".   Those users have never had any Pulse helper component installed on their system. When they connect, they're prompted to download PSAL. After they downloaded and installed PSAL, it prompted them to install (requires admin privileges) the ActiveX components OCX and OCX64 of Pulse Secure Setup Client. After that PSAL was supposed to invoke the Pulse Setup Client to download and install Host Checker, etc but throw "Detect Internal Error"   This is happening when connecting to appliances running either PCS 9.1R12 or 9.1R15.   This is happening regardless whether the endpoint is running Windows 10 20H2 or 21H2.   This is happening even on fresh clean plain-vanilla stock Windows 10.   This is happening even though the users have local admin privileges.   This is happening regardless of the browser the user uses (Google Chrome, Microsoft Edge, Mozilla Firefox)   This is happening EVEN IF all Pulse helper components (PSAL, Pulse Secure Setup Client, Pulse Secure Installer Service, Host Checker) are downloaded and installed MANUALLY (as MSI / EXE)   NOTE: If a user has already had all the Pulse helper components installed PRIOR to Internet Explorer retirement, those already-installed existing components appear to continue working without issue. This issue is only occurring to users who have never had Pulse helper components installed and attempt to do so AFTER Internet Explorer retirement date.   NOTE: Ivanti/Pulse Secure Support personnel and development/engineering should be able to reproduce this in their lab. Just set up a realm mapped to a role with TS enabled, and a HC policy set to Evaluate for that realm then connect from a fresh Windows 10 box which has never ever had any Pulse helper components on it. ... View more

Question for Pulse Secure Support folks if they're around:   I am seeing this behavior on all Pulse Desktop Client (PDC) 9.1R12 connecting to an appliance running the latest Pulse Connect Secure (PCS) 9.1R14.1   So, when Pulse Desktop Client is installed on a Windows 10 endpoint, the INTERNAL Host Checker which came with the PDC installation is located here:   "C:\Program Files (x86)\Common Files\Pulse Secure\TNC Client Plugin"   However, even though the "Auto-Upgrade Host Checker" option is CHECKED/ENABLED on the appliance, when PDC 9.1R12 connects and establishes a VPN tunnel (full tunnel) with PCS 9.1R14.1 appliance, the files for that INTERNAL Host Checker in "C:\Program Files (x86)\Common Files\Pulse Secure\TNC Client Plugin" are never updated to the same version of Host Checker on the 9.1R14.1 appliance.   When I viewed "C:\Program Files (x86)\Common Files\Pulse Secure\TNC Client Plugin\versionInfo.ini", it still shows the original 9.1.10249 inside.   The question is:  Is the PDC's INTERNAL Host Checker which came with PDC installation and stored in "C:\Program Files (x86)\Common Files\Pulse Secure\TNC Client Plugin" supposed to be upgraded automatically when "Auto-Upgrade Host Checker" is ENABLED?  Or will it always stay the same version as originally came with the PDC installation?   NOTE:  Whereas the EXTERNAL Host Checker (invoked by browser) stored in "C:\Users\USERNAME\AppData\Roaming\Pulse Secure\Host Checker" upgraded to the new version (same as the one on the appliance) just fine. ... View more

Up to PCS 9.1R11.5, "PSSetupClientInstaller.dmg" was living at:   https://<PUBLIC_HOSTNAME>/dana-cached/sc/PSSetupClientInstaller.dmg   Starting with PCS 9.1R12, users couldn't find it at that path any longer, in case they need to MANUALLY install Pulse Secure Setup Client on macOS.   Does anybody know the path to it, or where Pulse moved it to? ... View more

How do we attach a screenshot to a post in this forum? Or only ADMIN and MOD can do that?   It would be clearer to illustrate an issue if an image is allowed, even if it's a sanitized/redacted image. ... View more

Pulse Connect Secure 9.1R12 Host Checker component has a major issue: it CANNOT find Machine Certificate.   We have a Host Checker policy to check to make sure machine certificate was issued by our Enterprise CA.   We upgraded the appliance from PCS 9.1R11.5 to PCS 9.1R12   When using Pulse Clients 9.1R10, 9.1R11.5, 9.1R12, when the Client attempted to invoke internal host checking (the host checking component was sent by the PCS 9.1R12 appliance, presumably), it simply cannot find the Machine Certificate on Windows 10, even though "certlm.msc" clearly shows the Machine Cert exists.   This issue did NOT exist on 9.1R11.5 ... View more

I've already notified Pulse Secure support folks.   I opened a case 00449355 today for something else.  I noticed that we did NOT receive via EMAIL any Case Comments which Pulse Secure support engineers put in the Case Center for that particular case, even though when the Pulse support engineer emailed us directly, we'd get it just fine.   Not only that, none of the email addresses we put in the CC list actually received any of those Case Comments either.   Something is seriously broken there. ... View more

When will Pulse Connect Secure 9.1R11.4 (to address SA44784) be available? ... View more

Certain discussions in previous threads weren't clear to me.   I have a bunch of users who connect over the web, authenticate via SAML then LDAPS, then use Pulse Terminal Services Client to RDP.   Let's say when my existing appliances running PCS 9.1R8.2 / PCS 9.1R10 are upgraded to the 9.1R11.x FIXED RELEASE (assuming it's released tonight),   when a user (who's already had the older PSAL / Pulse Setup Client / Pulse Terminal Services Client installed in their Windows profile "\AppData\Roaming\Pulse Secure" previously fetched from PCS 9.1R8.2 / PCS 9.1R10) connects to the newly upgraded appliance which will be running the 9.1R11.x FIXED RELEASE:   ---> will those existing Pulse components in the user's profile be automatically updated to a newer version of PSAL / Pulse Setup Client / Pulse Terminal Services which addressed this issue?   From what I see, Pulse Setup Client might be the component with the bad implementation which checked for code-signing cert expiration instead of checking whether the code signing time falls into the period for which the code-signing cert was valid. ... View more

Pulse Connect Secure 9.1R8.2 and its Host Checker are highly problematic   Here is the summary of the issue we encountered:   Realm has SAML as first Auth Server, and LDAP(S) as second Auth Server. Host Checker set to EVAL at the realm level.  Host Checker restriction is enforced at the Role level ("Allow users whose workstations meet the requirements specified by these Host Checker policies"). User logs on to this realm via their web browser, and once authenticated successfully and passed HC policy, they will be mapped to TS role and HTML5 Remote Desktop role.  GLOBAL Host Checker periodic reevaluation interval is set to 10 minutes.  Host Checker timeout is set to 20 minutes.   Back when we ran Pulse Connect Secure 8.3R7.1, 9.0R4: When user logs on to the realm via a web browser (e.g. Chrome), browser will invoke PSAL and prompt the user to allow Host Checker to run the first time. HC runs and evaluates at the realm level. User is mapped to role (qualified at the role level) because they pass HC policy. When user gets to the main Pulse web portal, they're once again prompted to let Host Checker run. The second Host Checker process "dsHostChecker.exe" runs and promptly calls home every 10 minutes to report reevaluation results to the appliance (and indicated to the appliance which user was in compliance).   With Pulse Connect Secure 9.1R8.2:  When user logs on to the realm via a web browser (e.g. Chrome), browser will invoke PSAL and prompt the user to allow Host Checker to run. HC runs the first time and evaluates at the realm level and User Log would show:   AUT22923 Host Checker policy 'SOME-HC-POLICY' passed on host xxx.xxx.xxx.xxx for user '[email protected]'   After that, even though the user had authenticated successfully, and qualified at the Role level, and is mapped to roles (because they passed HC policy), PCS 9.1R8.2 appliance never prompted the user to run Host Checker again the second time (unlike PCS 8.3R7.1 or PCS 9.0R4). Instead the first instance of "dsHostChecker.exe" continues to run in the background and called home but did not report WHICH USER was in compliance.  In the User Log, it simply indicated at the first 10-minute mark (first reevaluation) that:   AUT22923 Host Checker policy 'SOME-HC-POLICY' passed on host xxx.xxx.xxx.xxx   Then at the 20-minute mark when the HC timeout interval is reached, even though the user had already logged in and had been using Pulse TS / HTML5 Remote Desktop for 20 minutes by this time, User Log would show:   AUT23447 Host Checker running on host xxx.xxx.xxx.xxx will exit as the user login timed out. AUT22927 System process detected a Host Checker time out on host xxx.xxx.xxx.xxx for user '[email protected]'   then PCS 9.1R8.2 appliance immediately killed the user's VPN session, and the user got logged out and lost their TS / HTML5 Remote Desktop sessions.   ---> We only upgraded to 9.1R8.2 because of Security Advisory SA44588 ( https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44588 ). We are very unhappy with this behavior exhibited by Pulse Connect Secure 9.1R8.2 and its Host Checker, which did not occur in previous releases. This has caused our user population plenty of grief.  The only workaround to maintain production for our organization is either increasing Host Checker timeout interval to a very large interval or setting the periodic reevaluation interval to 0 (which means evaluate at the beginning of the session only).   This problem might be either related to or is a variant of PRS-390488 "Host checker is getting timed out (can be seen on user access log) and user is getting logged out" which Pulse Secure has never resolved. ... View more

https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44503/   In Security Advisories 44503, Pulse Secure advised us all to upgrade previous Windows Client 9.1R5 and older (such as 5.3R7.1, 9.0R4, 9.1R3.1) to 9.1R7 to address client-side vulnerabilities.   My question:   Most of our appliances are running Pulse Connect Secure 8.3R7.1 (pending replacement with PCS 9.1R7 to be built).   Since PCS 8.3R7.1 use different/older PSAL, different/older Pulse Setup Client, different/older Pulse Installer Service, IF I upload the Pulse Desktop Client (PDC) 9.1R7 package "ps-pulse-9.1r7.0-b2525-package.pkg" to those PCS 8.3R7.1 appliances and set that PDC 9.1R7 to be the ACTIVE CLIENT PACKAGE, will it PROPERLY/CORRECT install / upgrade existing older versions of Pulse Desktop Client 5.3R7.1 and 9.0R4 and 9.1R3.1 on my endpoints properly when those older Pulse Desktop Clients connect to those appliances?   The reason is ask is because PCS 8.3R7.1 use different/older PSAL, different/older Pulse Setup Client, different/older Pulse Installer Service.   The Security Advisory said in Question 5, "Question 5: How do I deploy the patched Pulse Secure Desktop clients to my endpoints?     Answer: If you intend to deploy a patched Pulse Secure Desktop Client, upload the client bundle to your PCS or PPS gateway, configure it as the active version, and have your end users connect to the gateway. The Pulse Secure Desktop Client will auto-upgrade upon connection.", ---> but since PCS is 8.3 branch and PDC is 9.1 branch are different, I am uncertain whether that will work correctly.   Any advice would be greatly appreciated.  Thanks. ... View more

Pulse Connect Secure 9.0R4 virtual appliance Pulse Client 9.0R4 for Windows x64 SecureAuth MFA + AD LDAP   Back when our Pulse Connect Secure was running 8.3R7.1, whenever we connect to the appliance using Pulse Client 5.3R7.1 or Pulse Client 9.0R4, it would launch Internet Explorer for authentication to SecureAuth MFA, then afterwards run ActiveX to launch external Host Checker. It will pass the 1st Host Checker policy and will fail the 2nd Host Checker policy.  However, because Global HC is set to "Perform dynamic policy reevaluation" = DISABLED, and the Realm-Level HC is set to EVALUATE, and the Role-Level HC is set to ALLOW ALL USERS, it will successfully map to the Layer 3 VPN role and establish the L3 VPN connection just fine. That external Host Checker process "dsHostChecker.exe" will remain active for the duration of the L3 VPN session and called home every 10 minutes to check in.   Now that our Pulse Connect Secure appliance is upgraded to 9.0R4, whenever we connect to the appliance using Pulse Client 9.0R4, it would launch Pulse Client's built-in browser and apparently used "PulseSecureService.exe" Service for Host Checking. The logs on the appliance indicated that, just like before it passed the 1st Host Checker policy and will fail the 2nd Host Checker policy. However, because Global HC is set to "Perform dynamic policy reevaluation" = DISABLED, and the Realm-Level HC is set to EVALUATE, and the Role-Level HC is set to ALLOW ALL USERS, it will successfully map to the Layer 3 VPN role and establish the L3 VPN connection just like before.  ---> The problem is that AFTER 10 minutes (the defined interval for re-evaluation), the Pulse Client 9.0R4 for some reasons COULD NOT perform the periodic RE-EVALUATION at 10-minute interval, and it will immediately drop the L3 VPN connection.   This is causing major issue for us in migrating to 9.x (8.3Rx will reach end of support in October 2019) because we are required to have MFA in front and required to run Host Checker to determine who is allowed to have L3 VPN   Any thoughts as to why Pulse Client 9.0R4 with its built-in browser COULD NOT run Host Checker at periodic interval with our setup (MFA+LDAP)?  No matter what settings we have for Host Checker at Global Level, at Realm Level, or at Role Level, Host Checking just wouldn't run after 10 minutes, then the connection just dropped. ... View more

Is something wrong with the "download.pulsesecure.net"?   All our appliances have not been able to download the "epupdate_hist.xml" since last night   https://download.pulsesecure.net/software/av/uac/epupdate_hist.xml   When manually going to the above link and entered the download credentials, "download.pulsesecure.net" threw a "401" error. ... View more

Pulse Connect Secure 8.3R3, 8.3R6, etc.   Many of our users run the McAfee consumer endpoint protection product on their called "McAfee Total Protection" version 16.x various releases (R13, R15, etc.)   We were using ESAP 3.2.8 SDK v4.  Many of our users complained that Host Checker could not detect their McAfee Total Protection 16.x product (with the latest updates dated 10/11/2018) and Host Checker kept throwing error about their Windows 10 Windows Defender real-time protection isn't enabled. Error message is "Windows Defender 4.13.xxxxx.x" does not comply with policy. Compliance requires real time protection enable." (naturally it's disabled because McAfee is installed).  As a result, they're unable to establish  VPN connection.   Pulse Secure stated in the Release Notes for ESAP 3.3.1 that 3.3.1 supports McAfee Total Protection 16.x:   https://www.pulsesecure.net/download/techpubs/current/1404/pulse-connect-secure/esap/3.3.x/ps-esap-3.3.1-releasenotes.pdf   ---> Even after we uploaded and activated ESAP 3.3.1 and the Host Checker on the users' home machines were upgraded, Host Checker with ESAP 3.3.1 OPSWAT SDK v4 still couldn't detect McAfee Total Protection 16.x at all.   Anyone else encountering the issue?  This is most frustrating, as it resembled similar issue with Norton Security Suite 22.12.0.104 back in mid-March 2018. ... View more