'err Jim, There's only one of them!!! like Hello! :) > Wait; lemme get my 2-M tools... > > > ------------------------------------------------------- > 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 14:35 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: [ISAServer] Firewall database corruption due to > power outtage > > 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. >> >> >> >> > > > > > All mail to and from this domain is GFI-scanned. > > >