Reset Search



KB25581 - Pulse Secure Desktop (Windows or macOS) client is intermittently disconnecting for multiple users at random intervals

« Go Back


Last Modified Date3/7/2022 6:21 AM
This article describes the issue of Pulse Secure Desktop client being frequently disconnected for multiple users. This issue is only applicable to Pulse Secure Desktop client. This issue can occur, if multiple users have the same guid string value for the local machine ID in the Connection Store file. This file is created during the initial installation of the Pulse Secure Desktop client. The issue is intermittent and can occur at any time during the session. At other times, the session is not affected and the user may stay connected, until they sign out.

The following information is verified by Ivanti Development Team

To verify this issue kindly capture server debug log with Event code: web, radius & Log Level : 50

From the server debug logs search for the following log strings:

2022/02/10 13:22:06.174482 radius(27422) vc0 20 SBR sbrplugin.cpp:1064 - (9a058210)EAP-JUAC: JNPR_UAC_CLIENT_ID 379c4cdba3c041ba8301035488396da9
2022/01/06 19:04:14.130734 radius(3440) vc0 20 sbrauth - Removing session sidb7ff59b0a44e553dc3b5a9dba076b16a0217d50049729614 with same channel

Check If JNPR_UAC_CLIENT_ID is matching with another user JNPR_UAC_CLIENT_ID.

To root cause this issue, it is recommended to collect the following logs:

1. Server Debug Log (event code: web, radius and Log level: 50)
(Note: Recommend t perform this under planned maintenance window, This will bring down the performance of the system considerably and sometimes even can crash the device..)
2. System Snapshot
3. All IVE Logs
4. Screenshots of the behavior and overview page
Problem or Goal
Multiple users report intermittent disconnects with the Pulse Secure Desktop client.  There is no specific interval when this issue will occur as it will depend if the multiple user are attempting to login to the PCS device with the same machine guid.  The end user may see no error message when the issue occurs.

This issue will occur when Pulse Secure Desktop client is preinstalled on a base image which is used to deploy to multiple machines.  If this is true, the local machine ID stored in the connection store file may be the same on multiple machine.

When a Pulse Secure Desktop client connects to the PCS device, some session data is sent including the local machine identifier in the connection store file.  The Pulse Connect Secure device identifies each user sessions by the local machine identifier and expects this value to be unique. If multiple connections are sending the same machine identifier, the PCS device will terminate the oldest session for security reasons.

To determine if Pulse Secure Desktop client users are affected by this issue, collect the from the multiple Pulse Secure Desktop client (File > Logs > Save As).  From the logs, browse to the Connection Store folder and open the connstore.dat file. With a text editor and locate the following parameter:

machine "local" {
     guid: "d96b50d4275ef266d402348641e6b57b10b48bd3"
     pulse-language: "en-US"

If the guid string is identical across multiple client PC's, then this confirms the issue.


Pulse 5.0R1 and above (Windows Only):

The Pulse Secure Desktop installer has a new flag called SHAREDINSTALL. This flag should be set to 1, as shown in the following example, when the installer is being used to create a base shared image that will be deployed to multiple computers. When set to 1, it will install the Pulse application on the image without starting any processes. This will prevent the guid parameter from being generated on a shared image installation. This unique guid parameter will be auto-generated when the Pulse Secure Network Service are started for the first time on the actual machine.

To implement this mode, add "SHAREDINSTALL=1" to support deployment on a shared operating system image.

Example:   msiexec -i <MSI FILE PATH> SHAREDINSTALL=1


  • SHAREDINSTALL and CONFIGFILE (preconfiguration file) flags cannot be used at the same time.

If deploying a pre-configuration file is required, the following command will need to be manually executed or scripted on the end user machine once the image has been deployed.

  1. Navigate to C:\Program Files (x86)\Common Files\Pulse Secure\JamUI via command line
  2. Run jamCommand.exe -importFile <PRECONFIGURATION PATH>

Mac OS X:

Starting with Pulse Secure Desktop 5.0R1, DeviceID (in /Library/Application Support/Juniper Network/Junos Pulse/ directory) is created during the initial startup of Pulse application to ensure the machine guid is unique per each device.  After this point, Pulse Secure Desktop client will check the DeviceID file to ensure the value matches the connstore.dat.  If there is any mismatch, the value in the DeviceID will be written to the connstore.dat.

Pulse 5.0R1 and below:

In the following versions, deploying Pulse Secure Desktop client on a shared operating system image is not supported.   The following manual solution can be implemented if machines have been deployed with a duplicate machine guid.

When deploying Pulse Secure Desktop client, which is pre-installed for a Windows OS image being shared across multiple endpoints, the guid value for the local machine should be removed from the configuration file after installation. This ensures that the configuration data files in the root image does not contain a guid value that would be replicated on all machines.  A new and unique guid value will be generated for each user when Pulse Secure Desktop client is launched and run for the first time.

Perform the following procedure to reset the guid for users who have already installed Pulse Secure Desktop client and have duplicate guid values in the configuration file:

  1. Browse to C:\Program Files(x86)\Common Files\Juniper Networks\Connection Store and open the connstore.dat file in a text editor.
  2. Locate the following parameter:
machine "local" {
    guid: "41cbc0d2a1a100855755b4355d6d2579836694cd"
    pulse-language: "en-US"
  1. Remove the guid value from the parameter by deleting the entire second line. This will change the parameter setting to:
machine "local" {
    pulse-language: "en-US"
  1. Save the modified connstore.dat file to the original directory.

    Note: It may be necessary to edit the connstore.dat file in a Text Editor, which is ,Run As Administrator if these changes are made locally from the affected PC, due to the folder and file permissions that are set on the directory.
  2. Go to Task Manager > Services tab, locate and stop the JuniperAccessService service, and/or reboot the device to restart the service. When the service is restarted and Pulse Secure Desktop has been launched again, a new and unique guid will be generated and stored in the user's connstore.dat file.

Note : In some cases, we may need to perform additional step below if the GUID still does not change :

Delete the registry key below :

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Juniper Networks\Device Id Reboot the PC.
The GUID value generated should now be different.

On Mac OS X the following script can be used:

Pulse 4.0 and below:
# stop pulse access service
# remove local guid from connstore.dat
# restart service
sudo launchctl unload /Library/LaunchDaemons/
sudo sed -i .bak "/guid/d" "/Library/Application Support/Juniper Networks/Junos Pulse/connstore.dat"
sudo launchctl load /Library/LaunchDaemons/

Pulse 5.0 and above:
# stop pulse access service
# remove local guid from connstore.dat
# restart service
sudo launchctl unload /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo rm -rf "/Library/Application Support/Pulse Secure/Pulse/DeviceId"
sudo sed -i .bak "/guid/d" "/Library/Application Support/Pulse Secure/Pulse/connstore.dat"
sudo launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist


Note: The connstore.dat file also contains the connections that are displayed in the Pulse Secure Desktop UI, when it is launched. It is recommended that the above procedure be performed to modify only the portion of the connstore.dat file which was specified above to resolve this issue, as opposed to deleting the connstore.dat file from the user's machine. If the connstore.dat file is deleted from the machine, the user will need to manually recreate any and all connections that they regularly access.

Related Links
Attachment 1 
Created ByData Deployment



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255