Endpoint Protection

[Updated Jan 4 2010 by Paul Murgatroyd]

For the latest status on this issue, please see here: https://www-secure.symantec.com/connect/forums/official-status-sepm-definitions-stay-31-12-2009-last-updated-04-jan-2010

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

i've found that last virus definition on my SEPM is 31/12/2009, no change happen when try to update it again but it says updates successfully. any idea what to do???

Tnx

{Original Post has been edited since Paul M provided updated information below.}

JimW

Symantec is aware of this and is currently working on this.

I found the release is updated for 31/12/2009

I have noticed the same issue here, all my clients only have 12/31/2009 rev 041 definition, no defintion updated sicne then. however, I checked the Symantec site, Symantec did release new defintion. The  issue must be on the Symantec site as I even directly connect to Symantec to liveupdate, the log still said all defintion were not to date.
Symantec, please publish this issue on your with progress.

THanks

I was starting to pull my hair out and then noticed that on download that they only had 12/31 avail on the site.

Looking forward to the update BEFORE everything has to become a massive download for the clients :(

checked my machine after writing it, he is correct, we need to wait for the good news.

Same problem here.
Has Symantec provided any press release, support document, blog entry, or anything  that officially states there is a problem?   I need something to provide to my manager to explain why our anti-virus definitions are three days behind  !!!

Neither the SEPM nor manually clicking the LiveUpdate button in the client is able to obtain current definitions.  Ouch!

I update now at 8.00pm ist 3/1/10 and def shows 31/12/09 rev 114 . still can't see 2010 def date.

Once there is an update on this I will update it here.

Dears,
I Have the same problem  i've found that last virus definition on my Symantec End Point Manager is 31/12/2009 .
is there any hotfix to Lveupdate.
this is a critical issue and Symantec Technical  have to solve it.


Omar Delair Mohammed
IT Security Manager
Zain.

 

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348

{Text Edited by JimW to include up to date.  Also refer to information posted by Paul M.}

If you read the above link from ohio_navigator, I take this to mean that the AV defs are still being updated even though it will appear on the client as from 12/31/2009 rev. "XXX" (greater than 041)

Appears to be an issue with the date change.

Yes, thats correct.

An issue has been identified in the Symantec Endpoint Protection Manager (SEPM) server whereby all types of SEP definition content [AV/AS, IPS] with a date greater than December 31, 2009 11:59pm are considered to be “out of date”.

Customers running SEP are still protected, and we are continuing to release updated definitions as normal.  However, for the time being, SEP definitions will display a date of December 31, 2009, with increasing revision numbers.  Current certified definitions are December 31, 2009 rev 114 and contain updates through January 2, 2010.

Symantec is working on a solution and will update customers when a solution becomes available.

IMPORTANT: This issue does not impact any other enterprise products (e.g. SAV or SCS) or consumer products.

For further information please see Symantec KB:
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348

Impacted Products:
*     Symantec Endpoint Protection v11.x Product Line
*     Symantec Endpoint Protection v12.x Product Line
 

To day I can see the def date as 2010-01-02 rev. 020 . I think the problem is solved now.

Nope still problem is there

as my SEPM shows latest symantec version is  2010-01-02 rev. 020  and Latest Manager Version: 2009-12-31 rev. 114  after updaing today on 4th jan 2010.

Bijay you are right , the issue is still there we will update  once there is an update on this


Title: 'The date of the definitions in Symantec Endpoint Protection clients and Symantec Endpoint Protection Manager remain at Dec 31 2009'
Document ID: 2010010308571348
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2010010308571348?Open&seg=ent

Me too facing the same issue, if any update on this kinldy update this post !!


thanks..
tanveeer.

Just a quick warning to any of you folks, who, like us, have any network access rules that are based on virus definitions dates.

If Symantec do not get this fixed before your time limit, then your users will shortly fall foul of this.

EG - we block access to all network resources (other than virus update) if virus definitions are older than 7 days....
IE - in 2 days, we will be screwed - we are working on removing the rule now...

@NickF, yes thats correct.  For NAC specific suggestions, please see our official status post here: https://www-secure.symantec.com/connect/forums/official-status-sepm-definitions-stay-31-12-2009-last-updated-04-jan-2010

To everyone else, the latest information on the status of this issue is available in the above post and will updated with the latest information as we get it.

yeah there is a same issue at all regions , but atleast symantec would have intimated this on their WEBSITE , because people who are not at all aware of this , may think their SEPM would have gone bad and may have changed their settings.

Regards
Raghavendra

Thanks Paul,

To be clear though - we don't use NAC (or at least not Symantec NAC).
This will affect all network access software that checks virus def dates, the least of which is Windows Security advisor, which will likely start popping up warnings if this goes on too long.

Do you have an ETA on a fix?

Nick
 

hi,
this is publicly available

Title: 'The date of the definitions in Symantec Endpoint Protection clients and Symantec Endpoint Protection Manager remain at Dec 31 2009'
Document ID: 2010010308571348
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2010010308571348?Open&seg=ent

@NickF, thats a good point, unless the third party has options like ours then you would be best to temporarily disable the check.

Our engineers are working on the fix around the clock, we have identified the problem and have created a first cut fix which is with QA at the moment.

We plan to deliver the update to the SEPM via LiveUpdate, so there shouldnt be anything for our customers to do when we do release it.

 Hope this issue will resolve very soon, because users are thinking , symantec not able to release antivirus definitions in new year like that......

It's impacting EVERYTHING here, as well. Phone ringing off the hook.
Rapid release wont' work, LU won't work, stuck at 12.31.2009 (USA date format) December 31, 2009

Interesting that the rapid release script I run won't fix it.
This could be a world-wide disaster should something come up that we all need defs for! WOW.

Ah - because our WEB/INTERNET was also down........ I wasn't able to get to the web to do any searches. Now that I see there's some info out there, good to know we're really current, even though the computers state we are not.
Even my unmanaged computers are stating there's issues....... so it's not just managed computers alerting their users

hope its fixed soon!

We know its still working, but tell manager, users who only see the old date :-)

