Endpoint Protection

This article is part of a series describing how to leverage Group Policy Software Installation to install SEP. All automatically and without touching SEPM when you deploy a computer.

GPO Installs and SEP, Part 1

https://www-secure.symantec.com/connect/articles/creating-transform-mst-file-control-installation-symantec-endpoint-protection

GPO Installs and SEP, Part 2

https://www-secure.symantec.com/connect/articles/startup-scripts-and-sylinkdrop-better-together

GPO Installs and SEP, Part 3

https://www-secure.symantec.com/connect/articles/mp-upgrade-path-compliance-using-group-policy

___________________________________________________________________

Consider this scenario

If you never skip SEP updates, you can skip this article. But if you don’t have the resources for that, or have to skip some updates due to specific issues with a release but want to deploy their successors, you, like Acme Widgets, a hypothetical company, need to use a specific Group Policy feature.

Some time ago, Acme Widgets used Group Policy to install SEP 11.0 MR2-MP1 system-wide, including servers, desktops and notebooks.Since then, Acme rolled out SEP 11.0 MR3, also by Group Policy, upgraded-in-place over MR2 MP1 on all the desktops and servers. However, the notebooks are used by field employees and seldom come back to the main office for updates. So a few notebooks are on MR3, but most remain on MR2-MP1.

Acme had a specific problem with MR3 for computers in one OU that was fixed in MR4. But an MR4 problem prevented deployment to the rest of the system. So they installed MR4 by Group Policy only to members of that OU, leaving the rest of the system a mix of MR3, and MR2-MP1 on many notebooks.

But now, all of Acme’s issues are fixed in SEP 11.0 MR4-MP2, and Acme wants very much to upgrade. But the Release Notes of every MP include chilling words similar to these, from MR4-MP2:

“This maintenance pack cannot be installed over any versions of Symantec Endpoint Protection or Symantec Endpoint Protection Manager prior to MR4. It must be installed over Maintenance Release 4 (MR4), (MR4-MP1), or (MR4-MP1a).”

Acme has a mix of MR4, MR3 and MR2-MP1. Do they have to upgrade all of them first to MR4, wait for all computers—including the notebooks that are seldom connected to the LAN—to get the upgrade, then repeat with MR4-MP2? That could take years! Or take their chances with an upgrade path, MR2-MP1 to MR4-MP2, and MR3 to MR4-MP2 path that Symantec hasn’t tested and does not support?

The trick

We will use a loophole in the requirements. We’ll uninstall the old SEP leaving a SEP-free machine, then immediately install MR4 MP2. That’s a supported installation because it’s not an upgrade at all…it’s a clean install. And Group Policy will (yet, again!) do all the heavy lifting with a few mouse clicks, silently, and unattended. This article shows you how Acme did it.

Prerequisite

All versions of SEP you intend to update must have been installed by Group Policy Software Installation.

Exceptions

If no computers, or only some computers, had SEP installed by Group Policy, you can still take advantage of any one of these scenarios to extend Group Policy SEP installation to additional computers, as these upgrade paths are supported:
 

• Computers that run the MR that corresponds to the MP we want to install. In this case, MR4, since we are installing MR4-MP2.

• If we are installing a new MR (not an MP) over any prior version of SEP.

• If some other AV is installed and SEP can install, over it.

• If no AV is installed at all.

• If a competing AV over which SEP cannot upgrade was installed by Group Policy, provided that the “Replace” install described below is used.

   

Step-by-Step

The sequence is important to understanding how to use Group Policy correctly for this application, so we’ll retrace Acme’s steps starting with GPO install of SEP 11.0 MR2-MP1.

SEP 11.0 MR2-MP1

MR2-MP1 was straightforward. Prior to this install, Acme ran SAV 10.x, and any release of SEP 11 will upgrade SAV 10.x. They simply followed the first 2 articles of this series to install MR2-MP1, and the resulting GPO (named SEP) looked like this:

Tip
In the Properties sheet, append the version number to the Name of the Package.

You’ll see later that this is important for managing other settings in the GPO. The Name you enter here is also reflected in Programs and Features (AKA Add or Remove Programs) on the client computer, which is handy during testing and rollout. And it self-documents the history of SEP on your system.

SEP 11.0 MR3

Later, Acme upgraded to MR3. MRs can install over any prior version of SEP. In Group Policy, this is called an Upgrade install. On the Upgrades tab of the Package’s Properties sheet, click Add, select Symantec Endpoint Protection 11.0 MR2-MP1, choose Package can upgrade over the existing package, and click OK.

The GPO now looks like this:

When the client computer processes this Policy, it will install SEP 11.0 MR3 over SEP 11.0 MR2-MP1 and then reboot; a supported upgrade.

