File Share Encryption

I plan to upgrade the PGP Universal server this weekend from version 10.3.0 MP3 to 10.3.1 MP1. I have two question that I would like to find answers to before comfortably proceeding with the upgrade.

Question 1 - Since previously upgrading from version 10.3.0 to 10.3.0MP3, our current version, I’ve noticed that in the administrative logs, about 100 times every 10 minutes I’m receiving a error (validation error loading ovidprefs file /etc/ovid/prefs.xml : dlp is a required field. Trying to load without validation.)

                Now, I know there is a fix for this by actually editing the pref.xml file and adding settings between <SMS and </SMS> from file pref.xml.rpmnew or prefs.xml.save into the prefs.xml file. This is something I have not done yet. It has not caused function issues but I do want to clear it up ASAP.

                So finally my question, a two part question, Should I perform the manual fix for this before upgrading? OR will the latest upgrade fix this issue for us?

 

Question 2 – When I upgrade to this latest 10.3.1MP1 version, will the older 10.3.0 clients still be compatible OR am I requred to upgrade all the Symantec Encryption desktop clients to 10.3.1MP1 before they can functions? I’ve seen statements about backwards compatibility on the previous update documentation but it seems there is nothing on the new version documentation regarding this. Can someone please let me know for sure?

 

Thanks so much!  

 

Hi 3L3M3NT, I hope this is still useful. Regarding the first point I haven't tested. But it is very likely that the update will fix it. Otherwise it shouldn't make a difference to fix it before or after. Additionally, if you fix this after, you'll know it is really fixed and wouldn't be broken after the update. The topic in what concerns the legacy clients was due to the license (in)compatibility with older versions. For clients 10.3.x I haven't heard any specific issues. What you can expect is new features to not be available in the legacy clients even if the new server contains new options in the policy. Rgs, dcats

dacts,

 

Thanks for the information. I upgraded the server over the weekend and everything went good. I am however still having issues with the SMS required field and still seeing this "validation error loading ovidprefs file /etc/ovid/prefs.xml : dlp is a required field. Trying to load without validation." error on the admiin logs on this new 10.3.1MP1 version. Is a fix for this critical? what exactly does this do?

Have you enabled DLP integration?  

I had an issue with the upgrade from those versions too.  I had to contact Symantec, but they rebuilt a folder.  Mine was due to a tomcat error - the server worked fine but a couple of pages (mail policy) went very funky.  Could be similar.  If you're on a VM maybe snapshot it, delete the ovid folder and let it recreate it.

Thanks Alex_CST

 

We do not use the DLP intergration, that's the Data Loss Prevention thing, right?

I just tried the SMS patch and I could not even find the <SMS> </SMS> line in both the xml.rpmnew or prefs.xml.save files in the directory /etc/ovid.

Note: settings between <sms> </sms> should be:

<sms>
<enabled>false</enabled>
<gateway-provider>
<name>Wire2Air</name>
<server-url>http://smsapi.wire2air.com/smsadmin/submitsm.aspx</server-url>
<version>2.0</version>
<user-id></user-id>
<password></password>
<vas-id>1195</vas-id>
<profile-id>2</profile-id>
<from>49474</from>
</gateway-provider>
</sms>

None of these files contained any of this content. I have no idea what to do now... I would like to fix this since it fills up my Administrators log with all these validation error loading ovidprefs file /etc/ovid/prefs.xml : sms is a required field. Trying to load without validation Errors.

 

We don't even use the mail feature on the server at this time... it's only doing disk encryption and file share encryption. This error started with version 10.3.0 MP3.

Any advice? Should I still risk in deleting the ovid folder and let it recreate it?

 

Thanks

Just wanted to update this case and close it. I ended up opening a case for this issue. So this problem turned out to be a two part problem. We had errors for SMS and errors for DLP. Below is the final fix to the problems. Hope this helps to anyone that had the similar problems.

 

SMS fix:

 

Based on Symantec's advice we need to add the <SMS> lines below between the </linux-client-list>  and <group-key> tags on this pref.xml file.

 

<sms>
<enabled>false</enabled>
<gateway-provider>
<name>Wire2Air</name>
<server-url>http://smsapi.wire2air.com/smsadmin/submitsm.aspx</server-url>
<version>2.0</version>
<user-id></user-id>
<password></password>
<vas-id>1195</vas-id>
<profile-id>2</profile-id>
<from>49474</from>
</gateway-provider>
</sms>

Then we need to restart the tomcat service and the httpd service by using the following commands:

pgpsysconf –restart tomcat

 

pgpsysconf –restart httpd

 

Symantec said there would be no downtime so we can restart these services at anytime. This resolved our SMS errors.

 

DLP Fix:

 

Symantec suggested checking the file prefs.xml.rpmnew or prefs.xml.save. One of those files most probably prefs.xml.rpmnew is going to have a dlp section <dlp>...</dlp>

If not here is what we need.

<dlp>
        <enable-gwe-dlp-integration>false</enable-gwe-dlp-integration>
        <dlp-ira-server-ip></dlp-ira-server-ip>
        <dlp-ira-user-id></dlp-ira-user-id>
        <dlp-ira-password></dlp-ira-password>
        <dlp-ira-incident-update-interval>5</dlp-ira-incident-update-interval>
        <dlp-ira-incident-update-batch-size>1000</dlp-ira-incident-update-batch-size>
        <dlp-ira-endpoint-address>https://$DLP_HOSTNAME/ProtectManager/services/remediation</dlp-ira-endpoint-address>
        <dlp-ira-connection-timeout>60</dlp-ira-connection-timeout>
        <dlp-ira-read-timeout>600</dlp-ira-read-timeout>
        <dlp-ira-write-timeout>600</dlp-ira-write-timeout>
        <dlp-ira-max-retry-wait>24</dlp-ira-max-retry-wait>
    </dlp>

We just need to paste the whole dlp section between </proxy> and <cluster> on the pref.xml file

Restart universal server using the following command:
  pgpsysconf --restart –pgpuniversal

 

This had to be done after hours since there was a possibility for slight downtime in accessing encrypted data and or any new enrollments.

 

Hope this information helps someone. Thanks guys for chiming in!