Maybe it is just a nuance of our implementation however it appears that a side effect of this issue is that C:\Program Files\Common Files\Symantec Shared\SymcData is consuming large amounts of disk space and it appears that Liveupdate wants to install the new version of the defs each time it runs. Each time LU checks it thinks there is a new version (which there actually is) however it appears that applying the defs is failing not removing the temp files for the def installation. We are shutting down Liveupdate enterprise wide. Circuits are running at capacity moving Defs around and boxes are running out of space. Basically it is an ugly situation.

I am also seeing this issue here at our site. I tried using the rapid release JDB file, and the SEPM displays the revision 1/4/2010 Rev. 18.
However, the clients are not being updated. The latest version of defs that clients are reporting is 12/31/2009 Rev. 114.

Mike

I hoped we had overcome stupid date calculation mistakes with the year 2000 bug, but it appears Symantec cant even remember what happened 10 years ago - using a single digit for the year in the defs is an obvious mistake ( YMMDDXXX - where XXX is the revision) and should have been spotted by anyone competent before it became a problem.

I am not impressed with such a stupid shortcoming in what is supposed to be an Enterprise product.

I didn't see this anywhere, but Symantec is aware this is a problem on "UN-managed" SEP clients as well correct?

Any word from anyone at Symantec how long till we will see a fix are we thinking hours, days, or weeks?

Hi,

Yes, we are aware that this issue is impacting client updates as well as SEPM and SPC updates. It is also expected for their to be a mismatch on what is up to date on the Console Home Page. We are working diligently to release a patch that will resolve this. Please continue to monitor the KB referernced for the latest information;

http://service1.symantec.com/support/ent-security.nsf/docid/2010010308571348?Open&seg=ent


At this time there is nothing that needs to be done by you to ensure that your systems are up to date. Symantec is posting new virus definitions with the 12/31/2009 date so that you have continued protection. You should see the revision number increment as new defs are posted.

