Cannot get autoupdate to MR2 working

15

Apr

2008

0 Votes 0

spyd3r0x

In the readme.txt file on CD1 of the MR2 release, they mention that using Update Schedule does not work with distributing this update. I've disabled the scheduling for the install package, and am hoping that will solve the problem. Hasn't worked yet, though.

15

Apr

2008

0 Votes 0

sedlerj1

Not sure if this is any help, but just saw it while going through the README.TXT file ....

Auto-upgrade is the term used to describe the process of adding a new client installation package to a group. When you add a new installation package to a group, the Symantec Endpoint Protection Manager automatically upgrades the clients in the group to the new version of the client software. You can add new client packages to groups from both the Clients and Admin pages in the console.

Note: You must restart client computers at least once since the last installation before you use auto-upgrade. For example, if you upgraded the client computers to Maintenance Release 1, you must reboot the computers before you auto-upgrade the computers to Maintenance Release 2.

The auto-upgrade process uses mdef25builder.exe on the computer that runs the Symantec Endpoint Protection Manager. This process creates the smallest possible upgrade package. You can see mdef25builder.exe running in the Task Manager during the auto-upgrade process.

It takes mdef25builder five or more minutes to appear in the Task Manager once you add a new package to a group. The auto-upgrade processing time on the Symantec Endpoint Protection Manager takes a minimum of 30 minutes when you add a new package for the first time. Subsequent package additions to other groups do not take this long if the clients in the group run the same legacy software. When mdef25builder.exe disappears from the Task Manager, the package downloads to clients in a minute or more if you do not specify a schedule. If you specify a schedule, the package downloads to clients according to the schedule.

To verify that a package is downloading to clients, look for the \Program Files\Symantec\Symantec Endpoint Protection\Download folder to appear and be populated with either a .dax or .zip file. When the file disappears, the upgrade process is starting on the clients. The process can take 10 or more minutes.

15

Apr

2008

0 Votes 0

ch1221 2

I saw the information in the readme.txt about mdef25builder.exe. I've been steadily watching the processes on the server and have yet to see it launch.

The download folder on the clients have remained empty as well.

This is one of the features of SEP11 that we have been excited about. Trying to get client updates distributed with past versions of SAV has always been a nightmare in our environment. I hope they get this issue resolved quickly.

15

Apr

2008

0 Votes 0

diverdaveman

I've not been able to get any of my clients to update. I've worked on this full time to two days now and I'm PISSED!!!! Come on Symantec, it can't be this hard to create a half-decent application.

Is anyone out there getting thiers to work? If so, how did you do it.

15

Apr

2008

0 Votes 0

JB Fins

My clients seem to be hit or miss as far as auto-update. I had one whole department update to the latest version but only a few machines in IT. I am going to wait it out one more day to see if they run on their own but I agree, that the process worked more smoothly in upgrading to MR1.

The one whole department that did update, I had changed their schedule to 00:00-09:00 and they were all updated this morning.

15

Apr

2008

0 Votes 0

RayM

Is there a report to run or a global screen to see what version the client is on? I have found how to look at each invididual client to check but that can be time consuming.

Thanks,

Ray

15

Apr

2008

0 Votes 0

diverdaveman

Thank you for asking this question. I've been pulling my hair out going through the reports looking for the very same thing. It would be nice to show the version in the grid view, but a report will do.

15

Apr

2008

0 Votes 0

sedlerj1

I also saw the below passages ... basically seems like auto-upgrade doesn't work at ll, or just barely :smileymad:...

------------------------------------

You can import an installation package into Symantec Endpoint Protection Manager and assign the package to a group. After you assign the package, the auto-upgrade process might take up to four hours to begin updating clients in the group.

To force the auto-upgrade process to start immediately, run LiveUpdate on the Symantec Endpoint Protection Manager. Although LiveUpdate might not download new content, LiveUpdate forces the auto-upgrade package to generate and begin updating the clients.

