Endpoint Protection

We deployed MR4 MP2 (11.0.4202.75) using GPOs by creating a custom install package(not a single file install).  I then copied the entire contents to a share and created an MST to configure ADDLOCAL for Core,SAVMain.


This worked great.

However I have now modified this GPO to upgrade SEP to MR5 doing the exact same procedure and choosing to update the currently installed software instead of removing and reinstalling.  When I exported the package from SEPM i choose to force a reboot after install.

I am seeing strange behavior.

The GPO does in fact upgrade SEP to MR5 however after the update(before the user is allowed to log in) it does not reboot.  Therefore when the user logs in SEP services are not running.  The PC needs a reboot.

I also noticed that old installer information for MR4 is still in add/remove programs.  Why doesn't it get replaced by the new MR5?

If I choose in the GPO to uninstall and the old version and install the new version it still does not work at all.

Anyone know of a way to get SEP to force a reboot after an upgrade?  I've tried adding REBOOT=force to the property table in the MST.  I've tried exporting the custom package with the reboot force option enabled.  Still nothing.

The idea is for the software to upgrade after the user reboots their computer for the day but this lack of a reboot is an issue.

The MSI product codes don't seem to change between many of the SEP releases.  This causes Windows to think its the same installer that was there before.  This causes various problems. So I recomeend the following for GPO deployments.

Always remove the previous version of SEP.  Do this by right clicking the installer in your group policy, and choose to remove it immediately.  Then add the installer again to the policy.  Now, the group policy changes come before any MSI logic does, so GP removes SEP and then installs it again.  GP always removes stuff before it installs stuff. The necessary reboots seem to occur as far as we have seen in our deployments.

If you have an install on the computer that needs to go away, you might have to script an "msiexec /x {SEP's Product Code} /qn.  The product code can be found inside the MSI via a tool like Orca.

We deploy in this fashion, so feel free to post more questions here or contact me.

If this is the case then why does symantec even bother to have a guide on using GPOs to update and install SEP?  The guide would seem to be completely inaccurate.

So instead of adding a 2nd installer package and choosing the options to update the current installation I should select the original installation package in the GPO and choose to REMOVE it and choose the option to uninstall it immediately.  Then add the new package to the GPO for the MR5 release?  Thats not MS best practices nor is it very good for TESTING.  Basically that means I have one shot at this working and if it doesn't my GPO is forever screwed up.

My only problem is that after the GPO installs the MR5 update over MR4 MP2 it doesn't reboot and leaves the PC in a state where the SEP service are turned off. A simple manual reboot fixes this but it would be much easier if SEP would REBOOT after it updates itself to the new MR5.

The secondary problem I have is that it leaves the old entry in add/remove programs for the previous version.


If I instead choose the option to UNINSTALL the previous version before installing the new version in the GPO it just doesn't work at all.  it quick flashes a screen on bootup saying uninstalling version xxxxxx but it is done too quickyl and nothing is removed or installed.  I am guessing this is because of the product code issue you mentioned.

Yeah, I'm just reporting on what some of our admins have been doing.  I've heard some good arguments for deploying SEP initially to computers via GPO, but then deploying SEP updates via SEPM.  But that seems to require using a staging area in AD for computer accounts and making sure the GPO isn't set to remove SEP when the machine falls out of the policy scope.  Some admins do already use a staging area in AD/GP, so that could work for them.

Yes you're right, if the re-install fails the computer would be left without any A/V and it certainly is not the ideal way to deploy.  There may be more to this issue then either of us have spotted.

Actually the update works just fine.  It just doesn't perform the necessary reboot to start the services afterwards and nothing I do to force it works.

how about if you create  package which says reboot after install, does that work?

I tried that. I created a custom package in SEPM making sure to choose to option to force reboot automatically after install.  I copied that custom package to a share that everyone can access.  I created a .mst file. I followed all of the symantec documents for GPO installations and upgrades.  It just flat out doesn't reboot no matter what I do....  It leaves the services off and I need to manually reboot.

Anyone updating to MR5 via GPOs and experiencing this problem?(no reboot and SEP services not starting until after a manual reboot)  Anyone know of a way to force SEP to reboot after upgrading when deploying with GPOs?

I've tried creating the custom package in SEPM.  That didn't work. I am using a transform to deploy with GPO.  Is there a setting in the transform I can use to force a reboot?

I've not had this problem here. SEP comes up just fine after the install. We're installing AVAS/MAPI/SMTP/PTP on the clients, AVAS only on the servers. If I recall, NTP requires a reboot; but we haven't used NTP since MR2 MP1 or so. But SEPM isn't reporting any new RU5 clients that need a reboot.

I specifed an "Upgrade" install in the GPO since MR5 can overinstall any prior version.

@DavidB1234