JimW

ccowan,

What version of the SEP client are you seeing this issue?

Can you clarify if this is specific to your environment somehow? In other words, can you provide more information why you think this might be a "nuance of [your] implementation"?

Client definitions, both managed and unmanaged, were also initially locked at 12/31/2009 r114+ approach. This was to ensure that managed clients switching back and forth between the SEPM and LiveUpdate would have matching 12/31 schemed definitions. As we rollout the fix via LiveUpdate, we will switch all clients to correctly dated definitions. This is fine for unmanaged clients. However, managed clients that get definitions via both SEPM and LiveUpdate will see the definitions coming from SEPM as old until the server is patched. As such, clients getting updates via a mix of SEPM and LU will start having the behavior of only getting defs via LU as those are the only ones with a 2010 defs currently. When the server patch is deployed, SEPM should start getting 2010 defs and the clients will start doing both SEPM and LU updtes again.

The client software does not have any problems with 2010 definitions that we are aware of.

How often are new defs being posted.  I am still showing rev 114.  Which if I am following this thread correctly was released yesterday.  

We are seeing it in the SEPM Management consoles of which we have several (We are working to consolidate them). It appears that the clients are not experiencing the problem as you stated. On the consoles it appears that it is just the 64 bit versions of the defs that are left in the temporary directories in C:\Program Files\Common Files\Symantec Shared\SymcData\sesmvirdef64 and it appears that every other tmp folder has about 112 MB in them. There is a new folder every few minutes on some systems and some we have pinned down to every 4 hours in line with the LU update policies. C:\Program Files\Common Files\Symantec Shared\SymcData\sesmvirdef32 appears to have the tmp folders however they are empty (Maybe contents getting correctly purged?). We are still investigating and running around deleting files before the disks fill up.

They will be posted once each day.