When you upgrade clients to Maintenance Release 2 by adding a new client install package to a group, and the clients in the group run previous versions of Symantec Endpoint Protection, you should turn off scheduling. Scheduling is on by default when you add a new client install package 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.

15

Apr

2008

0 Votes 0

ch1221 2

Yes, I saw the note on trying to speed things up by kicking off Liveupdate on the SEPM. That didn't help in my environment. Also, removing the schedule hasn't helped either.

15

Apr

2008

0 Votes 0

SKlassen

To see what version each client is running:

1) In the SEPM console, go to Monitors>Logs Tab.

2) Choose Computer Status as the Log type. Accept the defaults, or click Advanced Settings and define more granular options.

3) Click on View Log. Click on Export. The client version will be one of the columns in this report.

alternately you can:

1) In the SEPM console, go to Monitors>Logs Tab.

2) Choose Computer Status as the Log type. Click Advanced Settings. Under product version, choose the version you are updating to. Click on View Log.

As clients check in with the new version number, this report will be populated in near real time as long as your keep it open and set the page to auto-refresh.

15

Apr

2008

0 Votes 0

Russ H

I ran into a similar problem where some of my clients were not upgrading. (I also noticed the lack of the mdef25builder.exe process) After a long troubleshooting session with Symantec, they had me run this URL on the SEPM server.

http://localhost:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=PublishLuInventory

After running this URL, mdef25builder.exe almost immediately kicked off and some of the clients that were not upgrading upgraded.

A number of other clients of ours were not upgraded, but we tracked these down because of users not clicking "OK" on the upgrade prompt. (IMHO, that client side dialog should have a timeout.)

15

Apr

2008

0 Votes 0

SKlassen

Auto-update worked for me. I think the trick was to NOT use the scheduler. Untick the Update Schedule box, then go run a manual live update on SEPM. From what I saw, the offset still applies though and it can take some time for systems to pick up on the next package. 50 systems, from first to last took around four hours.

Russ: Go to the Install Package Tab for your group. Edit the package. Choose the Notification Tab. Uncheck the box(es). Don't even give the end user a chance to mess up the install. Just let the whole thing run silently in the background.

Message Edited by Scott Klassen on 04-15-2008 10:18 AM

15

Apr

2008

0 Votes 0

RayM

That works. Thanks.

Ray

15

Apr

2008

0 Votes 0

SKlassen

I should mention that I don't think that the scheduler is broken or buggy, but it does seem to have a lot of hidden throttles and offsets that make it appear as though it's not working (at least in a timely fashion). It's one of the areas in SEPM that needs to be much better documented.

My litmus test for documentation is to bring in someones mother. If she can't follow along, understand, and have a feature act like she believes it will, then the documentation needs revision. No fair if the mother is Laura Chappell or Susan Bradley. :)

Message Edited by Scott Klassen on 04-15-2008 11:21 AM

15

Apr

2008

0 Votes 0

diverdaveman

Sorry guys!!! Guess I'm just not holding my head right. I can't get this auto-update working for crap. I've tried all the suggestions all day long - and still nothing.

15

Apr

2008

0 Votes 0

SKlassen

Diver: Are you using Push or Pull communication and what is your heartbeat interval set at?

The reason I ask is, with Pull mode, I know a few folks who like to set high heartbeat intervals. It means that it's going to take up to that amount of time for clients to check in next.

Message Edited by Scott Klassen on 04-15-2008 11:34 AM

15

Apr

2008

0 Votes 0

diverdaveman

We use 'pull' and the interval is set for 3 hours. I tried earlier in the day setting it to 1 hour and walked away from it - but still nothing.

You're right about the documentation!!!

Thanks,

Dave

15

Apr

2008

0 Votes 0

SKlassen

Here's the thing with that, it can take up to three hours for all the clients to get the new interval policy. I don't know if SEP can process all changes concurrently or if A gets changed, then B has to wait for the next heartbeat interval (think MS updates with pre-requisites).

Another area where long heartbeat intervals can bite you are with sending commands to clients through SEPM. In Pull mode, clients will get the command and process at the next heartbeat interval. So if you send a client a command to restart, it can take up to your heartbeat interval for the command to even be received. Personally I use 15 minutes. Keeps the network traffic down, while still allowing me to view log information and get things done in a timely fashion.

