If you are upgrading to Trend Worry-Free Business Security 5.1 and you are coming from their v5.0 product then you will want to go and install Patch 2 first. Patch 2 resolves a few issues in 5.0 that caused the upgrade to 5.1 to fail. Best Practice install this patch before upgrading to 5.1 it s only a 43MB download 🙂
You can get the patch from the following locations
WFBS 5.0 Standard http://www.trendmicro.com/download/product.asp?productid=100
WFBS 5.0 Advanced http://www.trendmicro.com/download/product.asp?productid=99
Greg Lipschitz says
I had so many issues at one site with 5.1.
It bluescreened PC’s on 1 site, bought network traffic in another to a halt and made the machines run like absolute crap!
Trend have been working through it but still have no idea of the root cause of the issue.
Greg
Tim Sullivan says
Wayne – Since you are the Trend guy, I wanted to run something past you. We upgraded a client from CSM 3.6 to WFBS 5.1 last week. They are running SBS 2003 SP2 with ISA 2004. After the upgrade, we get thousands of Event ID 537 – logon problem. The status code is: 0x80090308. I called Trend about this and they said it is a known problem with
AD passwords longer than 14 characters. We have plenty of clients with longer passwords and this is the only one with this problem. Have you seen anything like this?
Tim says
hi all, possible problem ive come across, i have installed wfbs 5.1 advanced throughout most of my clients servers with no major issues, however one of them has been causing nightmares with client internet access, i have been having to disable then re-enable the “network connection”, terminating firewall services, then restarting them every morning. it appears when the server security agent is not installed, we get no problem (but slight security risk!). i looked in event vwr and found isa complaining about a conflict on port 8080. which is isa proxy client service – that the clients IE all use! i can only guess the trend server client is hogging that port. it doesnt help the fact that the isa advanced sql database logging is screwed and it terminates at midnight, which i am finally sorting out tomorrow! (if i can remember the procedure). a scheduled script gets round it for the moment. any ideas on this possible conflict? or is something else wrong??? its a few hundred miles to visit them, as you know remote control fixing and firewall configs dont mix!