As someone with Platinum Support, it sure would have been nice to get an email about this directly from Symantec, instead of hearing about it from one of our security people that monitors the SANS website... :-(

I would suggest you talk to support. This is not sounding like it is related to our 2010 def issue. We will also look at this specifically in relation to the 2010 issue, but it does not sound related on the surface.

JimBr - for the server patch you mentioned, is this a manually installed patch or automatic?

 I have Platinum Support and Deepsite, and product notifications all turned on and I did not see anything notifying me of this.   One of these should have atleast given me a heads up to the issue.
 

I've signed up for every alert, every newsletter, etc - and to THIS DAY, the very best I get ever is an email stating that new IPS defs will be posted. I don't need that at all since that is AUTOMATIC via LU anyway.
What I do need is this sort of information, ESPECIALLY when today of all days, our state is suffering from WEB outages due to ICN switches being down.
So I can't easily get to this site to learn this stuff, I can however get email...........

Now I see an issue with only once daily defs, too - with all the nasty stuff out there.......... I use rapid release AND LU due to a necessity that we are current at least every hour due to the risks we seem to get in here doing it any other way, so I feel sort of half-naked right now!
Is there any way around this we can use??

Once daily defs, all SEP endpoints, managed or unmanaged............ I could configure all machines to use LU but since LU is tied down now too, even our unmanaged machines will see this even though they'd normally not - is that correct?
Frankly, I'd rather have seen LU left alone so that we could at the flip of a switch cause all of our computers to update via LU and cause 300 fewer calls to our help desk!   LOL This combined with the ICN Internet outage, wow, double-whammy for us.........

Whatever, do please let us know what to do once things are fixed...........  since our clients for the "most part" get defs not via LU from outside, but from the managers inside.

No bloat on our SEM machines here - I am not seeing a loss of drive space............

PS - Hi, JimW. What a new year, eh?

We are trying to make it completely automatic, but are working through the cases. Manual either installation or possible site-level configuration changes may be needed for multi-site environments.

 @shadows papa-- this new year is 1000 times better than last new year's Downadup..which is still haunting..

 We are experiencing the same issue in our environment. SEP 11

Yes. What a new year. It will get better as we get this resolved.

Other than most clients showing the "old" date, 2009-12-31 rev. 114 all seems to be fine

However, I do have 2 clients showing the new date of 2010-01-03 rev. 020. Any idea why only these 2 and not more? The majority of my clients are on 11.0.4 but some are 11.0.5, I have yet to verify if these 2 are.

I called Symantec today because I was concerned with the date glitch as well. I had noticed yesterday when I ran LU, the date stayed the same, however the revision number changed to 114. So I ran LU again today to see if it would change, when I saw it did not thats when I called Symantec.

Another reason I did not follow up sooner is because I have seen definition dates stay the same for a few days at a time.

When I went to the Symantec website to see if there was some explination to it I did not find anything to support the issue, thats why I called.

I would suggest to Symantec to have some type of an "ALERT" tab on the main site so that average end users like myself can easily go to (www.symantec.com) and select the "ALERT" tab and be taken to a page that has this page (http://service1.symantec.com/support/ent-security.nsf/docid/2010010308571348?Open&seg=ent) listed as a click-able link.

I could have avoided all of this and just read the link above.

Is this something that can be implimented into Symantecs website in the future?

When are the virus defs for today going to be released? My clients are still running rev. 114. Thanks!

We haven't posted any 2010 defs through LiveUpdate to either clients or servers for SEP. However, if those clients are sharing definitions with another product (like our Mail Security product), then they could be getting the 2010 defs from the other product. Is this likely the case? The other, more likely, posibility is that they somehow got an Intelligent Updater run on them. All of the IUs have 2010 dates.

We see 4 temporary directories / folders created approximately every 20 minutes in C:\Program Files\Common Files\Symantec Shared\SymcData\sesmvirdef64

112 MB
Empty
107 MB
Empty

Repeat....

We are actively working on creating the defs for today. They are planned for release today, unclear exactly when. The delay is to ensure high quality delivery to our customers.

Can you provide configuration information about the server and its LU configuration? OS type, 32-bit? 64-bit?, full SEPM version #, LU to Internet or internal LiveUpdate Admin server? Also a full listing of the subfolders in sesmvirdef64 would be great.

Yes, I did run the Intelligent Update on both of those clients, which would explain it.

Windows 2003 32Bit SEPM 11.0.4000.2295 LU to " Default Symantec LiveUpdate Server". 01/04/2010 04:23 PM . 01/04/2010 04:23 PM .. 01/01/2010 01:40 AM 20091231.041 01/03/2010 04:25 AM 20091231.114 01/04/2010 01:22 PM BinHub 01/03/2010 04:25 AM 57 definfo.dat 03/30/2009 01:43 PM incoming 01/04/2010 01:32 PM 0 lulock.dat 01/04/2010 03:47 PM tmp1386.tmp 01/04/2010 02:06 PM tmp15c9.tmp 01/04/2010 02:07 PM tmp1930.tmp 01/04/2010 04:23 PM tmp212.tmp 01/04/2010 02:22 PM tmp2144.tmp 01/04/2010 01:37 PM tmp24e.tmp 01/04/2010 02:23 PM tmp2517.tmp 01/04/2010 03:32 PM tmp263a.tmp 01/04/2010 02:02 PM tmp2c04.tmp 01/04/2010 02:36 PM tmp2cb5.tmp 01/04/2010 03:21 PM tmp2f36.tmp 01/04/2010 02:37 PM tmp304a.tmp 01/04/2010 04:02 PM tmp30ef.tmp 01/04/2010 03:37 PM tmp3213.tmp 01/04/2010 02:51 PM tmp383a.tmp 01/04/2010 01:36 PM tmp3b74.tmp 01/04/2010 02:52 PM tmp3be0.tmp 01/04/2010 02:52 PM tmp3be3.tmp 01/04/2010 03:07 PM tmp43ae.tmp 01/04/2010 03:02 PM tmp4582.tmp 01/04/2010 02:17 PM tmp4762.tmp 01/04/2010 03:08 PM tmp4795.tmp 01/04/2010 01:32 PM tmp4d57.tmp 01/04/2010 04:17 PM tmp4e57.tmp 01/04/2010 03:21 PM tmp4f2c.tmp 01/04/2010 03:52 PM tmp4f7b.tmp 01/04/2010 03:22 PM tmp527d.tmp 01/04/2010 03:36 PM tmp5aa7.tmp 01/04/2010 03:38 PM tmp5e6e.tmp 01/04/2010 02:32 PM tmp64ca.tmp 01/04/2010 03:51 PM tmp6633.tmp 01/04/2010 01:47 PM tmp66aa.tmp 01/04/2010 03:52 PM tmp69df.tmp 01/04/2010 04:23 PM tmp6eda.tmp 01/04/2010 04:08 PM tmp7013.tmp 01/04/2010 04:07 PM tmp71a4.tmp 01/04/2010 01:52 PM tmp7282.tmp 01/04/2010 03:07 PM tmp7537.tmp 01/04/2010 04:09 PM tmp760e.tmp 01/04/2010 02:06 PM tmp7645.tmp 01/04/2010 02:37 PM tmp7ad9.tmp 01/04/2010 02:22 PM tmp7b2c.tmp 01/04/2010 04:22 PM tmp7d15.tmp 01/04/2010 02:47 PM tmp7e1d.tmp 01/04/2010 01:36 PM tmp7ec5.tmp 01/04/2010 01:52 PM tmpa4a.tmp 01/04/2010 03:17 PM tmpadc.tmp 01/04/2010 01:53 PM tmpe11.tmp 01/03/2010 04:26 AM 34 usage.dat 3 File(s) 91 bytes 54 Dir(s) 2,302,294,528 bytes free C:\Program Files\Common Files\Symantec Shared\SymcData\sesmvirdef64>

I can confirm that I am also experiencing this issue.  I have folders with creation dates starting at about 7a.m. Eastern  yesterday.  This is also makes sense of an oddity that I ran into yesterday troubleshooting this issue before having to check a forum to find out about this issue.  When running luall, I was still getting 64bit defintions everytime it ran.  It didn't "find" any new 32bit, just the 64bit.  Seems reasonable to me that if it creates these tmp folders everytime it runs and then downloads the 64bit defs, thinking that they need downloaded, then we are all gonna keep getting them until this issue is resolved.  Can anyone chime in on the ramifications, if there are any, of deleting these folders?? 

-Chris

You can safely wipe all *.tmp folders there as long as the LuComServer*.exe process is not running.

If a client has used Intelligent Updater, it will have to continue to have IUs to update those clients since they now has 2010 defs. This would be required until the 2010 defs start going to clients via LU (if you have LU enabled for those clients) and/or we get our fix out and your SEPM gets updated to support the 2010 defs.

I too wanted to deliver high quality services to my customers and I worked my back for hours with different fixes before I found the post..... lucky I didn't break the SEP server or the clients... :)  Now I'll just sit back and relax waiting for Symantec to deliver the solution.... I know, I know, you'll say that managers and users are coming down on us.... Let them come, we'll fight back :), after all, January10 signatures are in place though SEP's nostalgic on 2009..... However, I pity those that got to put in place access control rules on defs......

This sounds very similar to some problems related to 64-bit defs continually downloading on 32-bit OSes or 32-bit defs continually downloading on 64-bit OSes. This problem was fixed in MR4 MP2. Is anyone seeing this problem and also running MR4 MP2 or RU5?

We have the same described problem with disk space being consumed in semsvirdef64 as described in the above posts. We are running SEPM version 11.0.3001.2224 or MR3. This started coinciding with the definition dates being stuck at 12/31/09 as described in this thread and I believe it is related. We have never had an occurence of this before.

I am hold waiting to talk to support about this. Currently I am deleting the *.tmp directories older than a couple of hours in the semsvirdef64. Over the past 2 days these tmp directories are consuming around 800MB every hour.

Jim, Brian Bergin here, we're seeing this on 11.0.5002.333 on mulitple customer networks.

After speaking to support, they said many customers are having the same issue. They can't confirm it is related to the definition date issue, and they think it shouldn't be. However, they can't confirm it is NOT related.
They advised using the SymDelTmps utility to delete the temp files, and making that utility a scheduled job.

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008060212522348?Open&seg=ent

I'm not seeing a temporary folder or file build-up at all, in fact the disk usage is rather stable.
However, I'm seeing something rather confusing in the mix.
The current defs in the DAT files is correct - 20091231.116
but the previous defs listed in the DAT files is from MAY.
The folders are there with/for the prior 4 versions - all the 20091231 etc, there are 4 - the current and the prior December 2009 defs folders, but so is MAY 2009 and it's listed as the prior defs even though May defs haven't been used since, well, may!
MAYBE this is an old problem, I dunno, but I just today found this................
Why with each update of the defs doesn't is properly put in the DAT files what the most recent old defs really are, instead of reaching all the way back to May of 2009.
Unrelated???

We are definitely seeing excessive disk usage that I expect is due to this.  See the graphs below.  On Jan 2, there is a strong uptick in disk consumption. (click on the graphs to see full size)

okay - I see below that there is a known problem that was fixed in 4MR2.  We aren't on MR2, so this may be coincidence, not cause/effect.

Paul

Where can one see what version (MR or MP or RU (who made this up?)) of SEP one is running?

I see version 11.0.3001.2224 in Windows Control Panel
I see version 11.0.4000.2295 in SEPM

Envirionment:
Windows Server 2003 R2 Standard Edition SP2 32-bit
4 GB RAM, 136 GB hard drive with 20 GB free and decreasing...

We are struggling to find this problem occurring on SEPMs at MR4MP2 or greater. Definitely try the upgrade.

MR4 MP2 should have a SEPM version # of 11.0.4202.

Hi Paul,

Is there any update regarding the latest def. file. when can it be resolved.

Hi Prachand,
I would appreciate as to when Symantec will resolve this issue.
Update so that we can also inform our customers.

HI,

Can you guide how change notification of Old Virus Defination, i want to increase it's period.
Here we have 3 days time , so currently all users are getting old virus defination message.


--Keshaw Khandelwal

Nick-

You are right. We are fighting this also, and have been since Saturday, when I first called in when users started having access issues. It is the arrogance at Symantec to think that they are the only NAC solution and they will protect the infrastructure. Enterprises have policies in place for a reason, and asking over 500,000 users to "dumb down" security policies is a bad business practice for a company who is trying to sell Security Products.

We have had business partners we deal with have to get another AV solution to connect to us via SSL VPN, because we won't change our rules (they also use SEP, and aren't getting def dates past 12/31/09). We just hope that this gets fixed before 4000 users start entering payroll shortly.

That's a very good point, and one that may start biting us soon also.

Whilst we can alter our own NAC rules, we cannot force our customers to do so.

We support several thousand customers remotely, some of whom have their own NAC products and rules and are not sympathetic to Symantec's cockup.
IE they will refuse to change their NAC rules to accomodate - This will mean that we will need to install a different product in order to connect to these customers.

Fortunately, we switched from SEP some time ago on our main support system due to it being completely unusable in a massive virtual environment, but we do still have some support systems that use it.



Nick

I'm on ru5 and I'm not seeing the disk space being chewed up with 64 bit defs.

Paul,
            In addition to SEP virus definition being stuck at 12/31/09, it appears that R114 also caused the tmp folders in sesmvirdef32 to fill up my C drive. Symantec response now is to upgrade to R5 (see link). I do not want to be force into a upgrade. When will Symantec fix the problem with the virus definition and when fix, will it also resolve the tmp folders problem?

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010617161948?Open&seg=ent

Fittanchew

But Wait for How Log???

We the Techies can understand but the investors will not listen this excuses.

Symantec will have to fix up ASAP

post a discussion for ur question

I tried to follow the procedure on http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010011512020748
However, On Manual Patching Instructions, how can I update the SEPM Content Catalog and Cache if I dont have internet access?! I need to do it manually
Is there any way to update it manually?!