If the "Guide" you're referring to is the 3 Connect articles about installing SEP by GPO that I submitted, understand they are not Symantec documents. I'm just a user like you, who figured it all out the hard way! I'll be glad to help if I can, but they're not official documents and there may be circumstances they don't accomodate that are not present in the systems I support, so I don't know about them.

Or maybe Symantec has added to their skimpy GPO documentation now...haven't looked.

Also, if you specify a Replace install rather than an Upgrade install, GP will remove the old version, reboot, and install the new version. You can leave the old Software Package in Group Policy as long as you like (and you need to, until you no longer have any clients on the old version). Are you saying that's what you did? I have not tried it with RU5, but I've never found it necessary to do a Replace install with RU5.

For more information on Replace vs. Upgrade GPO installs, see https://www-secure.symantec.com/connect/articles/mp-upgrade-path-compliance-using-group-policy, although--theoretically--an Upgrade installation should suffice for SEP RU5. And it did, here.

I can't swear to this, but I'm pretty sure that on the few machines on which I've installed SEP RU5 interactively I haven't been prompted for a reboot either, and all SEP services were running when I was done. If none of the files that get replaced are locked during Setup, a restart isn't necessary.

Finally, if you did not select either Upgrade or Replace for the previous version, the old version will remain listed in Add or Remove Programs. At least, that's the only circumstance under which I've seen this problem. AFAIK it's cosmetic, but you can clean it up by fixing the GPO and using MSI Cleanup Utility on the affected client.

One way you could work around whatever is going on to force a reboot is to use Group Policy Preferences to run a Scheduled Task one time on Startup that runs the SHUTDOWN /R command. Include that in your SEP GPO. Or do a one-time Scheduled Task that launches the services, if that's all that's required.

I have a very simple setup with 150 workstations and SEPM on a single server.  There is a single GPO that installed MR4 MP2 awhile back.  I edited the GPO to perform an UPGRADE install of MR5.  Every workstation I have tested has left an old entry in add/remove programs and has not started up the sep services after the upgrade.  The upgrade succeeds but leaves the pc in an unprotected state until it is rebooted and the services start.

I am ONLY installing Core and SAVMain using a transform in the GPO.

I TRIED to change the option to REPLACE in the GPO.  That did not work at all.  It says uninstalling xxxxx during bootup but then quickly just fails.

The only way I can get it to work is to use the option to upgrade in place in the GPO but then it doesn't reboot(leaving the services off) and it leaves the old add/remove program entry.

I figured this would be a piece of cake using your documents with such a simple infranstructre and only a single previous install of SEP MR4 MP2 in my environment... not so apparently...

In fact I can ghost a brand new PC with our standard image.  Create a brand new GPO identical to the last one.  Apply it to the PC.  It installs MR4 MP2 just fine.  I edit the GPO to include an UPGRADE package for MR5.  Run a gpupdate /force on the PC and reboot it.  It upgrades to MR5 but again leaves the services turned off and doesn't reboot.

This is reproduceable and consistant..... 

 

I had 2 machines with some sort of LiveUpdate software corruption that prevented the LU update, which rolled back RU5 install when nearly complete, and reinstalled MR4 MP2 by GPO. Running Setup manually and examining %TEMP%\SEP_INST.LOG was how I discovered what was happening. In my case, manually uninstalling LU worked around the problem and I could then install SEP interactively, or by GPO.