Did you uncheck the Update Schedule box in the install package, then run another manual LiveUpdate in SEPM. You may even have to undo anything you'd previously set for the scheduler before unchecking. Probably easier to remove the current package from the group and then re-add.

Then go relax a little. Let it stew overnight and see if things finally kick-in.

Message Edited by Scott Klassen on 04-15-2008 11:47 AM

15

Apr

2008

0 Votes 0

ynguldyn

It would be easier if we knew the path on the server where client update packages are stored. This way, it would help to look and see if they are created at all.

I suspect they should be in tomcat\packages, but I could be wrong.

15

Apr

2008

0 Votes 0

SKlassen

The packages themselves are still the ones stored in Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\ClientPackages I believe.

As far as where clients learn that they have got new stuff, it would be somewhere in Program Files\Symantec\Symantec Endpoint Protection Manager\data\outbox

15

Apr

2008

0 Votes 0

diverdaveman

Thanks Scott for your help -

Okay, here is what I've done:

Deleted the old install file
Set the heartbeat interval to 15 minutes within the group that needs the update
Updated the policy on a test box within the above mentioned group
Created a new install package - uncheck "maintain existing client features" (change some things from original install) - unchecking "upgrade schedule" and no notification
Saving package and going home - not really, but I wish it was the end of the day.
Running liveupdate on SEPM server

Thanks again,

Dave

Message Edited by diverdaveman on 04-15-2008 12:13 PM

15

Apr

2008

0 Votes 0

camgal

I seem to be having the same issue. At this point I am just trying to get 1 client updated to MR2 with no luck. Mdefbuilder.exe is running on the management server, but it never seems to actually deploy to the client. I have tried all the suggestions in this post with no luck. I have the client pulling with a hearbeat of 5 mins, and have run liveupdate on the management server.

Any other ideas?

15

Apr

2008

0 Votes 0

RBW

You can get a summary report that lists product version number by selecting:

Reports

Report Type: Computer Status

Select a Report: Symantec Endpoint Protection Product Versions

Then you can select Create Report to get machine counts by product version, or use Advanced Settings to get a subset of machines. This helped me isolate an update problem because in my case one group was not updating but all other groups were.

15

Apr

2008

0 Votes 0

RBW

All of our clients have been updated. Several of the methods used to get them updated were mentioned above. Here are the ones that we found to be most important:

1) Restart the client machine before attempting the update. We shutdown our workstations every evening and have an auto start in the early morning. We set the auto update schedule for 5:00 AM to 6:00 AM so that the update would occur just after a restart and before user logon, during a time period when no other tasks are scheduled.

2) Pull with a one hour heartbeat. When we pushed, updates were attempted once per minute and previous attempts were not deleted from the hard drive. After a while the machines would not run because of insufficient disk space. Changing them to pull and putting heartbeat at one hour allowed the installation to finish before the next scheduled attempt. It also put less of a load on the server as not all workstations tried to update at the same time. A five minute heartbeat does not give enough time for the installation package to complete before its next attempt. A three hour heartbeat means that changes and definition updates take too long to distribute. One hour seemed right, although we may try 15 minutes now that MR2 has been installed.

3) When a group does not update, delete the client install package for that group and create a new one. It can be done quickly and it forces the use of default parameters or conscious changes to those parameters.

4) Leave both items in Update Notification unchecked. With updates occurring before working hours, there was no need to provide for user involvement.

5) Be patient. I set up an early morning update schedule the night before, with plans to check the results after they were scheduled to run. Then I slept. It prevented me from interfering during the update process. Besides, we had acceptable level of service with MR1 so it was not a big deal if the update did not occur during our first (or second, or third) attempt.

6) Restart after installation. We restarted servers overnight after the clients were updated. Workstations and laptops are automatically recycled because we routinely power them off every evening. I do not know if it made any difference, but we recycled the SEPM server after updating the SEPM portion and before setting up the client install packages. Prior to restart we had trouble with definition updates. That problem disappeared after recycling the machine.

