[isapros] Re: [ISAServer] Firewall database corruption due to power outtage
- From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
- To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
- Date: Mon, 10 Jul 2006 15:02:07 -0700
How about get out your "disable PING via the FWC on ISA2004" tools first?
:-p
t
On 7/10/06 2:42 PM, "Jim Harrison" <Jim@xxxxxxxxxxxx> spoketh to all:
> 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:
