If you are planning to upgrade to SEP version 14, but in your environment you still have many legacy OS (which do not support SEP 14 install) and where many of them also have a Group Update Provider (GUP) function assigned to them will you need to restructure the GUP environment?
Yes, SEP 14 clients can download definitions updates from SEP 12.1 GUP, as long as the SEPM version is 14.
Symantec always recommends where possible to use the same version SEP client on a GUP machine as on the SEPM (assuming SEPM is running the latest version). But in a situation where SEP version on GUP cannot upgraded to version 14 ( for example if it is a legacy OS where version 14 is not supported), SEP 14 client will be able to download definitions from SEP 12 GUP.
- in SEP 14 there is new option in explicit GUP configuration settings called "Specify Client Subnet Mask" , it will be ignored by 12.1 GUP client.
- Since now the GUP will serve both SEP 12 and 14 client definitions suggesting to increase the GUP cache (https://support.symantec.com/en_US/article.TECH228043.html) to at lest 3 - 4 GB (to avoid repetitive definition downloads by GUP from SEPM) .
- Make sure that on your SEPM 14 you have also enabled legacy content to be downloaded ( 12.x definitions):
1. In the console, click Admin, and then click Servers.
2. Under Servers, right-click Local Site, and then click Edit Site Properties.
3. On the LiveUpdate tab, make choices from the following available options.
4. Under Content to Download for Client Types Check boxes next to SEP 12.1.x , download and store standard-size content (and reduced-size content if you are also running reduced 12.1.x clients for embedded systems)
5. Due to this known bug that was fixed with 14 MP2 its recommended to have at least 14 MP2 GUP where possible:
GUPs at remote branches do not update content across slow WAN links
FIX ID: 4078751
Symptom: Symantec Endpoint Protection clients fail to obtain content from Group Update Providers over slow wide-area network (WAN) links.
Solution: Corrected an issue where the Group Update Provider incorrectly handled the HTTP response code 400 from Symantec Endpoint Protection Manager, which caused the content corruption
6. Please make sure that the GUP has enough disk cache space configured in LU Policy see: Best Practices for Group Update Provider maximum disk cache size