File Share Encryption

Just patched our Universal Server to 3.2.1 (build 4940)

Server version still states 3.1.0 (build 860)

But think that's a separate issue.

Anyway.

Downloaded the new client from the server and installed the

PGPDesktop_en-US.msi

onto the XP machine.  But constantly get:

If I click close it carries on then does the following:

I click Don't Send and all is fine and it installs.  The build on the client says 10.2.1 (4940) all seems fine.

But can't work out what is causing those crashes when installing the client.  On the test lab I had setup I ran into the same issue.  But I did find a post around here someone mentioning how to either get around this or it was a different but seemingly related issue.  But I don't seem to have bookmarked that post or taken notes (annoying) and can't remember what settings it said, to turn off on the Universal Server, that would then stop this issue.

Any ideas?

Get the same error when installing the 64bit client onto a Windows 7 machine.

Do you have DEP enabled?  Try disabling DEP and see if you can install

Yes it will be on.  I haven't got one to test at the moment.  Odd thing is, if you say close message etc it carries on fine.

Have you tried doing a completely silent install?  Maybe then the message won't pop up

http://www.symantec.com/docs/HOWTO77014 

Not sure I'd trust a silent install on our setup.  It's a bit slapped together.  Sometimes get pass phases not matching on enrollment.  Even when you clear out all old keys from the server.

I just noticed that you stated that your build number on your PGP Universal Server is not reporting correclty. That is a sign of a much bigger problem. I would certainly work to get that issue resolved with support. There is not telling what happened there, possibly a failed upgrade?

I haven't seen this issue being reported again in a while since we are now on SYmantec Encryption Desktop 10.3.0 as the latest version. This was an issue that we saw on PGP Desktop 10.2.0 builds. You stated that the client reports build version 10.2.1 MP3 (build 4940)?

I am curious as to what the build version numbers of different .dll files on the machine are as well.

Is this happening on a client upgrade path or on a fresh installation of a new PGP desktop client? We saw the problem on the later and possibly these clients are 10.2.0 MPx right now and you are updating them to 10.2.1 so you are running into this problem? I have seen that occur before. Usually just disabling DEP for windows installer temporarily eleviates this headache. I've attached a .reg file you can use to do so. That way when you run the MSI - it will not prompt you in the UI for this DEP error. Our testing results have shown there is no problem with doing this - the installer is not broken. It's something to do with an check that we do with the SDK which is failing on DEP there. But it doesn't prevent the installer from installing the product correctly:

See http://www.symantec.com/docs/TECH175381 for more info on the original problem in 10.2 that we saw with this.

Attachment(s)

DEP.Reg_.txt   376 B 1 version

one last comment, if you have a backup, and you aren't too far into the deployment. you might want to look at restoring from a backup of your 3.0.1 Build 860 server to a newer release such as 3.1.2 Build 50 or 3.2.0 Build 2599, then upgrading to 3.2.1 Build 4940.

3.0.1 Build 860 had several major bugs and while the upgrade path should just be as easy as:

3.0.1 Build 860 --> 3.2.1 MP3 - the software may not always work as well that way.

Also, would you be opposed to just trying an upgrade to 3.2.1 MP5 (build 5033) or 3.3.0 instead? You might get better results out of upgrading to that release as we have just recently resolved a few upgrade related bugs having to do with the database schema, consumer policy settings getting corrupted, etc.

Problem with any other upgrades is we only appear to have the

PGPUniversal3.2.1MP3

PGPDesktop10.2.1

Available on download at the Symantec patch site.  Also the pup that was uploaded to the server was:

PGPUniversal3.2.1MP3_PGPDesktop10.2.1.pup

Which is only 370mb and your support told me on another thread that the reason the version of the server hasn't updated is because that .pup file is actually only the "pup lite" version.  Meaning it's just a client update only.

I'm still trying to find the old post I'd seen, where someone turned some settings off on the server and downloaded the client again after.  Then never got the DEP errors after.

That could very well be part of your problem. So what's happeneed here is you updated Desktop Client installer packages on the server without updating your server. This is also not technically a supported client upgrade path. You cannot have 10.2.1 clients managed by a 3.0 server, it may not work and is not a scenario that QA has tested. Basically, the server is backwards compatible with the clients - but not forward compatible.

I would suggest upgrading to PGP Universal Server 3.2.1 MP3 by downloading the PUP update that is around 750-800MB instead and uploading that and completing the upgrade process again.

Can't try 3.3.0 as looking at the download page that we get when we enter in our serial number at fileconnect, all it shows is 3.2 and it's patches.  So I assume our licence doesn't cover 3.3.0 sadly.

Also I've noticed if the client is installed via the Universial Server update service, it installs fine with no error, its only the downloaded copy I got off the server that has the above error message.  I wonder if they just corrupted when they downloaded.

Our server appears odd as well as I turned off the option to notify users that the patch is available, yet a few people still got the message.

That sounds like a possible issue with your consumer policy. I would recommend cloning the policy and then restoring the clone policy to factory defaults and the moving your default user group over to that policy.

In regards to your other comment about exporting the MSI is the only way this error comes up during installation. The DEP error may be related (in that case) to the trusted keys that are stored on the Universal Server. I would check those keys to make sure they are all valid and that you can access each key individually without a problem. If one of them fails to access correctly. You may need to manually remove that key and then reimport it.

We embedd the trusted keys installed on the server into the MSI installer for certificate chain of trust. So that may be where that is coming from.

are people still having problems here? My test environment i have DEP fully enabled and UAC set to the highest level possible. I don't see this type of issue. I am curious if this is still a problem or not given my suggestions of things to try?

Still happens on the manual install but if it's updated via the server it seems OK.  We've just ignored it and it continues when it's closed.

Also we're moving away from PGP and starting to use Bitlocker now.  Bit annoying as I was just getting used to PGP.