[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 10:32:59 -0700

You're going this on purpose, aren't you?




On 7/10/06 9:19 AM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> spoketh to
all:

> 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.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 
> 



Other related posts: