Symantec Encryption Product Community

Does anyone have any experience with upgrading their version of PGP Desktop on the client causing PGPTray to no longer function properly?

I have a large number of machines on PGP Desktop version 9.10.0.500, we've created a silent install process primarily because of the sheer volume of machines being encrypted and their role within the workplace.  When peforming the silent install / enrollment on a clean client (no PGP installed), the install works flawlessly.  However, when performing the silent install on a client with 9.10 installed, upgrading to 10.0.2.13, the upgrade is successful with the exception that PGPTray stops functioning.  When you try to launch PGPTray post upgrade the service will start, then suddenly terminate.  Can anyone speak to this?  Is there something in the silent install that might cause this?  Why would it work for a clean install but not an upgrade?  Any information would be greatly appreciated.

Regards

I believe that PGP 10.0.3 is the first 10.x version that will not have this behavior if the keyrings are not in the default My Documents location.  Might this be your problem?

We observed this same symptom after McAfee anti-virus updates. It seemed to stop PGP services.

You can restart PGP services or logoff/logon again to correct the issue...a real nuisance.

I believe it is fixed to avoid the issue in most recent PGP version.

That could very well be.  The test machine which was upgraded from 9.1 to 10.0.2 shows the secring.skr file located in My Documents\PGP as a 0 byte file.  I'm testing now to see if that is in fact the cuase and will post my results here.  Thank you for the lead, Tom!

I've been having the same problem with version 10.0.2.built 13.  After doing a lot of root cause analysis (for about a year now), I think I've narrowed it down to our weekly McAfee AV update.  Through process of elimination, it finally became clear that the vast majority of our helpdesk calls reporting this problem were coming in on Thursday mornings. After several months of this trend, it was beyond coincidence that the only vector was this update.  The only deviation from this trend what when the user's computer was either shut off or literally off site (i.e. laptop) and was updated upon first opportunity. 

What has made this issue impossible to nail down is because it would only happen to about 20-30 users out of the 7,500 user install base. It never happened to the same user twice or if it did, the time span between incidents was so long, it went unnoticed. There are no errors in any of the logs or even any indications that any kind of a fault has occurred. It's almost like the PGP service has been shut down but not fully restarted (or something like that).

We've only come up with two work-arounds... Stop/Restart the PGPSERV service and restart PGP Desktop, or simply reboot. As I mentioned, it doesn't happen again after that.  The bottom line is, I can't prove a darned thing other than the fact that I need to upgrade my Universal server and update about 8,000 laptops and desktops.

I have a similar situation with a few machines that have been upgraded several times.

Did you use the "Override default KeyRing Locations" and change the default location of the keyring files in the policy group that these machines are currently under?  Is there a weird, or default, or excluded policy group these machines are falling under after the upgrade?

When you try to launch PGPTray post upgrade the service will start, then suddenly terminate.  Can anyone speak to this?  Is there something in the silent install that might cause this?  Why would it work for a clean install but not an upgrade?

I have a few questions:

Does this happen on every machine which receives the upgrade?

Is the start/stop behavior for PGPtray for just the first post upgrade boot, or does it persist beyond successive reboots?

I don't expect anything in the silent install would cause this. Are you using msiexec with switches to do the silent install/upgrade?

The primary difference that I would expect between an upgrade install and a clean install is the pgpprefs.xml file. For an upgrade there will be an existing file which the install modifies. The clean install will create a brand new pgpprefs.xml file. It may be worth getting a copy of the file from a clean install machine and from an upgraded machine and comparing them. The pgpprefs.xml is in %appdata%\PGP Corporation\PGP. (By default this will be C:\Documents and Settings\%USERID%\Applicaiton Data\PGP Corporation\PGP\ or C:\Users\%USERID%\AppData\Roaming\PGP Corporation\PGP)

Thank you everyone for your insights and input thus far on the problem.

To answer your questions, paulhen:

This happens on every machine which receives the upgrade, yes.  We've tried machines with different configurations, end result being the same.

The start/stop behavior for PGPTray post upgrade is for the first reboot, and every subsequent reboot thereafter.

We are indeed using msiexec with switches for the silent install.

I am in the process of comparing the two xml's now and will report my findings on that as well.

Thank you!

If you are running into the problem Tom referenced, there will be a difference in how the keyring file locations are specified.

If you log into a new user account on an upgraded machine what happens with the PGPtray.exe process?

Enabling debug logging may give you some additional information. The article on doing that is TECH149847. In cases like this one, I will sometimes add the registry settings to HKEY_LOCAL_MACHINE rather than to HKEY_CURRENT_USER

Is there anything in the PGP Desktop log or the Windows event viewer that may be relevant? The PGP Desktop log is in the same folder as the PGPprefs.xml. The current log is PGPlog.txt. The ones with numbers are from previous days.