Skip to main content

Posts

Showing posts from February, 2007

ds: daylight saving time ... and the impatient user

a talented ad guru brought this up to my attention. i thought it was something strange and important enough for everyone (the three of you that may actually read my blog) ... you may be aware of this but dst doesn't affect kerberos at all since kerberos only uses utc. there is still potential for problems, however. if a user moves their clock forward (or backward) instead of letting the dst rules adjust it, then they'll run into kerberos failures in the form of krb_err_time_skew . anything beyond a 5 minute skew is determined to be a replay attack... and subsequently not honored. so with that in mind, you think... domain-joined resources will reset their times to the domain time. unfortunately, this only occurs in 8 hour intervals. of course, if the user just manages to change their time zone, this will not cause the same effect. they'll be fine. the time zone is a local offset which does not affect the utc value like utilizing the date/time applet to change the t

os: default arp cache timeout (life)

this was such an obscure find that i thought i'd post it just to refer back to you later. in case you were wondering, 2003 cache holds entries that are invalid for 2 minutes and uses a value of 10 minutes for valid entries. here's the formal info (full reference is in this appendix ): ArpCacheLife Key: Tcpip\Parameters Value Type: REG_DWORD—Number of seconds Valid Range: 0–0xFFFFFFFF Default: In absence of an ArpCacheLife parameter, the defaults for ARP cache time-outs are a two-minute time-out on unused entries and a ten-minute time-out on used entries. Description: See ArpCacheMinReferencedLife

mom: what does maintenance mode speak to? (packet details)

i'm not sure why i never bothered to look at this before. i guess it piqued my interest because a coworker asked me what it needed to communicate with... the server or the agent? well, i fired up a packet sniffer and found this... {MSRPC:456, TCP:455, IPv4:454} 192.168.1.85 192.168.1.35 MSRPC MSRPC: c/o Response: unknown {MSRPC:456, TCP:455, IPv4:454} 192.168.1.35 192.168.1.85 MSRPC MSRPC: c/o Request: unknown {MSRPC:456, TCP:455, IPv4:454} 192.168.1.85 192.168.1.35 MSRPC MSRPC: c/o Response: unknown there's really nothing relevant in the trace to look at. just the fact that the rpc traffic from where maintenance mode ran only goes to the mom agent. so, i guess it is true that maintenance mode uses the agent to communicate to the mom server. this is kind of odd, i think... mostly because you can't use the command-line tool to set the machines in maintenance that are already down.  anyway, make sure the agent can communicate to the server and wherever yo

misc: xian io demonstrations coming up...

for your considerations w/ scom, if you have network devices you plan to monitor, attend one of these sessions to see how jalasoft does it. they've been around forever doing mom integrations. :) Presentation We want to invite you to join this special Live Meeting where we will show the new features of Xian Io. Among the topics that we will cover are: Integration with Ops Mgr 07, the Network Scan Server task, configuring rules, performance data, Distributed Applications and receiving alerts. The live meeting will be conducted by Arnold Hagens – Product Marketing Manager Sessions Four sessions will be held during the month of February on the following days: Thursday, February 1st - 12:00 P.M. EST (Eastern Standard Time) Thursday, February 8th - 12:00 P.M. EST (Eastern Standard Time) Thursday, February 15th - 12:00 P.M. EST (Eastern Standard Time) Thursday, February 22nd- 12:00 P.M. EST (Eastern Standard Time) Questions and Confirmation Questions and confirmation of your ses