Group Policy best practices on which this technique depends:

You’ll recall in this case we know we still have MR2-MP1 notebooks offline. Until every last one is upgraded, the MR2-MP1 entry must remain in the GPO in order to enforce the supported upgrade sequence. This has these ramifications:

• Never remove older Packages from a GPO, and never move or remove their installation files, unless you are absolutely certain you have no computers running the older version. When you delete a Package, you can’t recreate it. Behind the scenes, every package is assigned a GUID. The recreated package will not “match” what is installed on the client because the GUID won’t match. It will be considered a new Package, and will be processed accordingly. The net effect on Acme of premature removal of MR2-MP1 from the GPO is that all future upgrades will be Upgrade installs, when they should be Replace installs.

• Even if you have only one server, create a domain-level DFS share to host your Setup files before you start using Group Policy to install software. Servers come and go, but a domain is forever. As servers are replaced, you want the UNC path to the MSI & MST files to remain constant, and a DFS share allows you to do that. Fixing installation paths after the fact can be done with a WMI script, but it’s cumbersome. DFS (and WMI scripts, if it’s too late!) is beyond scope of this article; there’s lots of help available on Microsoft TechNet and Microsoft’s support boards. (I’ll help you if I see your post there!)

SEP 11.0 MR4

You’ll recall that Acme only pushed MR4 to a specific OU that needed it. All other OUs were still on MR3. So they created a new GPO named SEP2, scoped to just that one OU. Here's how they managed the MR4 upgrade in SEP2.

Then, back in the Add Upgrade Package dialog, select MR2-MP1 from the other GPO, and select Package can upgrade over the existing package, because MR4 can upgrade in place over it. Repeat for MR3. Note that the remote GPO ‘s name is shown in parentheses after the Package name.

And the Upgrades page should now look like this:

When the client computer processes this Policy, it will install SEP 11.0 MR4 over SEP 11.0 MR2-MP1 or MR3 and then reboot; both supported upgrades.

Important:

Make sure you’ve specified Replace or Upgrade for every version of SEP you’ve installed by Group Policy. If you miss one, Group Policy adds bogus MSI entries for the one you missed to the client’s Registry, and you’ll see it in Programs and Features in addition to the correct installation. You may have problems with future installs. If this happens, fix the GPO, first. Then, on affected client computers, use the Windows Installer Clean-Up Utility to remove the invalid entries. http://support.microsoft.com/kb/290301

SEP 11.0 MR4-MP2

OK, here’s the moment we’ve all been waiting for! Acme’s entire system will now be united under one version of SEP. We have a pretty complicated scenario, at this point, but Group Policy will sort it all out for us automagically on each client, in some cases using a Replace install, in others, an Upgrade. Here’s where the decision to use Group Policy will pay a big dividend.

1. Open the original GPO, the one that contains MR2-MP1 and MR3, and add MR4-MP2.

2. On the Upgrades tab, click Add, select MR2-MP1, and select Uninstall the existing package, then install the upgrade package, and click OK.

3.  

4. Repeat for MR3.

5. Now click Add a third time, and browse for MR4 in the other GPO but this time, select Package can upgrade over the existing package and OK.

6. Now the Upgrades tab looks like this:

Group Policy Editor now looks like this:

One last step, though. Recall that we have 2 GPOs installing SEP: SEP and SEP2. Right now, SEP2 has higher priority, because it would have had to in order to install MR4 to the specific OU that needed it. That will block MR4-MP2 in that OU.

In Group Policy Management Console, click on the OU in the left pane. In the right pane, make sure SEP is ordered higher (has a lower number) than SEP2.

When Group Policy Software Installation is processed by a client computer, if MR2-MP1 or MR3 are installed, Windows will uninstall SEP, reboot, then install MR4-MP2, then reboot again. If MR4 is installed, MR4-MP2 will upgrade-in-place, then reboot. All are supported upgrade paths.

Over time, as you add more MRs and MR-MPs to your GPOs, specifying Upgrade or Replace every time, Group Policy will always handle version upgrades correctly, no matter what version of SEP it finds on a machine.
 

I’ve mixed x86 and x64 SEP versions in my GPOs…will this work for me?

I omitted that condition from the scenario to simplify it. But yes, it will work, because Upgrade or Replace is specified for each new Package against all prior Packages that have been applied to client computers. You’ll want to append “x86” and “x64” to your Package names to keep them straight while you’re working with the GPO. Since x86 SEP packages will only install on x86 computers, and x64 Packages on x64 computers, you don’t need to specify Upgrade or Replace between processor architectures, just within them.

See https://www-secure.symantec.com/connect/articles/creating-transform-mst-file-control-installation-symantec-endpoint-protection for other tips regarding mixing x86 and x64 Packages in a GPO.