16

Apr

2008

0 Votes 0

camgal

RBW,

Thanks for the response, I am going to try your suggestions today.

When you created your install packages did you uncheck "Maintain exsiting client features when updating" under the General tab of the Upgrade Settings windows?

Thanks again.

16

Apr

2008

0 Votes 0

RBW

Our servers are running AV only. Our workstations are also running Proactive Threat Protection and Network Threat Protection. The default install package contains all three. So that the install process did not install Proactive Threat Protection or Network Threat Protection on our servers, we left enabled the option "Maintain existing client features when updating".

We created four groups, Servers (64 bit), Servers (32 bit), Desktops, and Laptops. Then we assigned a default install package to each of these groups. The update of SEPM created two default client install packages, one for 64 bit machines and the other for 32 bit machines. When we assigned an install package to a group, we picked the appropriate default package, left enabled "Maintain existing client features when updating", selected the default "Download the client package from the management server", selected the default "Upgrade Schedule", adjusted the from and to times to appropriate times of day when servers or workstations would be available and not scheduled for other tasks (e.g. backups, virus scans, etc), and selected the default Distribute upgrades over 0 days 0 hours. We also left notifications at the default values of not selected. Client communications were set to pull once per hour, so update requests were automatically staggered.

We did not use the Admin: Install Packages feature to create our own packages. This would have added an extra level of complexity and we were trying to stay as close to default options and values as possible.

16

Apr

2008

0 Votes 0

SKlassen

<<< Waiting to see how Diverdaves' rollout went last night.

16

Apr

2008

0 Votes 0

diverdaveman

Hey guys - it's a much better day, today! Some of our clients are starting to auto-update. I guess sleep does help out. I'll be testing and checking throughout the day for the rest of the clients.

Many thanks to Scott and others for your help on this situation.

Dave

16

Apr

2008

0 Votes 0

MCLEE

Symantec Employee

Were you able to upgrade SEPM to the MR2 version before doing the AutoUpgrade?

16

Apr

2008

0 Votes 0

camgal

Yes, the SEPM was upgraded to MR2 prior to attempting anything with AutoUpdates.

16

Apr

2008

0 Votes 0

sedlerj1

It's been mentioned a few times about deleting the install package if auto-upgrade didn't work. My upgrade has yet to kick off, and I have all of the scheduling options disabled, plus it's been 4+ hours.

But when it comes to deleting the install package, SEPM will not let me. No message or error, it just does not remove. There is another thread going on about this, so just wondering how you guys were able to delete the package?

Thanks.

16

Apr

2008

0 Votes 0

camgal

Where are you trying to delete the install package from? I have had no problem removing it from the group that I tried to deploy it to, however I get the following error when I try to remove it from from the Client Install Packages screen under the Admin tab:

"Symantec Endpoint Protection version 11.0.2000.1567 for WIN32BIT" is the latest patch. You cannot delete it.

16

Apr

2008

0 Votes 0

sedlerj1

I am getting the same thing as you in the Admin > Client Install Packages Area.

I Was having the same problem under the group I assigned it to, but am now able to delete it. I think my client was in the process of getting the update, so possibly why I couldn't remove it.

mfdef ... kicked off hours ago and never updated the client. It seems that manually running LiveUpdate on SEPM finally forced it to go.

Thanks for your response.

16

Apr

2008

0 Votes 0

camgal

When you refer to running Live Update manually on the SEPM, which has been mentioned a few times in this post, where are you running this from? I have been kicking it off from the client that resides on the SEPM Server, is there another way I should be doing this, because it is not forcing my clients to update like it seems to be for everyone else.

Thanks

16

Apr

2008

0 Votes 0

sedlerj1

I went to Admin > Servers > Highlight your local site name. At the bottom, click Download LU Content.

16

Apr

2008

0 Votes 0

camgal

Thanks! Found it there.

17

Apr

2008

0 Votes 0

