I've got something you can hug.... t On 7/10/06 1:56 PM, "Jim Harrison" <Jim@xxxxxxxxxxxx> spoketh to all: > I think someone needs a hug... > > > ------------------------------------------------------- > Jim Harrison > MCP(NT4, W2K), A+, Network+, PCG > http://isaserver.org/Jim_Harrison/ > http://isatools.org > Read the help / books / articles! > ------------------------------------------------------- > > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On > Behalf Of Thor (Hammer of God) > Sent: Monday, July 10, 2006 11:50 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: [ISAServer] Firewall database corruption due to power > outtage > > Actually, it doesn't steam me in the least. While I can perceive the value > of the lockdown feature, it adds no value to my environment-- I have no > problem at all disabling it. In fact, it's been disabled since I began > logging to SQL on my servers (long time now). No worries here. > > The whole thing got started when I was simply trying to identify to the ISA > group that when logging to SQL, ISA's lockdown mode is "trigger happy" when > certain maintenance takes place on the server- that "maintenance" can be the > purging of "fluff" in the WebProxyLog, performing a mass update of data in > the logs, or even regular DB Maint jobs that re-index, optimize, shrink > db's, etc. It's not about trimming logs, purging logs, or anything to > "solve" ISA logging issues- it can be something that doesn't even involve > ISA logs per se. > > It was the identification that, in the real-world, "ISA Logging to SQL == > Disabled Lockdown Mode" is the inevitable result in all the cases I > examined. I didn't even say that was a bad thing- I'm quantifying it, not > qualifying it. Like I said, I don't really care about lockdown mode. I was > just pointing out that if lockdown mode was going to be considered an > important feature to enterprise customers, (which I have seen it be) then > the end user is going to require better, customizable options regarding the > parameters used when ISA logs to SQL, or else they will be forced to disable > it. You can't tout a feature as important if it will ultimately require > disabling when deployed. That's all. > > The only time I got close to being "steamed" was when recommendations kept > coming back regarding how to fix the "fluff" issues. I've already fixed the > fluff issues. I said that several times. I was asking for detailed > information on the criteria ISA uses to initiate lockdown when logging to > SQL, not how to address log cruft, structure tables, or when to run > maintenance jobs. My goal was to gain information on how to build a robust, > dependable connection that would endure "standard," every-day loads, not on > how to avoid using the connection in those environments. > > > That's it. Done over here ;) > > t > > > > > > On 7/10/06 10:32 AM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> spoketh to > all: > >> Why get steamed? Seems purdy easy to me. >> >> Thomas W Shinder, M.D. >> Site: www.isaserver.org >> Blog: http://blogs.isaserver.org/shinder/ >> Book: http://tinyurl.com/3xqb7 >> MVP -- ISA Firewalls >> >> >> >>> -----Original Message----- >>> From: isapros-bounce@xxxxxxxxxxxxx >>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison >>> Sent: Monday, July 10, 2006 12:28 PM >>> To: isapros@xxxxxxxxxxxxx >>> Subject: [isapros] Re: [ISAServer] Firewall database >>> corruption due to power outtage >>> >>> Nope - just a workaround that makes Tim all steamy. >>> >>> ------------------------------------------------------- >>> Jim Harrison >>> MCP(NT4, W2K), A+, Network+, PCG >>> http://isaserver.org/Jim_Harrison/ >>> http://isatools.org >>> Read the help / books / articles! >>> ------------------------------------------------------- >>> >>> >>> -----Original Message----- >>> From: isapros-bounce@xxxxxxxxxxxxx >>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder >>> Sent: Monday, July 10, 2006 09:20 >>> To: isapros@xxxxxxxxxxxxx >>> Subject: [isapros] Re: [ISAServer] Firewall database >>> corruption due to power outtage >>> >>> Then that would fix it? Right? >>> >>> Thomas W Shinder, M.D. >>> Site: www.isaserver.org >>> Blog: http://blogs.isaserver.org/shinder/ >>> Book: http://tinyurl.com/3xqb7 >>> MVP -- ISA Firewalls >>> >>> >>> >>>> -----Original Message----- >>>> From: isapros-bounce@xxxxxxxxxxxxx >>>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor >>>> (Hammer of God) >>>> Sent: Monday, July 10, 2006 11:15 AM >>>> To: isapros@xxxxxxxxxxxxx >>>> Subject: [isapros] Re: [ISAServer] Firewall database >>>> corruption due to power outtage >>>> >>>> Right... That's what I said... Disable lockdown. >>>> >>>> t >>>> >>>> >>>> On 7/10/06 8:29 AM, "Jim Harrison" <Jim@xxxxxxxxxxxx> >>> spoketh to all: >>>> >>>>> Like unto thusly: >>>>> >>>> http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/dis >>>> ablelockdownonlo >>>>> gfailure.mspx >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> Jim Harrison >>>>> MCP(NT4, W2K), A+, Network+, PCG >>>>> http://isaserver.org/Jim_Harrison/ >>>>> http://isatools.org >>>>> Read the help / books / articles! >>>>> ------------------------------------------------------- >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: isapros-bounce@xxxxxxxxxxxxx >>>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On >>>>> Behalf Of Thomas W Shinder >>>>> Sent: Monday, July 10, 2006 08:10 >>>>> To: isapros@xxxxxxxxxxxxx >>>>> Subject: [isapros] Re: [ISAServer] Firewall database >>>> corruption due to power >>>>> outtage >>>>> >>>>> Log Failure Alert. >>>>> >>>>> Thomas W Shinder, M.D. >>>>> Site: www.isaserver.org >>>>> Blog: http://blogs.isaserver.org/shinder/ >>>>> Book: http://tinyurl.com/3xqb7 >>>>> MVP -- ISA Firewalls >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: isapros-bounce@xxxxxxxxxxxxx >>>>>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor >>> (Hammer of >>>>>> God) >>>>>> Sent: Monday, July 10, 2006 9:24 AM >>>>>> To: isapros@xxxxxxxxxxxxx >>>>>> Subject: [isapros] Re: [ISAServer] Firewall database >>>> corruption due to >>>>>> power outtage >>>>>> >>>>>> What do you mean "the alert?" What alert? >>>>>> >>>>>> t >>>>>> >>>>>> >>>>>> On 7/10/06 7:21 AM, "Thomas W Shinder" >>>> <tshinder@xxxxxxxxxxx> spoketh >>>>>> to >>>>>> all: >>>>>> >>>>>>> Hi Tim, >>>>>>> >>>>>>> But you can do that by configuring the Alert to not send >>>>>> the system into >>>>>>> lockdown. >>>>>>> >>>>>>> Thomas W Shinder, M.D. >>>>>>> Site: www.isaserver.org >>>>>>> Blog: http://blogs.isaserver.org/shinder/ >>>>>>> Book: http://tinyurl.com/3xqb7 >>>>>>> MVP -- ISA Firewalls >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>> Sent: Monday, July 10, 2006 9:16 AM >>>>>>>> To: Adar Greenshpon; ISA-MVP; Avi Sander; Nathan Bigman >>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>> due to power >>>>>>>> outtage >>>>>>>> >>>>>>>> I guess I misunderstood. The "mentioned below" items >>> kept going >>>>>>>> back to how to remove the fluff, rather than dealing >>> with why ISA >>>>>>>> goes into lockdown so readily. I've still not seen any >>>> information >>>>>>>> on how/when/why ISA goes into lockdown when logging to >>> ISA. You >>>>>>>> had indicated that the other information was >>> incorrect, so I was >>>>>>>> standing by for that info. >>>>>>>> >>>>>>>> It doesn't matter if you put it in a different database. >>>> When the >>>>>>>> optimization plan (you know, the "normal" plan that >>>>>> rebuilds indexes, >>>>>>>> insures integrity, etc) runs, ISA goes into lockdown. Even if I >>>>>>>> waited a week in between times that I purged the data, >>> I'll still >>>>>>>> have to perform some maintenance, and the system would still go >>>>>>>> into lockdown. >>>>>>>> >>>>>>>> The solution is to disable lockdown. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> t >>>>>>>> >>>>>>>> >>>>>>>> On 7/10/06 12:13 AM, "Adar Greenshpon" >>>>>> <Adar.Greenshpon@xxxxxxxxxxxxx> >>>>>>>> spoketh to all: >>>>>>>> >>>>>>>>> Thor: as I've indicated below, we plan on improving the >>>>>> connectivity >>>>>>>>> issue you raised. Given the current SQL logging >>>>>> limitation and your >>>>>>>>> deployment, might it be possible to split the webproxy >>>>>> log into two >>>>>>>>> databases: one for historical purposes and one for current >>>>>>>> events. The >>>>>>>>> heavy-weight maintenance could be done on the former one >>>>>>>> while the later >>>>>>>>> one would be available for ISA to dump logs into. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>> Sent: Monday, July 10, 2006 1:50 AM >>>>>>>>> To: ISA-MVP; Avi Sander; Adar Greenshpon; Nathan Bigman >>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>> due to power >>>>>>>>> outtage >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, Jim... Thank you. Sorry that I got so short, but I >>>>>> was getting >>>>>>>>> quite >>>>>>>>> frustrated trying to make the same point over and over again. >>>>>>>>> >>>>>>>>> The focus need not be on "how to trim the logs." That's >>>>>>>> not the *real* >>>>>>>>> issue. The focus needs to be: "Regarding lockdown, what >>>>>>>> factors are in >>>>>>>>> play >>>>>>>>> when ISA logs to SQL, and under what circumstances does >>>> ISA invoke >>>>>>>>> lockdown when posting to a SQL DB?" >>>>>>>>> >>>>>>>>> Let's put the padding issues *totally* out of the picture. >>>>>>>> Let's say >>>>>>>>> that >>>>>>>>> I've got TB's of storage and that I could not care less >>>>>>>> about how much >>>>>>>>> fluff >>>>>>>>> is in my WebProxyLog-- let it get as big as it wants. >>>>>>>> However, I must >>>>>>>>> back >>>>>>>>> it up. I've also experienced ISA going into lockdown >>>>>>>> during classic db >>>>>>>>> maintenance like backing up, re-indexing, optimizing size, >>>>>>>> etc. These >>>>>>>>> processes must be run regardless of the presence of >>>>>>>> "padding issues" or >>>>>>>>> not. >>>>>>>>> In fact, even if the padding problem is solved in ISA2006, in >>>>>>>>> combination with or exclusive of contributing options >>>> in SQL 2005 >>>>>>>>> (which I'm migrating to as I type), ISA will still go into >>>>>>>>> lockdown when the SQL server engages in processes >>> which may lock >>>>>>>>> the db, or delay response in some way. >>>>>>>>> >>>>>>>>> Again- (and hopefully someone will listen this time) the >>>>>>>> concern speaks >>>>>>>>> to >>>>>>>>> the "real world" usability of "lockdown mode" within the >>>>>>>> enterprise. If >>>>>>>>> Microsoft intends to tout the lockdown feature of ISA >>> as a tool >>>>>>>>> enterprise clients can use to ensure evidentiary >>> integrity, then >>>>>>>>> you >>>>>>>> must address >>>>>>>>> the >>>>>>>>> mode's "survivability" during standard, everyday, >>>>>>>> real-world processes >>>>>>>>> that >>>>>>>>> must be run on the SQL servers the ISA box is logging to, >>>>>> or it will >>>>>>>>> simply >>>>>>>>> not be used. This relates to processes that may or >>> may not have >>>>>>>>> anything to do with the log files themselves. >>>>>>>>> >>>>>>>>> If nobody cares if lockdown is utilized in the >>>>>> enterprise, then this >>>>>>>>> thread >>>>>>>>> is done. If, however, the goal is supply enterprise >>>>>> customers with a >>>>>>>>> lockdown mode they can use, then user-defined connection >>>>>>>> parameters must >>>>>>>>> be >>>>>>>>> provided in order to customize the lockdown threshold to our >>>>>>>>> environments. >>>>>>>>> >>>>>>>>> T >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/9/06 9:28 AM, "Jim Harrison (ISA)" >>>>>> <Jim.Harrison@xxxxxxxxxxxxx> >>>>>>>>> spoketh >>>>>>>>> to all: >>>>>>>>> >>>>>>>>>> It may help in the short run, but the issue Tim raises >>>>>>>> isn't so much >>>>>>>>>> "how much data is being logged", but "how long ISA will >>>>>>>> wait while the >>>>>>>>>> logging process fails to respond before it raises an >>>>>> alert" and "I >>>>>>>>> wanna >>>>>>>>>> set this trigger point". >>>>>>>>>> >>>>>>>>>> What he's asking for (as have more than a few customers) >>>>>>>> is some way >>>>>>>>> for >>>>>>>>>> the user to specify a "almost choking on my own data" >>>>>>>> alert limit that >>>>>>>>>> could be used to move ISA logging to an alternate >>>>>> destination (SQL, >>>>>>>>>> file, bitbucket) until the primary logger responds once >>>>>>>> more. What we >>>>>>>>>> have now is a "choked on my own data" alert, which is a >>>>>>>> bit too late. >>>>>>>>>> >>>>>>>>>> In fact, I've seen one unfavorable comparison to >>>>>> <product deleted> >>>>>>>>> where >>>>>>>>>> they actually: >>>>>>>>>> 1. fail over to a backup logging process 2. monitor >>> the primary >>>>>>>>>> logger 3. fail back when the primary logger >>> reappears 4. import >>>>>>>>>> the alternate-store log data into the primary >>>>>> store as a >>>>>>>>>> low-pri part of the fail-back. >>>>>>>>>> >>>>>>>>>> Techincally, this is scriptable, except for the fact >>>>>> that our alert >>>>>>>>>> happens too late (and isn't "tweakable"). If one were >>>> willing to >>>>>>>>>> tolerate the momentary traffic block that's created today, >>>>>>>> a script is >>>>>>>>> a >>>>>>>>>> workable solution (except for the "pre-panic" factor). >>>>>>>>>> >>>>>>>>>> Jim Harrison >>>>>>>>>> SASD (ISA SE) >>>>>>>>>> If We Can't Fix It - It Ain't Broke! >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] >>>>>>>>>> [mailto:sbradcpa@xxxxxxxxxxx] >>>>>>>>>> Sent: Sunday, July 09, 2006 2:22 AM >>>>>>>>>> To: isaserver@xxxxxxxxxxxxxxx >>>>>>>>>> Cc: Avi Sander; Adar Greenshpon; Nathan Bigman >>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>> due to power >>>>>>>>>> outtage >>>>>>>>>> >>>>>>>>>> Shouldn't depadding not cause the system to freak out >>>> and go into >>>>>>>>>> lockdown? That's his real point.. not necessarily the >>>>>>>> fact he has to >>>>>>>>> do >>>>>>>>>> >>>>>>>>>> it..but the fact that ISA is there locking itself down in >>>>>>>> the process >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> Thor (Hammer of God) wrote: >>>>>>>>>> >>>>>>>>>>> Never mind. Not sure why I bother... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> t >>>>>>>>>>> >>>>>>>>>>> On 7/9/06 12:01 AM, "Avi Sander" <asander@xxxxxxxxxxxxx> >>>>>>>> spoketh to >>>>>>>>>> all: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Thor - >>>>>>>>>>>> >>>>>>>>>>>> Please see >>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlr >>>>>>>>>> ef >>>>>>>>>>>> /ts_set-set_2uw7.asp . >>>>>>>>>>>> >>>>>>>>>>>> It describes how one can toggle the ANSI_PADDING >>>>>> option. This can >>>>>>>>>>>> control how fields are padded\trimmed in SQL, but >>>> should be set >>>>>>>>> prior >>>>>>>>>> to >>>>>>>>>>>> tbl creation. >>>>>>>>>>>> >>>>>>>>>>>> - avi >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> Sent: Friday, July 07, 2006 6:23 PM >>>>>>>>>>>> To: Avi Sander; Adar Greenshpon; ISA-MVP >>>>>>>>>>>> Cc: Nathan Bigman >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> I think we're getting off track a little here... >>>>>>>>>>>> >>>>>>>>>>>> I appreciate the link to that "fix," but I've *already >>>>>>>> solved* the >>>>>>>>>>>> padding >>>>>>>>>>>> issue. I've been including a script for that in >>> my Blackhat >>>>>>>>> trainings >>>>>>>>>>>> for >>>>>>>>>>>> years. To that effect, simply trimming the data in >>>> the default >>>>>>>>> table >>>>>>>>>>>> isn't >>>>>>>>>>>> the best way to go, IMO. The data structure is not very >>>>>>>> efficient >>>>>>>>> to >>>>>>>>>>>> begin >>>>>>>>>>>> with (for my needs). I've created my own (better designed) >>>>>>>>> structure, >>>>>>>>>>>> and >>>>>>>>>>>> trim the data as I post into that table (and there is no >>>>>>>> "trim data" >>>>>>>>>> DSN >>>>>>>>>>>> option that I know of). But that's OK-- as an >>>> administrator, I >>>>>>>>>> *expect* >>>>>>>>>>>> that I will have to adjust logging processes to better >>>>>>>> fit my needs >>>>>>>>>>>> (just >>>>>>>>>>>> like I do with IIS logs that I post to SQL). You guys >>>>>> provide the >>>>>>>>>>>> mechanism, >>>>>>>>>>>> and I customize it to suit me. Like I said, my yearly >>>>>>>> retained data >>>>>>>>> to >>>>>>>>>>>> date >>>>>>>>>>>> is only 10 gig. No problems. >>>>>>>>>>>> >>>>>>>>>>>> What I'm saying is that *when I run the process to >>>>>> trim the data* >>>>>>>>> ISA >>>>>>>>>>>> goes >>>>>>>>>>>> into "lockdown." This whole thing got started when we >>>>>>>> were talking >>>>>>>>>>>> about >>>>>>>>>>>> lockdown mode, and how "trigger happy" it is when one is >>>>>>>> logging to >>>>>>>>>> SQL. >>>>>>>>>>>> >>>>>>>>>>>> I only brought it up in an effort to identify this: >>>>>>>>>>>> If a customer logs to SQL, there is a padding problem. >>>>>>>> The padding >>>>>>>>>>>> problem >>>>>>>>>>>> *requires* DB maintenance processes to control. >>> When the DB >>>>>>>>>> maintenance >>>>>>>>>>>> is >>>>>>>>>>>> executed against any DB of consequence (just >>> several thousand >>>>>>>>> records >>>>>>>>>>>> seems >>>>>>>>>>>> to be enough), ISA goes into lockdown, presumably >>>>>> because of the >>>>>>>>> "lag" >>>>>>>>>>>> created by server load when the SQL server goes about >>>>>> parsing out >>>>>>>>> gigs >>>>>>>>>>>> of >>>>>>>>>>>> fluff data. This is true even on my production SQL >>>>>>>> cluster (which >>>>>>>>> is >>>>>>>>>>>> kickass, mind you ;) so it's not a "hardware" problem. >>>>>>>> Thus, I was >>>>>>>>>>>> forced >>>>>>>>>>>> to disable lockdown. >>>>>>>>>>>> >>>>>>>>>>>> Therefore, IF a customer is logging to SQL, AND >>> they want use >>>>>>>>>> "lockdown" >>>>>>>>>>>> THEN better user-definable timeout parameters need to be >>>>>>>> available. >>>>>>>>>>>> That's >>>>>>>>>>>> all I was saying. >>>>>>>>>>>> >>>>>>>>>>>> Of course, since you have identified that ISA2004 EE, >>>>>> ISA2006 SE, >>>>>>>>> and >>>>>>>>>>>> ISA2006 EE properly trim data before posting it to SQL, >>>>>>>> then it all >>>>>>>>>>>> seems to >>>>>>>>>>>> be a moot point, right? ;) >>>>>>>>>>>> >>>>>>>>>>>> The main box posting web access is currently ISA 2004 >>>>>> SE. But I >>>>>>>>> think >>>>>>>>>>>> I've >>>>>>>>>>>> got a copy of ISA 2004 EE that I picked up in Hong Kong >>>>>>>> along with >>>>>>>>> an >>>>>>>>>>>> old >>>>>>>>>>>> Rush CD that I'll throw on that guy and see what >>>>>>>> happens. (jk;) I'll >>>>>>>>>> let >>>>>>>>>>>> you >>>>>>>>>>>> guys know what happens. >>>>>>>>>>>> >>>>>>>>>>>> Thx >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/7/06 12:29 AM, "Avi Sander" <asander@xxxxxxxxxxxxx> >>>>>>>> spoketh to >>>>>>>>>> all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> there's also an option on the ODBC DSN : 'trim >>> fields' that >>>>>>>>> partially >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> helps, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> if i recall correctly. >>>>>>>>>>>> I'll look into this further >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> From: Adar Greenshpon >>>>>>>>>>>> Sent: Fri 07/07/2006 09:07 >>>>>>>>>>>> To: Avi Sander; Thor (Hammer of God); >>>>>> isaserver@xxxxxxxxxxxxxxx >>>>>>>>>>>> Cc: Nathan Bigman >>>>>>>>>>>> Subject: RE: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thor, >>>>>>>>>>>> >>>>>>>>>>>> Per the excessive padding, see this thread: >>>>>>>>>>>> http://forums.isaserver.org/m_140009200/tm.htm - I >>>>>> think that's >>>>>>>>> what >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you're >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> looking for as we already heard this a few times (as >>>>>> Avi pointed >>>>>>>>> out, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> problem does not exist in ISA 2004EE or ISA 2006 >>>>>>>> versions). Nathan >>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> will an >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> official KB help here? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adar. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> From: Avi Sander >>>>>>>>>>>> Sent: Friday, July 07, 2006 12:27 AM >>>>>>>>>>>> To: Thor (Hammer of God) >>>>>>>>>>>> Cc: Adar Greenshpon >>>>>>>>>>>> Subject: RE: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK - that explains it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a known SQL ODBC interfacing issue. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ISA 2004 EE and ISA2006 SE & EE moved away from ODBC >>>>>>>> and use oledb >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> interfaces >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for SQL server logging instead. This issue does not >>>>>> exist there >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> anymore as it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> is all trimmed by design (and throughput is also greatly >>>>>>>>> increased). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The 2 potential causes of errors i mentioned earlier in >>>>>>>> the thread >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (buffers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> full, 4 retries) are only relevant to the OLEDB >>>>>>>> logging, and not to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> your ISA - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> my bad. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> let me check with the ISA2004 SE code and get back to >>>>>> you with a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> better >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> picture... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -avi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> Sent: Thu 06/07/2006 23:12 >>>>>>>>>>>> To: Avi Sander >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These are ISA2004 SE boxes. I haven't tried with >>>>>>>> ISA2006 yet, but >>>>>>>>>> I'm >>>>>>>>>>>> running it here at The Yeti and can check it out >>> (unless you >>>>>>>>> already >>>>>>>>>>>> know...) >>>>>>>>>>>> >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/6/06 2:08 PM, "Avi Sander" <asander@xxxxxxxxxxxxx> >>>>>>>> spoketh to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hey Thor - >>>>>>>>>>>> >>>>>>>>>>>> What ISA version are you using? and whichSKU: SE or EE? >>>>>>>>>>>> >>>>>>>>>>>> -avi >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> Sent: Thu 06/07/2006 18:39 >>>>>>>>>>>> To: Adar Greenshpon; ISA-MVP; Avi Sander >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Adar- >>>>>>>>>>>> >>>>>>>>>>>> Yes, logs going to an external SQL 2000 cluster via >>>>>>>> direct gigabit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> switched >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> link. And log retention is permanent. Though I've >>>>>>>> only got 120 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> employees, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we >>>>>>>>>>>> have tight policies on Internet usage and abuse and I, >>>>>>>> like many, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> must keep >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> access logs to ensure these policies are being >>>>>>>> honored, as well as >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for any >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> number of potential legal issues that might arise. I >>>>>>>> trust that >>>>>>>>> you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> are not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> suggesting that ISA log retention via SQL should be >>>>>> measured in >>>>>>>>>> days, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> right? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ;) >>>>>>>>>>>> >>>>>>>>>>>> Let me go into more detail about the "fluff" I >>>>>> mentioned- it is >>>>>>>>> not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> so much >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the "gigs of logs" as it would relate to real data- it >>>>>>>> is actual >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "fluff:" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Extra, padded spacing in the fields posted to >>> SQL from ISA. >>>>>>>>> Though >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you guys >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> have defined the fields in SQL as nvarchar data, there >>>>>>>> is some bad >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mojo in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> logging process. Cursory review of the data in >>>>>>>> something like SQL >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Query >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Analyzer may not immediately reveal this, but binary >>>>>> analyze of >>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> data >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> files >>>>>>>>>>>> do. >>>>>>>>>>>> >>>>>>>>>>>> I've created some example text files to simplify what >>>>>>>> I am talking >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> about >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (Attached as SQL1.txt and SQL2.txt). >>>>>>>>>>>> >>>>>>>>>>>> Consider the following simple query to retrieve a >>>>>> single row of >>>>>>>>>> basic >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> data >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> from the WebProxyLog as stored by ISA: >>>>>>>>>>>> >>>>>>>>>>>> "select >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>> >>>> ClientUserName,ClientAgent,DestHost,DestHostIP,SrcNetwork,DstNetwork >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> from WebProxyLog where LogID=10133541" >>>>>>>>>>>> >>>>>>>>>>>> (SQL1.txt contains the results, but I'll paste them >>>>>>>> here as well) >>>>>>>>>>>> <begin paste> >>>>>>>>>>>> ANCHORSIGN\yomomma >>>>>>>>>>>> PGP >>>>>>>>>>>> update.pgp.com >>>>>>>>>>>> 63.251.255.18 VPN Clients >>>>>>>>>>>> External >>>>>>>>>>>> >>>>>>>>>>>> </end paste> >>>>>>>>>>>> >>>>>>>>>>>> Notice all the extra spacing; again, even though the >>>>>> fields are >>>>>>>>> type >>>>>>>>>>>> nvarchar-- ISA is padding the data. Now, let's trim >>>>>>>> it up and see >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> what >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> happens in this query: >>>>>>>>>>>> >>>>>>>>>>>> "select >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> rtrim(ClientUserName),rtrim(ClientAgent),rtrim(DestHost),rtrim(DestHos >>>>>>>>>> tI >>>>>>>>>>>> P),rt>> >>>>>>>>>>>> r >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> im(SrcNetwork),rtrim(DstNetwork) from WebProxyLog where >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> LogID=10133541" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (SQL2.txt contains the results, but again I'll >>> paste them) >>>>>>>>>>>> <begin paste> >>>>>>>>>>>> ANCHORSIGN\yomomma PGP update.pgp.com >>>> 63.251.255.18 >>>>>>>>> VPN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Clients >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> External >>>>>>>>>>>> </end paste> >>>>>>>>>>>> >>>>>>>>>>>> The original query results are 934 bytes. The >>>> trimmed query >>>>>>>>> results >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> are 74 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> bytes. Just for this simple query, with selected >>>>>>>> fields from one >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> record, the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> storage requirements for this data is 12.62 times >>>>>>>> greater due to >>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "fluff." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Extend that out to a full logged record, and then >>>>>> multiply that >>>>>>>>>> times >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> tens of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> thousands. *THIS* is the 1-2 gigs of "fluff" I'm >>>>>>>> talking about on >>>>>>>>> a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *daily* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> basis. >>>>>>>>>>>> >>>>>>>>>>>> The "required maintenance" I'm talking about is where >>>>>>>> I take daily >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> raw data >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> from the WebProxyLog, trim it up, and then post it >>>>>> into my own >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> tables. In my >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> case, the _yearly_ web proxy log data for my users is >>>>>>>> only 10 gig. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _Weekly_ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "raw" data in the original ISA log format averages 12 >>>>>>>> gig. When >>>>>>>>> I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> run this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> process, I am able to retrieve data via SQA, Access >>>>>>>> front end, or >>>>>>>>>> via >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ADODB >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> objects, yet ISA will go into lockdown mode while >>>>>> logging when >>>>>>>>> this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> job runs >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at night. That's why I have to turn it off. >>>>>>>>>>>> >>>>>>>>>>>> I hope that better defines the issue as I see it. >>>>>>>>>>>> >>>>>>>>>>>> Thanksl >>>>>>>>>>>> T >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> "Tom Shinder pities Mr. T" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/5/06 2:01 AM, "Adar Greenshpon" >>>>>>>>> <Adar.Greenshpon@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> spoketh >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Thor, >>>>>>>>>>>> >>>>>>>>>>>> Just so we'll be on the same page: are you directing >>>>>>>> your ISA logs >>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> an >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> external machine with SQL Server (SQL 2000 or 2005)?. >>>>>>>> If so, how >>>>>>>>> do >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you do >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the maintenance? What's your desired log retention >>>>>>>> policy (e.g. 7 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> days)? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Per the gigs of logs you're doing, have you considered >>>>>>>> reducing it >>>>>>>>>> by >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> logging images http requests? >>>>>>>>>>>> Adar. >>>>>>>>>>>> __________________________________________ >>>>>>>>>>>> Adar Greenshpon | Program Manager | Microsoft ISA Server >>>>>>>>>>>> adarg@xxxxxxxxxxxxx <mailto:adarg@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <mailto:adarg@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> | Tel: +972.4.856.1077 | SMS/Cell: +972.54.666.4579 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> Sent: Tuesday, July 04, 2006 8:55 PM >>>>>>>>>>>> To: Avi Sander >>>>>>>>>>>> Cc: Adar Greenshpon; ISA-MVP >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK- the either/or situation makes more sense. I'm >>>>>>>> sure that I'm >>>>>>>>>> not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> hitting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the log buffer- the 9 second minimum window is what is >>>>>>>> getting me. >>>>>>>>>>>> >>>>>>>>>>>> How exactly do you define a "failure to commit?" Are >>>>>>>> you actively >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> looking >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for >>>>>>>>>>>> a "failure" code from SQL, or is it the lack of >>> a committed >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> transaction >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> within >>>>>>>>>>>> the time span? I ask because if I am in the middle of DB >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> maintenance, I can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> execute a transaction that might have to wait a >>>>>> while to get a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> committal, but >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> SQL knows about the transaction pending and won't >>>> error out. >>>>>>>>>>>> >>>>>>>>>>>> The SQL table structure included in 2004 results in >>>>>> HUGE table >>>>>>>>> sizes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for web >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> proxy logging alone. I'm talking gigs worth of fluff >>>>>>>> per day, so >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> daily DB >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> maintenance is an absolute requirement. I have >>> never had a >>>>>>>>> logging >>>>>>>>>>>> transaction "live" through a maintenance period >>>>>>>> without going into >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> lockdown, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> hence it being disabled on all my web proxy listener >>>>>> machines. >>>>>>>>>>>> >>>>>>>>>>>> I understand that the reasoning behind "lockdown" is for >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "evidentiary" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> reasons, but that seems counter intuitive to me. The >>>>>>>> actual log >>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> more >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> important to me than the absence of a logged event >>>>>>>> when the system >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> locks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> down. >>>>>>>>>>>> So, not only are the services not available (though a >>>>>>>>> "fail-safe"), >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> but I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> loose any log of any attempt in the meantime. Are we >>>>>>>> going to see >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> some more >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "user definable" setting in regard to logging and >>>>>> lockdown? If >>>>>>>>> not, >>>>>>>>>> I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> don't >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> see how even mid-size businesses will be able to >>> log to SQL >>>>>>>>> without >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> disabling >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the feature. >>>>>>>>>>>> >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/4/06 5:51 AM, "Avi Sander" >>>>>>>> <asander@xxxxxxxxxxxxx> spoketh to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ISA will lockdown if either of the following occurs >>>>>> (whichever >>>>>>>>> comes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1st): >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - Four consecutive failures to commit the >>>>>> data into the >>>>>>>>> DB. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Our >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> default COMMIT timeout is 30 secs. We'll retry every 3 >>>>>>>> secs. So at >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> minimum >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you've got 9 secs here. >>>>>>>>>>>> - LOG buffers are exhausted\out of memory. By >>>>>>>> default on a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1GB RAM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> machine we'll accumulate tens of thousands of recs. Is >>>>>>>> there a lot >>>>>>>>>> of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> traffic >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> going through when this happens? How much RAM does >>>>>> this machine >>>>>>>>>> have? >>>>>>>>>>>> >>>>>>>>>>>> What is the event description you see in the EventViewer? >>>>>>>>>>>> >>>>>>>>>>>> The Log buffers can be extended some more, though not >>>>>>>> recommended >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> since can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> use up a lot of memory. >>>>>>>>>>>> >>>>>>>>>>>> -avi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ________________________________ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From: Adar Greenshpon >>>>>>>>>>>> Sent: Tuesday, July 04, 2006 2:03 PM >>>>>>>>>>>> To: isaserver@xxxxxxxxxxxxxxx >>>>>>>>>>>> Cc: Avi Sander >>>>>>>>>>>> Subject: RE: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Avi - wanna play logging diva? >>>>>>>>>>>> Generally speaking, there are four internal commit >>>>>>>> retries until >>>>>>>>> ISA >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> enters >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> lockdown. We have seen a few thousand log records in >>>>>>>> the buffers >>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> these >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> temporary moments in our stress labs (nothing you >>>>>> could really >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> witness on a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> normal SBS box though). >>>>>>>>>>>> >>>>>>>>>>>> Adar. >>>>>>>>>>>> __________________________________________ >>>>>>>>>>>> Adar Greenshpon | Program Manager | Microsoft ISA Server >>>>>>>>>>>> adarg@xxxxxxxxxxxxx <mailto:adarg@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <mailto:adarg@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> | Tel: +972.4.856.1077 | SMS/Cell: +972.54.666.4579 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>>>>>> Sent: Wednesday, June 28, 2006 8:26 PM >>>>>>>>>>>> To: ISA-MVP >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If that is what you guys are expecting to happen, I >>>>>>>> can tell you, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *ain't* the case - not when logging to SQL on another >>>>>>>> box, anyway. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There's >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no "using as much memory as it can" going on. It >>>>>>>> seems to be more >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> like "I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> did not get an acknowledgement that the last >>>> transaction was >>>>>>>>>> written, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> it's been 2 seconds, so I'm going into lockdown." >>>>>>>>>>>> >>>>>>>>>>>> I'm looking forward to what info you can get from >>>>>> your "logging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> diva." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 6/28/06 8:43 AM, "Jim Harrison (ISA)" >>>>>>>>>> <Jim.Harrison@xxxxxxxxxxxxx> >>>>>>>>>>>> spoketh to all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually, it's not a fixed value (or >>>>>>>> user-changeable), other than >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> being >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> self-regulating. >>>>>>>>>>>> ISA logging will use as much memory as it can until >>>>>>>> it determines >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> growth is unchecked. Thus, how quickly ISA will cry >>>>>>>> foul depends >>>>>>>>>> in >>>>>>>>>>>> part on how much free memory is available. >>>>>>>>>>>> >>>>>>>>>>>> I'll ask our logging diva for details, but this sums >>>>>>>> it up pretty >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jim Harrison >>>>>>>>>>>> SASD (ISA SE) >>>>>>>>>>>> If We Can't Fix It - It Ain't Broke! >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>>>>>> Sent: Wednesday, June 28, 2006 8:09 AM >>>>>>>>>>>> To: ISA-MVP >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database >>>> corruption due to >>>>>>>>> power >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> It must be about a 1k buffer, then. I repeatedly >>>> put ISA in >>>>>>>>>> lockdown >>>>>>>>>>>> within >>>>>>>>>>>> seconds of maintenance jobs being run, or other "data >>>>>>>> intensive" >>>>>>>>>>>> operations >>>>>>>>>>>> on the DB. I would start the job, in in a few >>>> seconds, get >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> disconnected >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> form my TS session because of it-- It wasn't a "one >>>>>>>> time" thing- >>>>>>>>> it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> consistent and repeatable. That's the only reason I >>>>>> went ahead >>>>>>>>> and >>>>>>>>>>>> disabled >>>>>>>>>>>> lockdown. >>>>>>>>>>>> >>>>>>>>>>>> Is the buffer user definable somewhere? What exactly >>>>>>>> does your >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> script >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> do? >>>>>>>>>>>> >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 6/28/06 7:54 AM, "Jim Harrison (ISA)" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <Jim.Harrison@xxxxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> spoketh to all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually, that's not true; ISA doesn't go into >>>>>> lockdown until >>>>>>>>> the >>>>>>>>>>>> logging buffer is filled. >>>>>>>>>>>> I agree that a "backup logging" concept is useful. >>>>>>>>>>>> I have a script that works for ISA 2000; it >>> shouldn't be >>>>>>>>> difficult >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "agnosticize" it. >>>>>>>>>>>> >>>>>>>>>>>> Jim Harrison >>>>>>>>>>>> Security Platform Group (ISA SE) >>>>>>>>>>>> >>>>>>>>>>>> If We Can't Fix It - It Ain't Broke! >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Thor (Hammer of God) >>> [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>>> <mailto:thor@xxxxxxxxxxxxxxx%5d> >>>>>>>>>>>> Sent: Wednesday, June 28, 2006 7:34 AM >>>>>>>>>>>> To: ISA-MVP >>>>>>>>>>>> Subject: Re: [ISAServer] Firewall database >>>>>> corruption due to >>>>>>>>> power >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> I'd like to see some way to at least "buffer" >>> the logging >>>>>>>>> requests >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> when >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> logging to an off-box ODBC destination, like SQL. >>>>>>>> ISA is quite >>>>>>>>>>>> intolerant >>>>>>>>>>>> of even the slightest interruption in logging. >>>>>> But, I guess >>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> makes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sense if the goal is to have "evidentiary credibility." >>>>>>>>>>>> >>>>>>>>>>>> It wouldn't have to be something l337 like a >>>>>> secondary local >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> logging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> option >>>>>>>>>>>> or anything like that-- I think being able to >>>> set a timeout >>>>>>>>> value >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> would >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> would. With larger db's, a maintenance job >>>> would kick the >>>>>>>>> server >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> into >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> lockdown, even though the SQL service is still >>> running... >>>>>>>>>>>> >>>>>>>>>>>> Jim, I know you wanted me to get my infrastructure >>>>>>>> layout to you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> again >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for >>>>>>>>>>>> my solution to the SQL db size problems, but I >>>>>> haven't had a >>>>>>>>>> chance >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> find >>>>>>>>>>>> that old email. I should just re-create it ;) >>>>>>>> Regardless, even >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> that >>>>>>>>>>>> "solution" in place, I've had to disable >>>> lockdown mode when >>>>>>>>>> logging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> SQL >>>>>>>>>>>> for that very reason. >>>>>>>>>>>> >>>>>>>>>>>> t >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 6/28/06 7:19 AM, "Thomas W Shinder" >>>>>> <tshinder@xxxxxxxxxxx> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> spoketh >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> all: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> And it's a really good security and forensics decision. >>>>>>>>>>>> >>>>>>>>>>>> Thomas W Shinder, M.D. >>>>>>>>>>>> Site: www.isaserver.org >>>>>>>>>>>> Blog: http://blogs.isaserver.org/shinder/ >>>>>>>>>>>> Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Amy Babinchak >>>>>> [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx] >>>>>>>>>>>> <mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx%5d> >>>>>>>>>>>> <mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx%5d> >>>>>>>>>>>> Sent: Wednesday, June 28, 2006 6:28 AM >>>>>>>>>>>> To: isaserver@xxxxxxxxxxxxxxx >>>>>>>>>>>> Subject: RE: [ISAServer] Firewall database >>>>>>>> corruption due to >>>>>>>>>>>> power outtage >>>>>>>>>>>> >>>>>>>>>>>> I like that ISA shuts down if it can't log. It's >>>>>>>> an indicator >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> something has gone wrong. >>>>>>>>>>>> >>>>>>>>>>>> Amy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] >>>>>>>>>>>> [mailto:sbradcpa@xxxxxxxxxxx] >>>>>>>> <mailto:sbradcpa@xxxxxxxxxxx%5d> >>>>>>>>>>>> <mailto:sbradcpa@xxxxxxxxxxx%5d> >>>>>>>>>>>> Sent: Wednesday, June 28, 2006 12:12 AM >>>>>>>>>>>> To: isaserver@xxxxxxxxxxxxxxx >>>>>>>>>>>> Subject: [ISAServer] Firewall database corruption >>>>>>>> due to power >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> outtage >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> With the caveat that we all know we need a good >>>>>>>> UPS but like >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> stuff >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> happens.. I've seen two folks recently have issues >>>>>>>> getting a >>>>>>>>>>>> server back >>>>>>>>>>>> >>>>>>>>>>>> up have a 'dirty shutdown' due to power outtage >>>>>>>> that ended up >>>>>>>>>>>> corrupting >>>>>>>>>>>> >>>>>>>>>>>> the ISA firewall database. >>>>>>>>>>>> >>>>>>>>>>>> Short of uninstalling and reinstalling... short of >>>>>>>> adjusting >>>>>>>>>>>> ISA so it >>>>>>>>>>>> won't shut down if it can't log... short of a >>>>>> better UPS... >>>>>>>>> any >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> other >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> recommendations on handling this better? >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in LEAVE >>>>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in LEAVE >>>>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in LEAVE >>>>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in LEAVE >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in LEAVE >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In >>>>>>>>>>>> the subject line put in LEAVE >>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In >>>>>>>>>>>> the subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In >>>>>>>>>>>> the subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> To subscribe to the list - send an email to >>>>>>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>>> In the subject line put in JOIN >>> isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In >>>>>>>>>>>> the subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> youremailaddress >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Don't forget the comma! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> To subscribe to the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>>> In the subject line put in JOIN isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>> youremailaddress >>>>>>>>>>> >>>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In the >>>>>>>>>>> subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>> youremailaddress >>>>>>>>>>> >>>>>>>>>>> Don't forget the comma! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> To subscribe to the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>> In the subject line put in JOIN isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>> youremailaddress >>>>>>>>>> >>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In the >>>>>>>>>> subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>>> youremailaddress >>>>>>>>>> >>>>>>>>>> Don't forget the comma! >>>>>>>>>> --- >>>>>>>>>> To subscribe to the list - send an email to >>>> list@xxxxxxxxxxxxxxx >>>>>>>>>> In the subject line put in JOIN isaserver@xxxxxxxxxxxxxxx, >>>>>>>>> youremailaddress >>>>>>>>>> >>>>>>>>>> To leave the list - send an email to >>>> list@xxxxxxxxxxxxxxx In the >>>>>>>>>> subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>>> youremailaddress >>>>>>>>>> >>>>>>>>>> Don't forget the comma! >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> To subscribe to the list - send an email to >>>> list@xxxxxxxxxxxxxxx In >>>>>>>> the subject line put in JOIN isaserver@xxxxxxxxxxxxxxx, >>>>>>>> youremailaddress >>>>>>>> >>>>>>>> To leave the list - send an email to >>> list@xxxxxxxxxxxxxxx In the >>>>>>>> subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>> youremailaddress >>>>>>>> >>>>>>>> Don't forget the comma! >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> All mail to and from this domain is GFI-scanned. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> All mail to and from this domain is GFI-scanned. >>> >>> >>> >> >> >> > > > > > All mail to and from this domain is GFI-scanned. > > > >