http://support.sunbeltsoftware.com/Default.aspx?answerid=1859
Die dulci fruere! Roger Wright ___ On Thu, Feb 25, 2010 at 2:39 PM, Roger Wright <[email protected]> wrote: > 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 <[email protected]> wrote: >> Roger, for your branch offices update servers, what server name/IP do you >> have for the update? >> >> >>>>> Roger Wright <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >>> [email protected] >>> >>> ~~~~~~~~~~~~~/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: >>> >>> [email protected] >>> >>> ~~~~~~~~~~~~~/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: >>> >>> [email protected] >>> >>> ~~~~~~~~~~~~~/SNIP/~~~~~~~~~~~~~~ >>> >>> >>> >>> >>> ________________________________ >>> From: Tom Miller [mailto:[email protected]] >>> 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" <[email protected]> 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:[email protected]] >>> 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" <[email protected]> 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:[email protected]] >>> 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 >>> >>> [email protected] >>> >>> >>> >>> From: Sherry Abercrombie [mailto:[email protected]] >>> 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 <[email protected]> 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:[email protected]] >>> 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 >>> [email protected] >>> 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/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