This doesn't sound like your problem at all, but nonetheless we may learn the answer by looking at SEP_INST.LOG. Unfortunately you don't get a SEP_INST.LOG during a GPO install. (There may be a way to get one with an MST setting...don't know.)

So exclude a test PC from the GPO by editing its Delegation. Also make sure that the MR4 MP2 Software Package is set to NOT remove when the GPO is unscoped;. Run GPUPDATE /TARGET:COMPUTER /FORCE on the client computer to remove the GP Software Assignment. Then run RU5 Setup manually over MR4 MP2 and look at SEP_INST.LOG.

I'm no expert on interpreting them, but post it here and I'll look, or someone else will see the problem. See http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/ed3d7fcd6b653eca882575c500776413?OpenDocument

Do you know if there is anything I can do to the .mst file to force a reboot?  Perhaps another row in the property table or something?

I see lots of people trying to prevent one but nobody trying to force one.

I don't use GPOs for installs, but if you can, why not just run a batch file with two lines: the first running msiexec and the second sutdown.exe, both with the appropriate arguments?

@PeterWendell: To install from a batch file you have to use a Startup Script. That's a last resort and good to avoid. If you do this, make sure to set a very long timeout for Startup Scripts or your installs may be terminated prematurely leaving the product partially installed. I've done this on rare occasion for something we HAD to have, and have quickly, but never for anything as big as SEP, and never for anything that offered an MSI install. And if I recall, shutdown commands are ignored in Startup Scripts, because I think I've tried it...you'd have to do something like the one-time Scheduled Task I suggested earlier. Also make sure there's run-once logic in the script because you'd not want to have it attempt to install each time.

@Davidb1234: I've never tried to force a reboot with an MSI install....and never had to. If a reboot is needed, SEP install has always rebooted on its own. If it hasn't, then it doesn't need to, and it comes up normally, and that has included RU5. That makes me a little suspicious of the integrity of the MR4 MP2 install. A SEP_INST.LOG would be a real good idea.

Another test that could tell us something: Take a clean Windows install, install SEP MR4 MP2 interactively but with the same components you use with your GPO install, then join it to the domain and let your GPO overinstall RU5, and see what happens then. If you get different results then the MR4 MP2 install is getting real suspicious.

Every MR4MP2 that I've tried to overinstall, either using the full setup via CD, an exported install package, or the msp patch has failed to start the service upon completion of the install.  This is in different domains, 32 and 64 bit clients, and everything from XP to Win7.  Using SEPM to do the upgrade by assigning upgrade packages works perfectly fine.  "Manual" upgrades from MR4 MP1a also work fine.  The "manual" upgrade process just doesn't agree with a MR4MP2 client.

Weird...absolutely NO problems with service start at all, here, with RU5. Upgrading over almost entirely GPO-installed MR4 MP2 on 100s of x86, x64, multiple domains, GPO install, interactive install, XP SP3 to Win 7 RTM. Honestly, never had a problem doing this since we started installing by GPO with SAV 8.something (if memory serves). Among many, many other GPO installs!

And I still wanna see that SEP_INST.LOG.

Is there anything in the Windows App & System logs that indicate that the services tried to start but couldn't? And why?

Perhaps, as a workaround, add this Startup Script to the GPO:

NET START "Symantec Endpoint Protection"
NET START "Symantec Event Manager"
NET START "Symantec Management Client"
NET START "Symantec Settings Manager"

Or better still, if you've deployed Group Policy Preferences, you can accomplish the same thing graphically and in a more self-documenting way with Computer Configuration\Preferences\Control Panel Settings\Services.

As long as the services will start without restarting the machine, this will get you over the hurdle pretty painlessly.

If the services are already started, it's benign; it won't do anything but waste a few CPU cycles trying. Once everyone's at RU5, you can delete the Startup Script/Preferences, and hope it won't happen with future upgrades.

I don't really want to get in to testing manual installs of SEP as I will never be doing that in real life nor will anyone else.  If you know of a way to create the SEP_install.log deploying with GPO let me know.  Short on time right now.  We are just a small company and I am the entire IT department.  I wish this stuff would just work better.

As far as the event log it appears to install sucessfully.  There is a few messages about files being locked with source ccSvcHst but other than that it just says the update was successful. 

 

I doubt my MR4 MP2 install is suspcious.  It couldnt' have been deployed any more basic that it was deployed and there was no problems deploying it with GPOs.  It is a very basic install with just Core, and SAVMain selected in the .mst.

I loaded up the SEP msi in Orca just for our own packaging needs and as best I can tell the Reboot=Force property isn't going to work since there doesn't appear to be a reboot action in the installexecutesequence that looks at that property.  There are a lot of custom actions in the SEP msi file, so I could be missing something in here, but there are some custom actions with reboot in the title.  

One of the custom actions is "SetRebootAtEnd...." has this for its condition in the installexecutesequence table:

(Installed AND (SND_INSTALLED=1) AND ($SYMTDI_SYS.6500F9C2_37EA_4F25_A4DE_6211026D9C01=2) AND (NOT SNDUNINSTALLREBOOTOVERRIDE=1)) OR (NOT Installed AND (SND_INSTALLED=1) AND ($SYMTDI_SYS.6500F9C2_37EA_4F25_A4DE_6211026D9C01=3))

I may be wrong and you *will* want to test, but creating a transform for the MSI and giving this a blank condition could potentially trigger a reboot regardless of its need.

Hi,
I'm having almost the same issue but I'm upgrading from SAV 10 through GPO.

I've selected to uninstall previous SAV 10 and do an install of SEP 11.0.5002.333 and all goes well but instead of a final reboot where it should be, the option to press CTRL+Alt+Del comes up. When the user logs on to the client the desktop appears and after a few seconds the reboot is done.
So for me, I get the reboot but it is all to late. Even if I wait half an hour it reboots when logging on so it's not some sort of slow installation.

This worked well with the version 11.0.3001.2224 which I did all the tests with, but then suddenly there was an order to go for the latest available version due to performance issues and when started to test that version instead I ended up with this problem.

Any help with this would be appreciated since we are using GPO for deployment at our sites.

Thanks,
Lars-Inge