The agents on my update servers point them to 127.0.0.1 for updates and to the main policy server for policy updates.
Die dulci fruere! Roger Wright ___ On Thu, Feb 25, 2010 at 2:25 PM, Tom Miller <tmil...@hnncsb.org> wrote: > Roger, for your branch offices update servers, what server name/IP do you > have for the update? > > >>>> Roger Wright <rhw...@gmail.com> 2/25/2010 2:22 PM >>> > I don't think so. The policy updates should come from the main > server, but the branch update servers can get their updates directly > from Sunbelt. Branch clients point to their local update server for > updates but to the main policy server for policy updates. > > That's how I've configured things in two networks. > > > > Die dulci fruere! > > Roger Wright > ___ > > > > > On Thu, Feb 25, 2010 at 2:17 PM, Tom Miller <tmil...@hnncsb.org> wrote: >> I don't see that text in the link you provided, but that (the first link) >> is >> a pretty old discussion and there have been upgrades since then. >> >> I think what Sunbelt means is the "main" server gets its updates from >> Sunbelt servers but all other servers should be pointed to that main >> server >> for updates. Then the remote server in turn updates its agents within the >> policy scope. At least that's the way it works here, very similar to how >> I >> had Symantec working. As for the second threat that makes no sense. >> >> If I were you I'd send this thread to Sunbelt for clarification and let us >> know the response. >> >>>>> "David Mazzaccaro" <david.mazzacc...@hudsonhhc.com> 2/25/2010 12:34 PM >>>>> >>> >> Really??? >> Both Curt and Brian from Sunbelt Software on the forum say otherwise..... >> >> >> ~~~~~~~~~~~~~/SNIP/~~~~~~~~~~~~~~ >> >> http://supportforums.sunbeltsoftware.com/messageview.aspx?catid=27&threadid=1155&highlight_key=y >> A remote update server pulls definitions directly from Sunbelt and >> downloads >> them to those agents. All policies and reporting are still handled by the >> VIPRE service, thus the remote machines remain in contact. The remote >> update >> server negates the need to push updates across the T1 line from site to >> site. >> >> Curt >> >> ------------------------- >> Curt Larson >> Product Manager >> Sunbelt Software >> cu...@sunbeltsoftware.com >> >> ~~~~~~~~~~~~~/SNIP/~~~~~~~~~~~~~~ >> >> >> http://supportforums.sunbeltsoftware.com/messageview.aspx?catid=27&threadid=2378&highlight_key=y >> >> VIPRE Enterprise is able to be configured as an update server, but those >> updates come from the internet. Currently there is not an option to have >> the >> remote update servers pull their definitions from a central policy server, >> but it has been requested as a feature. >> >> ------------------------- >> Brian Ross >> >> Malware Removal Specialist >> >> Sunbelt Software >> >> Support Contact Info: >> >> supp...@sunbeltsoftware.com >> >> ~~~~~~~~~~~~~/SNIP/~~~~~~~~~~~~~~ >> >> >> http://supportforums.sunbeltsoftware.com/messageview.aspx?catid=27&threadid=1626&highlight_key=y >> >> I did check into this, and we have a feature request on the backlog to add >> this functionality. I do not have an ETA on that addition though. >> >> ------------------------- >> Brian Ross >> >> Malware Removal Specialist >> >> Sunbelt Software >> >> Support Contact Info: >> >> supp...@sunbeltsoftware.com >> >> ~~~~~~~~~~~~~/SNIP/~~~~~~~~~~~~~~ >> >> >> >> >> ________________________________ >> From: Tom Miller [mailto:tmil...@hnncsb.org] >> Sent: Thursday, February 25, 2010 12:20 PM >> To: NT System Admin Issues >> Subject: RE: VIPRE versus Trend >> >> Remote update servers are supposed to get their updates from the main >> console servers. That's the way I have my Vipre configured and it works >> fine. I wonder who at Sunbelt told you remote PCs/servers should get >> updates via the Internet. That's counter-intuitive for hub-and-spoke >> networks. >> >> This is the doc I used to set this up here: >> http://support.sunbeltsoftware.com/Default.aspx?answerid=1859 >> >>>>> "David Mazzaccaro" <david.mazzacc...@hudsonhhc.com> 2/25/2010 11:58 AM >>>>> >>> >> We have a VPN, I will check w/ the PIX in regards to policy and scanning. >> >> re: "If you instruct your remote update server to update from Sunbelt, >> that >> seems odd" >> Currently, this is the only way a remote update server CAN update itself. >> The main console could certainly handle pushing updates to the remote >> update >> servers (this is how Symantec Corp Ed worked), but Vipre doesn't offer >> this >> (yet). >> >> thx >> >> >> >> ________________________________ >> From: Tom Miller [mailto:tmil...@hnncsb.org] >> Sent: Thursday, February 25, 2010 11:51 AM >> To: NT System Admin Issues >> Subject: RE: VIPRE versus Trend >> >> For your remote offices: do they connect via direct point to point/frame >> relay or via a VPN? I just want to be certain. If using a VPN, does this >> route via your firewall? I have many smaller sites set up this way, but >> be >> careful if you have any scanning/blocking policies, as that may impact >> vipre >> updates. I had some issues with remote updates and it turns out my >> firewall >> scan policy was really slowing down updates. >> >> Yes, you really must get a remote update server at each site. Just make >> it >> a PC, no server necessary. Then only one will update across your >> VPN/frame >> relay. >> >> If you instruct your remote update server to update from Sunbelt, that >> seems >> odd, since it would still have to traverse the VPN to get to HQ, then to >> the >> Internet. Is your main Console server overloaded that it cannot handle >> the >> remote update requests? >> >> Just trying to understand. >> >>>>> "David Mazzaccaro" <david.mazzacc...@hudsonhhc.com> 2/25/2010 11:15 AM >>>>> >>> >> Well, here's my situation: >> Let's start w/ my main location (location A). >> Location A is our corporate headquarters. It is our only location that >> has >> an internet connection. >> We have 9 other smaller remote offices (location B, C, D, etc). >> Each remote site has a T1 line connecting them to our provider's VPN cloud >> and back to our corporate office. >> These offices have circuits ranging from 512k - full 1.5M depending on >> their >> size. >> >> Vipre's updates (and method of deploying these updates) is simply put... a >> nightmare. >> Everyday, and sometimes twice a day, sunbelt releases MASSIVE definition >> updates. >> So in order to stay up-to-date, I have to drag hundreds of MB across my >> 512k lines (daily). >> >> Originally, the Vipre server at location A downloads the updates every 4 >> hours (the most frequent setting). >> Based on policies on the server at location A, updates are pushed out to >> the >> remote offices. >> Even if I configure "bandwidth throttling", all this does is slow down the >> amount of time the updates will take to reach the remote users. >> Often, by the time one update is finished, another one has been released. >> This setup has caused major network congestion, so I attempted to deploy a >> remote vipre update server on one of my desktops at a remote site. >> >> This remote update server at location B is configured to download updates >> from sunbelt directly. >> This is the only way a remote server can update itself. >> I assumed that it would be able to pull updates from my main server in >> location A, but I am being told that it has to go out to the internet to >> get >> its updates. >> So I thought one PC downloading an update over the circuit is better than >> a >> dozen. >> >> However, here is the problem with this arrangement: >> The remote update server can't be configured to throttle its own updates, >> so >> I am still stuck pulling down 100+ MB updates over a 512k line with no >> control over the bandwidth. Also, the remote update server (just like the >> agents) can only be configure to get updates every x hours (not at a >> specified time of day). >> And… when the Vipre service restarts (due to reboot, MS update, >> maintenance, >> power outage, whatever)… the timer starts from that point. >> >> I will say that it IS getting better, and version 4 is promising to fix >> this >> (and several other) issues. >> >> The Vipre Enterprise forum on the Sunbelt website is a great place to keep >> up w/ info: >> http://supportforums.sunbeltsoftware.com/ >> >> >> HTH >> >> ________________________________ >> From: Don Guyer [mailto:don.gu...@prufoxroach.com] >> Sent: Thursday, February 25, 2010 10:58 AM >> To: NT System Admin Issues >> Subject: RE: VIPRE versus Trend >> >> I’m right in the middle of evaluating McAfee replacements here, so keep >> this >> type info coming, please! >> >> >> >> Also, if anyone has info (good/bad) about any vendor’s solution, please >> post >> up. Feel free to contact me offline, if you feel that’s necessary. >> >> >> >> Thx! >> >> >> >> Don Guyer >> >> Systems Engineer - Information Services >> >> Prudential, Fox & Roach/Trident Group >> >> 431 W. Lancaster Avenue >> >> Devon, PA 19333 >> >> Direct: (610) 993-3299 >> >> Fax: (610) 650-5306 >> >> don.gu...@prufoxroach.com >> >> >> >> From: Sherry Abercrombie [mailto:saber...@gmail.com] >> Sent: Thursday, February 25, 2010 10:35 AM >> >> To: NT System Admin Issues >> Subject: Re: VIPRE versus Trend >> >> >> >> I've had a completely different experience with Vipre Enterprise Steve. >> We >> have had some issues with Vipre bpam service using up non-paged pool >> memory, >> causing the server to become unresponsive, this happened on a very small >> subset of servers, but a very significant subset, namely database servers >> with Oracle on them. In working with Vipre support we completely disabled >> quick scans, and deep scans, only using active protection on the policy >> group for database servers. We also made some changes in memory >> management >> on the servers per some MS KB articles that we researched and that Vipre >> support directed us to. We haven't had any issues with this in 2-3 >> months. >> >> I've not ever used Trend, only McAfee and Vipre. Vipre management console >> is great, easy and intuitive compared to McAfee's ePO. Vipre has caught >> more stuff than we ever thought possible since we've implemented it, >> including some password cracker applications on workstations that >> shouldn't >> have those kind of things...... >> >> I've got Vipre installed on 650 nodes, and am having to up my license >> count >> because we're out of licenses. >> >> On Wed, Feb 24, 2010 at 3:42 PM, Steve Kelsay <kels...@sctax.org> wrote: >> >> I wish I could be more optimistic, but We are using the Vipre Enterprise. >> It >> does an excellent job of protecting us, when I can keep it running. It >> seems >> like it just is not ready for primetime. Sunbelt had their top tech go >> through our entire network setup during a recent Konficker attack, and it >> is >> still not really stable. >> >> >> >> I can look at the console and believe it is running wonderfully, until >> scans >> start without any identifiable cause, effectively shutting down servers >> with >> 100% Cpu usage, but that scan never shows up on the remote console, >> although >> the machines are sending last contact info, and last scan info, the off >> time >> scans never show up. I lobbied hard to get Vipre, and really want it to >> succeed, but it is not looking good at this time. A deep scan starts on >> many >> machines as soon as anyone logs onto the machine, and that will also peg >> the >> CPU meter. No reason we can tell for this to happen. >> >> >> >> From: Raper, Jonathan - Eagle [mailto:jra...@eaglemds.com] >> Sent: Wednesday, February 24, 2010 4:26 PM >> >> To: NT System Admin Issues >> Subject: VIPRE versus Trend >> >> >> >> All, >> >> >> >> We’re looking to move away from McAfee. Right now we’re considering Trend >> Micro OfficeScan Enterprise and the VIPRE Enterprise products. >> >> >> >> Anyone here (aside from Sunbelt employees) have any experience with both >> of >> the current or relatively current iterations of the products? >> >> >> >> Can you provide any reasons to choose one over the other, aside from >> price? >> >> >> >> Thanks in advance, >> >> Jonathan L. Raper, A+, MCSA, MCSE >> Technology Coordinator >> Eagle Physicians & Associates, PA >> jra...@eaglemds.com >> www.eaglemds.com >> >> >> >> >> >> ________________________________ >> >> Any medical information contained in this electronic message is >> CONFIDENTIAL >> and privileged. It is unlawful for unauthorized persons to view, copy, >> disclose, or disseminate CONFIDENTIAL information. This electronic message >> may contain information that is confidential and/or legally privileged. It >> is intended only for the use of the individual(s) and/or entity named as >> recipients in the message. If you are not an intended recipient of this >> message, please notify the sender immediately and delete this material >> from >> your computer. Do not deliver, distribute or copy this message, and do not >> disclose its contents or take any action in reliance on the information >> that >> it contains. >> >> >> >> >> >> >> >> >> >> >> -- >> Sherry Abercrombie >> >> "Any sufficiently advanced technology is indistinguishable from magic." >> Arthur C. Clarke >> >> >> >> >> >> >> >> >> >> . >> >> >> >> >> >> Confidentiality Notice: This e-mail message, including attachments, is for >> the sole use of the intended recipient(s) and may contain confidential and >> privileged information. Any unauthorized review, use, disclosure, or >> distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply e-mail and destroy all copies of the original >> message. >> >> >> >> >> >> . >> >> >> >> >> >> Confidentiality Notice: This e-mail message, including attachments, is for >> the sole use of the intended recipient(s) and may contain confidential and >> privileged information. Any unauthorized review, use, disclosure, or >> distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply e-mail and destroy all copies of the original >> message. >> >> >> >> >> >> . >> >> >> >> >> >> Confidentiality Notice: This e-mail message, including attachments, is for >> the sole use of the intended recipient(s) and may contain confidential and >> privileged information. Any unauthorized review, use, disclosure, or >> distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply e-mail and destroy all copies of the original >> message. >> >> >> >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > Confidentiality Notice: This e-mail message, including attachments, is for > the sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure, or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
