[isapros] Re: [ISAServer] Firewall database corruption due to power outtage
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 10 Jul 2006 14:42:13 -0700
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.
Other related posts:
