If you have the misfortune to have BackupExec at your client sites, you may have noticed your backups failed last night with “e000e020 – The job was scheduled to run, but the availability window closed before the job could start. There may not have been any destination devices available during the window, or the job may have been submitted to run when the window was closed”
Apparently this is due to Daylight Savings Time – the solution is to rerun the job or wait and see if it runs tonight – Thanks for a really helpful solution Symantec.
Symantec have now released a patch that fixes the issue of definitions being dated 12/31/2009. However, the patch so far is only available for those running 11.03 or 11.05. For more details read the official statement on the Symantec forums or the Symantec Knowledgebase article . Most of our Endpoint Protection Servers were running 11.0.4 (as live update does not upgrade the server console component) so we have to upgrade to 11.0.5 first. This can be seen as a good thing as 11.0.4 has the nasty feature of filling up the hard drive of the server as Symantec downloads and keeps 3 copies of the av definitions every few minutes as it tries to download definitions dated in 2010 (and fails). So far, most of the Endpoint Protection Manager upgrades have been fairly simple with straightforward instructions – a 25 minute process after the files have been downloaded (including backing up the database) but we had one site that didn’t work and we had to reinstall every single Symantec Endpoint Protection client and server by hand. Not a lot of fun.
Yes I deliberately posted the date this way as that is how the shortsighted programmers as Symantec did it. Needless to say, when the year rolled around to 00101 this is a lot less that 91231 so the definitions were treated as old. It scares me to see that this bug managed to get into the product – did they not learn anything from the Y2K issues?
To make matters worse we found some servers were continually downloading definitions onto the server and in one case filled up 73gb of disk space. The fix for this is to ensure that the endpoint protection manager software is running 11.0.5 – this is a new download and upgrade installation although for one of our clients it meant uninstalling and reinstalling every single pc at that location – not an upgrade at all.
To top it all, Symantec also decided this week to announce the end of life for the v10 of their products – the only version that was actually working with correct definition dates. Although end of life is in 2012, support should really have coordinated with sales to ensure that the notice didn’t go out *this* week.
I think I still have a few servers that haven’t updated, so I will be checking those out next week. If we continue to use Symantec (which I really do not want to do), I’m hoping to look at an MSP installation of the product – one server managing all the clients so I only have one place to check for client status (and only one server to install, patch and configure)
Most of our Symantec Endpoint Protection clients are alerting that the definition dates are old (we reduce the alert time to less than the default 30 days). These alerts are coming in through the desktop client and also through both of our monitoring systems. Apparently Symantec are aware of the issue (see “The date of the definitions in Symantec Endpoint Protection clients and Symantec Endpoint Protection Manager remain at Dec 31 2009”) and their definitions cannot have a date in 2010. Therefore their work around is to push out new updates with a date of December 31st 2009 and they are just increasing the version number until engineering come up with a patch to fix the issue of not accepting dates in 2010.
I sure hope that their update plan works better than our most recent upgrade that meant we had to reinstall the client by hand at every desktop. None of the upgrade processes would work.
So I’ve spent ages troubleshooting and debugging Symantec’s Endpoint Protection (SEP) version 11, MR4 – the first version that actually has a hope of working on a 64bit platform. After spending far too long configuring the various policies and tweaking various settings I was finally able to get the software installed via group policy on a testlab machine but the client would not checkin with the management server. The virus definitions were 4 months old BUT the client console was saying everything was ok. Lots of troubleshooting later and I stumbled across the definitions for the Management server – a setting that I had originally wanted to change anyway. In there I saw that the management server was listening on port 8014 and a quick telnet check from the client showed I was unable to connect. Disabling windows firewall (temporarily – this is on a testlab so the infection risk is minimal) allowed the client to check in with the server, change some settings in the console and update the virus definition dates. Finally I re-enabled the firewall, added an exception for TCP port 8014 and it all looks good, but I’ll wait to see what happens overnight for definition updates on the client. For future reference the list of communications ports for version 11 can be found at Symantecs website here or posted below in the extended entry.
Discovered that 64bit clients of Symantec Antivirus have to be set to get their updates from Symantec servers using LiveUpdate, not from the Management server (as you would normally set the configuration to be). This may involve creating a new management group in Symantec’s Administration console and setting the update to not use the parent server as per the screenshot below.
When trying to run LiveUpdate from within BackupExec v12 running on Windows 2008 you may get the error message “To receive updates, Backup Exec must be registered with LiveUpdate. To automatically register now, Click Yes. If you choose not to register now, you will be prompted again when you click LiveUpdate.” The solution is to right click the BackupExec icon and run as Administrator. LiveUpdate will work.
I logged a ticket with Symantec today as I needed to download Maintenance Release 7 for their corporate edition 10.1 yet their fileconnect website only gave me version 11 (which is so unstable we refuse to install it). 2 hours later I got an email from their support site that started “We have been trying to reach you in the last few days to assist you with the issue regarding Symantec Antivirus but unfortunately we have not been able to do so.”
I guess they’ve invented a time machine in order to try and beat their really long wait times on hold for support…..either that or I forgot that I logged a ticket several days ago and they’ve finally got round to dealing with it!
Anyway, they’ve given me a new serial number to log into the website with so I can download the older version. I’m not sure if it’s an inplace upgrade (I hope so) rather than a removal and reinstall again – if its the removal and reinstall that means *another* 3 or 4 hours to remove, reboot, install and then fix the issues of the client software breaking other software again.
I guess I *really* need to get some time to investigate nod32 network deployments – anyone had any experience with this?
I had the good fortune to get through to Symantec support in under a minute this afternoon – probably because there tech’s can’t actually do much as their licensing portal is down. For some reason the system doesn’t actually bother to tell you this, even after you spend ages filling in all the details they need and hitting the final submit button. It would be nice if they put a notice at the login screen to say that the server is down, don’t bother wasting 30 minutes to get a serial number so that you can install the product you’ve purchased and use it!