Endpoint Protection

I know you can export client packages for either 32 or 64-bit machines, which is fine when deployed with Group Policy. But how do you use Symantec's AutoUpgrade feature on groups with both 32//64-bit machines, since you as admin have to choose one client?

Is there a way around having to tag every 64-bit machine on the network and placing them in a separate group? Please say it ain't so.

Hi Prachand

My SE indicated that  for any given group you could add both a 32 and a 64 bit install package.   The clients will install the appropriate one.

Can you please review / confirm this for everyone.

Doug

Yes that  is possible. For  one group both 32 and 64 bit package can be created. What you need to do is  push /install the appropriate pacakge on the appropriate computer and both will be listed in the same group

Doug,

You can definitely assign both packages to a single computer group containing both x86 and x64 clients, and the clients can be both XP and Vista (and 2003 and probably Win7 and WS2008). The only caveat is that there is a minimum client version that autoupdates correctly. I believe that MR2MP2 will autoupdate directly to MR4MP2, but you might have to get to MR3 first. I just don't recall now.

(And of course, the updates to the server have to be done more incrementally - Server MR4MP2 cannot update MR3 directly, for instance - you have to update to MR4, then to MR4MP2. It may have to do with the DB schema updates - IDK.)

Check in with ShadowsPapa on this as well.


Loel

Hi Doug, You can assign a 32-bit and 64-bit package to the same group when you do an auto-upgrade and both clients will automatically upgrade. You don't have to create separate groups for 32-bit and 64-bit clients Thanks :-)

I have four managed clients running SEP MR4, and I'm trying to auto-upgrade them to RU5.  I assigned RU5 install packages to all the populated groups, with "upgrade schedule" unchecked, and I've been waiting for the upgrade to propagate to our clients.

But nothing is happening; our clients are still at 11.0.4202.75 after several hours of waiting.  Is there something I need to do to enable the auto-upgrade, or do I just need to wait longer?

 TO check if the package is assigned.
In SEPM -Go to Clients- highlight the group (in which you have the clients ) - click On Install Package ( on the top right hand side)
and see if the right package is listed over there.

I followed those steps, and the right packages are listed.  But they aren't getting deployed; all my clients are still at MR4.  Is there something else I need to do?

Title: 'Migrating to Symantec Endpoint Protection 11.0 RU5'
Document ID: 2009090313483348
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2009090313483348?Open&seg=ent

To migrate client software to MR5

1. Log-on to the newly migrated Symantec Endpoint Protection Manager Console if you are not logged on.
2. Click Admin > Install Packages.
3. In the lower-left pane, under Tasks, click Upgrade Groups with Package.
4. In the Welcome to the Upgrade Groups Wizard panel, click Next.
5. In the Select Client Install Package panel, all existing client packages are listed in the drop down box. Select one of the following:
   • Symantec Endpoint Protection <appropriate version>.
   • Symantec Network Access Control <appropriate version>.
6. Click Next.
7. In the Specify Groups panel, check one or more groups that contain the client computers to be migrated, then click Next.
8. In the Package Upgrade Settings panel, check Download client from the management server.
9. Click Upgrade Settings.
10. In the Add Client Install Package dialog box, on the General tab, specify whether or not to keep existing client features or specify new ones, then configure a schedule for when to migrate the client computers. Under the Notification tab, specify a message to display to users during the migration.
    • If the clients in the group run a version of Symantec Endpoint Protection previous to MR2, turn off scheduling. Scheduling is on by default when a new client install package is added to a group. If scheduling is turned on, the upgrade fails. To turn off scheduling, in the Add Client Install Package dialog box, uncheck Upgrade Schedule.
11. For details about settings on these tabs, click Help.
12. Click OK.
13. In the Upgrade Groups Wizard dialog box, click Next.
14. In the Upgrade Groups Wizard Complete panel, click Finish.

I followed the steps listed in the "Migrating to..." document.  So far, one of our groups has upgraded, but nothing has happened with the other, after over 24 hours.

The only difference between the groups that I can see, is that the group that has not upgraded includes a 64-bit client, as well as a 32-bit client, so I added 32 and 64-bit packages to this group.

(Also, I turned off scheduling for both packages.  Since I'm upgrading from MR4, it's not clear to me whether I'm supposed to have this turned off or on.  In any case, it was also turned off for the clients that have upgraded successfully so far.)

On any of the clients in this group where the auto upgrade has failed could you please check are there any errors in the event viewer for msi.

Also go to run and type %temp% and look for a file called SEP_Inst.log
In the file search for Return Value 3 and  paste 5-6 lines before and after it

Make sure that the user protection, whatever it's called, is turned off on Vista, 7 and any 2008 machines. That will kill auto-upgrades.
Otherwise, simply assign both 32 and 64 bit packages as has been said.
But if the user account protection junk is turned on (that annoying "are you REALLY sure" prompt) it will kill upgrades done via packages.

Its called User Acess Control ( UAC).
You are right in some cases when UAC is on auto upgrade fails

I found an SEP_Inst.log file, on one of the computers, but the only entries in the log were from the original install of MR4, back in June, 2009.   And the event log does not show any recent MSIInstaller errors.

When I look at the Client-Server activity system log on SEPM console, I do see Client has downloaded auto-upgrade events for both clients this morning, but on the client I am looking at right now (I won't have access to the other one until tomorrow morning), there are no corresponding events in any of the logs I checked.

I should mention that neither of these machines is completely typical.  One of them (the one I just looked at) is running the SEP manager, as well as the client I'm trying to update.  The SEP Manager did upgrade successfully, without any problems.  The other client is on a 64-bit machine, running Windows 7.  Are either of these characteristics significant, as far as auto-upgrade from MR4 to RU5 is concerned?

It wouldnt surprise me if the issue was MR4 on Win7.

Many of the features of the MR4 build did not work on 7 (PTP specifically, for example) so it wouldn't surprise me if  autoupgrade doesn't either.

This wouldn't have surprised me either.  We tried installing MR4 on Windows 7, and then auto-upgrading to RU5, just to see what would happened.  We're still in test mode, so we can afford a few dead ends.

But, strangely enough, the Windows 7 client finally did auto-upgrade this morning.  I don't know why the upgrade finally succeeded, after failing so many times.  When I get a chance to look at the logs, I might have a better idea.

So now the only client that still has not upgraded is the XP workstation that is hosting our SEP Manager.  I don't know why; could SEPM be blocking the client upgrade somehow?

I finally got access to the event logs on the Windows 7 box, and found a series of MsiInstall errors in the log, with the text:

Product: Symantec Endpoint Protection -- Symantec Endpoint Protection has detected that there are pending system changes that require a reboot. Please reboot the system and rerun the installation.

Evidently, the user had turned on auto-patch, and also configured the system to ask permission before rebooting.  So it sat for a while with updates pending.  Finally, it was restarted yesterday morning, and the auto-upgrade was able to run, and now the client is RU5.

I still have one client that hasn't upgraded.  No failures in the log for this one; the client-side logs don't show any attempts to install the upgrade.

 

Open regedit

Navigate to

- and Rename it to PendingFileRenameOperation2

- Do not reboot, and try to install again.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\ PendingFileRenameOperation  

Before I could read the preceding post, I went to the group containing the client that would not auto-upgrade, and I removed the 32-bit install package.  Then I added back to the group, using the Upgrade Groups Wizard. 

A few minutes later, I checked back, and the client was running RU5.

So this problem, at least, is resolved for now.  Thanks for your help.