Saturday, June 28, 2008

New article posted

I finally finished the Interview of Lt. Cdr. Cobb, the CO of Patrol Squadron 91 during the Solomons Island campaign. I had started it before my trip to San Bruno and had it done except for the final proofreading, but the San Francisco damage report grabbed my focus for a bit.

Next up will be to finish the SF damage report.

Tuesday, June 24, 2008

iTunes sucks

Let me add my voice to those hate iTunes... a safari update came down and I applied it 'cause I check my site for compatibility. Keep in mind this was a safari web browser update only.

After that I went to play some music and the update had set iTunes as my default player.

A big "fuck you" to Apple for trying to slip Safari in like spyware in the first place and then pulling crap like this. It's about time you "think different" youself.

Wednesday, June 18, 2008

Exchange 2007 Disk Thresholds

First computer post....

This hit us at the office today, internal and outgoing mail was working fine but incoming was not reaching us. No bounce backs, no queues showing messages; it was just.... quiet. There were a couple of patches outstanding from last week and I figured, there was probably some minor exchange glitch that a reboot would fix (the app log looked pretty clean).

So I let it apply the outstanding patches, and in the process it bounced the exchange services and we started getting mail again. However, after system reboot we were back to square one. So I went digging around a bit more and determined that we had just under a gig of free space on the C:\. Usually when an exchange server hard drive fills up I go through and look at the directory exchange writes logs to, which in this case was C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group.

We had what I will call a heroic amount of log files there; roughly 14 gigs worth. I love the lack of Exchange 2007 support on our Sonicwall CDP...

Best way to clear these out that I've seen on systems without backup software such as Symantec's Backup Exec is to run a system state and exchange backup with NTbackup; in the process of running the backup it'll flush the logs for you. There are two caveats to this, first, you need sufficient space SOMEWHERE on the network to write the backup, and two, NTbackup has been severely gutted in Server 2008 and you may be up a creek if you're running Server 2008 and Exchange 2007.

While I was waiting for the backup to process, I went through the logs again and found some entries in the app log describing the problem.

First we got:





Event Type: Warning
Event Source: MSExchangeTransport
Event Category: ResourceManager
Event ID: 15004
Date: 6/17/2008
Time: 3:09:31 PM
User: N/A
Computer: MERLOT
Description:
Resource pressure increased from Normal to Medium.

Resource utilization of the following resources exceed
the normal level: Queue database logging disk
space ("C:\Program Files\Microsoft\Exchange Server\
TransportRoles\data\Queue\") = 96% [Medium] [Normal=94%
Medium=96% High=98%] Physical memory load = 92% [limit
is 94% before message dehydration occurs.]

Back pressure caused the following components to be disabled:
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory

The following resources are in the normal state:
Queue database and disk space ("C:\Program Files\
Microsoft\Exchange Server\TransportRoles\data\
Queue\mail.que") = 95% [Normal] [Normal=94% Medium=96%
High=98%]
Version buckets = 0 [Normal] [Normal=40 Medium=60 High=100]
Private bytes = 14% [Normal] [Normal=71% Medium=73% High=75%]



Followed immediately by:





Event Type: Error
Event Source: MSExchangeTransport
Event Category: ResourceManager
Event ID: 15006
Date: 6/18/2008
Time: 10:53:54 AM
User: N/A
Computer: MERLOT
Description:
The Microsoft Exchange Transport service is rejecting
message submissions because the available disk space has
dropped below the configured threshold.

Resource utilization of the following resources exceed
the normal level:
Queue database logging disk space ("C:\Program Files\
Microsoft\Exchange Server\TransportRoles\data\Queue\")
= 96% [Medium] [Normal=94% Medium=96% High=98%]

No components were disabled because of back pressure.
The following resources are in the normal state:
Queue database and disk space ("C:\Program Files\Microsoft\
Exchange Server\TransportRoles\data\Queue\mail.que") = 95%
[Normal] [Normal=94% Medium=96% High=98%]
Version buckets = 0 [Normal] [Normal=40 Medium=60 High=100]
Private bytes = 0% [Normal] [Normal=71% Medium=73% High=75%]
Physical memory load = 37% [limit is 94% before message
dehydration occurs.]



When service was restored the app log wrote:



Event Type: Information
Event Source: MSExchangeTransport
Event Category: ResourceManager
Event ID: 15005
Date: 6/18/2008
Time: 11:22:55 AM
User: N/A
Computer: MERLOT
Description:
Resource pressure decreased from Medium to Normal.

No components were disabled because of back pressure.
The following resources are in the normal state:
Queue database and disk space ("C:\Program Files\
Microsoft\Exchange Server\TransportRoles\data\Queue\
mail.que") = 90% [Normal] [Normal=94% Medium=96% High=98%]
Queue database logging disk space ("C:\Program Files\
Microsoft\Exchange Server\TransportRoles\data\Queue\")
= 91% [Normal] [Normal=94% Medium=96% High=98%]
Version buckets = 0 [Normal] [Normal=40 Medium=60 High=100]
Private bytes = 10% [Normal] [Normal=71% Medium=73% High=75%]
Physical memory load = 62% [limit is 94% before message
dehydration occurs.]



Technet has nothing on this error at this point and our monitoring software, HyBlue didn't catch it, albeit I am DEFINITELY sending them a note! I thought I'd pop a note out there for others who might run into his error; it's a pretty easy fix, just free up some drive space or set your threshold down lower and risk filling your hard drive completely. Haven't found any documentation on HOW to do that yet, personally I think it's better to watch your free space and make sure those logs get cleared out!

Monday, June 16, 2008

Finally got more time

It's been busy at work the last week and I needed to catch up on some stuff for Admiralty Modelworks so I haven't had a chance to work on the San Francisco CA-38 Battle Damage Report. I had a little bit of "hurry up and wait" time at a client's today and got three more pages done.. ten left to go, average of 2 photos a page, then three damage plates to stitch together... then comes the great proofreading and it's ready for the world!

Thursday, June 12, 2008

Important Question!

Or at least a tactical flaw....

With the upcoming release of a new Incredible Hulk movie convenience store chain 7-11 has been running commercials for their Special Hulk Slurpees. I heard one yesterday on the radio that featured a psychologist "talking" to Hulk and trying to calm him down with a Slurpee... but it strick me, isn't this a VERY bad move on her part?

I mean, what would happen if Hulk got brain freeze?

Wednesday, June 11, 2008

What matters in History

As a model builder, I take keen interest in details. As someone who researches events and hardware, I am also concerned with the details of an event.

But as someone who advocates for history, I am less interested in details. How much does it matter what color a ship was or what types of guns it carried in the overall scheme ofo thing when you're trying to teach someone the key points of an event?

Sure, one reason the US won at the battle of Midway was our radar technology, but how much does that matter to the point that at THIS point we stopped the Japanese from a success and crippled their offensive power?

That's not to say that details don't matter; sure as hell they do. If I build a model of a ship for a sailor who was aboard her I want to make sure he or she can point to an area and say "I used to hang out here during general quarters," instead of "we had a gun mount right about here I was stationed at."

Some people are happy to take a lump of material, slap a number 14 on it and call it USS Ticonderoga, but I believe to truly honor a ship and her crew, you should strive to get as many of the details and particulars right as you can.

It's what separates those who build or read for fun from those who build or read for bigger reasons. But we shouldn't forget when advocating history that sometimes you need to let people walk before they can run, and the finer details aren't the the end all of history.

Monday, June 2, 2008

Only managed one page today; my Dragon Buchanan arrived today and Ron and I had to yak about it for a while.