Endpoint Encryption

Hi Experts,

            I was wondering if someone could tell me if I’m doing something wrong or if this is a bug with the PGP client. When I create a new virtual disk, I assign it a name, the disk location I mount it as is a folder on the C: partition. I create this virtual folder as a 12MB dynamic NTFS AES (256 bits) encrypted volume for testing. I add my user key and the virtual folder is created with no problems. When I try to access the mounted virtual folder, I receive the message that the volume is not recognized. When I look at the .PGP volume on the PGP client, it is mounted but the format is not recognized, meaning the NTFS format was never created. I tried this over and over with the same results. What could be my problem? Anyone else have an issue when creating a virtual folder using the PGP client? Would it be the Key type I'm usisng? , any dependance on that?

Please help

FYI.. I'm running the lates PGP univeral server and the latest PGP client 10.3.0 MP3 (Build 9307)

I'm not familiar with this problem, but am wondering if the folder your virtual disk is being mounted to is completely empty, as required.

It is, I know if it has info in it it will just mount as a drive and not a folder. Can it be key specific? GKM VS SKM?

What about admin rights, this user doesn't have admin right and I do. It works on my computer but not theirs. Just found this out. When I un-mount my working virtual folder I'm then left with just the folder, if I place I file in that folder and then go to remount my virtual folder, it then mounts as then next available drive. To prevent this I had to restrict write access and delete access in this folder. What's bugging me is to why I can't create this same virtual folder on another users machine. Can you let me know if it is an admin rights issue? If so, can it work with power users?

End users should be able to create virtual disks assuming your policy allows.  What are the differences between your 2 machines?  OS? SP Level? File System? 

Alex,

As far as the policy, the user is in the same test policy that I’m in. The option is there to create the virtual disk, so I know the policy is working. The OS and SP levels are the same as mine. The machines have the same MS updates applied and the file system is the same, NTFS.  The only difference is that I’m using PGP full disk encryption on my system, the other system that is having the issues is using the Symantec Endpoint Encryption software, previously knows as GuardianEdge. Not sure if this SEE full disk encryption would cause this problem. I would not think it should.  

After further testing, It’s determined that if you create any PGP virtual drive/folder, you need Administrative rights in order to access the folder for the first time. After the user first accesses that folder you can then remove the Administrative rights for that user and the process works with no problems there after. Why would I need admin rights in order to access the virtual folder for the first time? I would think I would need admin rights to create the virtual folder if that. giving users Admin rights is a security risk, that's how viruses spread through a network Symantec.. you out of all people should know this. Why is your product forcing me to give users Admin rights? 

Is it me or are most of the PGP functions full of bugs? It's unbelievable to me that a security product like this can't do various security functions without have some kinds of glitches and or restrictions. But yet when it was time to buy this product, I was told it would do all the functions I needed to do. Anyone have a number for someone high up in the Symantec engineering department that I can call and give them my long list of problems that need to be addressed? I am so frustrated with this product at this point and I'm behind on securing all our sensetive company data at this point. Not sure what I can do myself at this point.

Thanks Symantec!  

Did you purchase it through a reseller?  They have better ways to escalate.

Unfortunately not Alex, through our Symantec rep. Not sure who it is now since they’ve switched so many times. Trying to get that info from our procurement department now. I’m going to resolve this case since it looks like no one else is having this problem or it doesn’t bother anyone that this security risk bug exists. No reason to waste more time with this post. I’m happy that PGP is working well for everyone else’s applications. Thanks all whom responded and listened to my last rant, it sure did feel good :)