Thanks

I also have several standalone networks with no internet connectivity that I need to FULLY correct.  I successfully patched my Symantec Endpoint Protection 11 Release Update 5 (RU5) - 11.0.5002.333 using the downloaded  SEPServerPatch-v6.01.exe.  This now allows me to update the definitions, as evidenced by the incrementing revision number, but the date is still displayed as Thursday, December 31, 2009.  The following steps which apparently fix this part of the issue, I am unable to perform due to the lack of internet connectivity. 

Update the SEPM's Content Catalog:
Click the Admin tab in the SEPM interface
Click the Servers tab and select the Local Site from the View Servers list
Click Download LiveUpdate Content in the Tasks pane
Click the Download button on the Download LiveUpdate Content window
After LiveUpdate completes, the SEPM will now have an updated Content Catalog including the information necessary to download 2010 definitions
Update the SEPM's Content Cache:
Click the Admin tab in the SEPM interface
Click the Servers tab and select the Local Site from the View Servers list
Click Download LiveUpdate Content in the Tasks pane
Click the Download button on the Download LiveUpdate Content window
After LiveUpdate completes, the SEPM will now have 1 set of Antivirus and Antispyware definitions with a 2010 date

Will there be a solution for those of us with this issue?

Thanks

Hi i am using 64bit windows server 2003 and i have symantec endpoint 11 v. 11.0.2000.1567. I tried to apply the patch but it says "Unable to apply patch on this computer" is it because of 64bit and if not what may be the cause of it?.