ch1221 2

With all of the suggestions, I have yet to get my clients to deploy. I still have my case open with Symantec but haven't received any different suggestions other than use the Migration and Deployment wizard to get MR2 out - which is not an option in my environment. We are global and it's impossible to catch systems online unless I stay up 24 hours a day.

The auto-update feature is one of the things that sold us on the upgrade to SEP11. Past client upgrades have always been a problem. Symantec, this needs to get fixed!

17

Apr

2008

0 Votes 0

camgal

I would have to agree. I have also tried everything in this post and still cannot get the deployment to MR2 to work. I have yet to place a call with Symantec, but I guess that is my last option as I also do not want to go through the Migration and Deployment wizard.

18

Apr

2008

0 Votes 0

tilallr1

Ok. So had the same problem after upgrading the Manager to MR2. Created Install Packages, deployed them to their respective groups, ran LiveUpdate on the server and nada. Waited a day and still nada. So I decided to upgrade my servers at least using the deployment tool. But first I exported the Install packages to the local drive and then selected those exports when using the deployment tool. Now almost the second I did this, either exported the install packages or used the deployment tools, all my clients began to auto-update. It was like magic. I so love this feature. Thought I would let everyone know what I did to fix it. Maybe you can all give the export and deployment tool a try on a few machines and see if that jumpstarts the auto-update feature for you. Let me know.

18

Apr

2008

0 Votes 0

Crashball

I was having the same issue. I have an SMS environment that we primarly use so it wasn't a huge issue, i just wated to test the process and see if it worked better than using SMS. I had done everything in the post and nothing. I had removed all the group packages, but all of sudden i notced i left one test group with it on and it finally upgraded last night after after almost 36 hours. At least it finally did it, but i don't know many environments that could wait that long to see if anything is happening. You can't just sit and wait. There needs to be some type of status or log to check if it isn't clear with in 15 minutes if anything is happening. I will definately be using SMS to deploy instead.

24

Apr

2008

0 Votes 0

Matt Pierce

Thank you folks so much. I was able to get auto updates rolling after following the advice in this thread. I think what did the trick was removing all install packages and rebooting the SEPM then adding packages back. I ran the web site console command, but never saw mdef25builder running. After adding the install packages back I moved all the clients into a new group that had the install package asssociated. After that installs started trickling in as user acknowledged the prompt. Many of the hung clients have full.zip int he downloads directory, most dated from months ago. Should I delete these files or just let the file be recreated on the poicy udpate?

02

Jul

2008

0 Votes 0

Bekir

We had the same problem unfortunately. After MR2 upgrade on the server, Install Packages functionality didn't distribute anything. Here is what we have done. We've turned off the Simple File Sharing from the Active Directory domain policy and packages were running everywhere like roadrunners. Swift and satisfactory. I hope this helps, and I'd be glad to know if it does.

Best regards,
Bekir Burak Durmaz

05

Sep

2008

0 Votes 0

Guardian 2

I am having the same issue and have tried turning off my Simple file sharing, setting the scheduled times, and also a longer duration with out the schedule with no success. The main difference is when I called symantec we were running SEPM with NO maintenance releases so it was the original starting SEP. They assisted me in upgrading the server and told me to do the 2 day let it go and see what happens. Unfortunately I have let them go for the 2 days and my clients are still sitting at version 11.0.780.1109 and are not getting updates from the server. Any ideas?

EDIT: I am trying to upgrade to version 11.0.2020.56. Not sure if it makes a differance.

Message Edited by Guardian on 09-05-2008 08:28 AM

10

Sep

2008

0 Votes 0

RayM

I'm also having trouble with this. Just installed 11.0.2020.56 and it doesn't even show up under "Product Version". I can see the last 2 versions but not this one. I can't even force an install to a PC, the installation window blinks then goes away. I can install an older client this way but not the newest one. Any ideas?

Thanks,

Ray

Comments

Links

Cannot get autoupdate to MR2 working

Comments

Would you like to reply?

Links

Technical Support

Symantec.com

Store

Community Stats