I also have the same problem because my server and clients cannot speak out to the internet.  Is there some way to clear out all the definition files and then bring in a new one and have it update that way?

Will Symantec be creating a new build or Maintenance release for administrators like me and others in this thread that have their SEPM server and clients on a network without internet access?  The procedures listed here are simple enough, but if you cannot connect to live update, you cannot update your server. 

I currently get my updated virus definitions by downloading them from the internet (*.jdb files) and moving them to my other network.  Can I forego the live update portions of the procedure by simply downloading a few days worth of virus definition updates and put these into the incoming folder of the SEPM after the patch executable is applied? 

If this works, is there anything I would need to do to my clients to make them show the correct definition date or will they just report the correct date without any other actions after the SEPM is updated?

It would be nice if a KB could be published to help those of us without internet access on our networks or even if a new build were to be published soon.

Thanks

O.K.  So I have followed the instructions below on 3 separate closed networks (no internet access) all running 11.0.5002.333.  The patch completes successfully.  Then I download the latest JDB def file and copy it into the incoming folder, and it applies the latest defs.  While the rev number of the definitions increments, it still displays the 12/31/2009 date.  Since our setup 'nags' users about defs more than a week old, this feature becomes bogus.  I wonder what exactly is meant by step 3 below.  Yes, I know i can change the 'nag' limits to avoid the bogus alerts.



Apply the patch:

1. Download the manual patch SEPServerPatch-v6.01.exe (SEPServerPatch-v6.01.exe : SHA- C5F6CC5FA3C5B1FE47066CD3FF5645D688339CE2)
2. Execute the patch directly on each affected SEPM server
   For JDB users:
3. After applying the patch, no further configuration is required to apply JDB-based definitions with a 2010 date.    

Hey you can enable use "live update server" option in live update policy.
it will use little bit internet bandwidth of your network.

It will resolve your issue untill you get the solution from Symantec.

Hey you can enable use "live update server" option in live update policy.
it will use little bit internet bandwidth of your network.

It will resolve your issue untill you get the solution from Symantec.

Someone in the thread said, symantec endpoint protection has requested new definitions from the management server. The problem will disappear after the server responds and the update is complete. Has this solved the issue then?