IT

If you are having this problem, here is the fix.

I can't say it any better than she can so I'm just going to link to her blog entry on it!

http://msmvps.com/blogs/bradley/archive/2006/05/30/98329.aspx

If anything, this is a note to self. I tend to keep a session of multitail open on any server I like keeping an eye on. Typically it will include the security logs, http logs, error logs, and audit logs. In a few instances when 'logrotate' has kicked in overnight while a 'multitail' session was open, watching the files that were getting moved, all hell breaks loose.

Since the file handle/files that multitail watches suddenly disappear/become invalid, the spawned 'tail' children go into a psuedo-fork-bomb/zombie loop.

For instance, this morning I awoke to about 3000 rapidly spawning and dying 'tail' processes that made it difficult to near impossible to pull up a process list. When that failed, I ended up browsing /proc to see if something bad was going on. I also peeked at /proc/loadavg which was actually pretty normal. Since I have some sane ulimits set on the machine in question, the overall problem didn't become a system-wide out-of-memory problem/crash.

When I get a moment I'll see if I can hack a way to make multitail a little more friendly to files getting purged from under it.

If you have no idea what I'm talking about with multitail, please check out the website for it:
http://www.vanheusden.com/multitail/

It is like tail on steriods.

The WSUS team made a boo-boo it seems, and the recent release of SQL 2005 SP1 to WSUS ignored language filters.

You can read about it here:
http://blogs.technet.com/wsus/archive/2006/05/25/430136.aspx

Basically the subject line says it all. If you want working AV today, go grab this free copy.

https://www.my-etrust.com/SubscriptCenter/MSTrialRegistration.aspx?cid=1855&lang=en-US

I might have to stop by and check out what they have going on at some point. Sometimes I'm burnt out and antisocial after work, so it will have to be during one of our slow times, which lately, seems to be never.

I can't complain though. I have a job and we're super busy. It is a lot better than being unemployed and unable to pay the bills.

http://www.wmntug.org/

Mostly only useful for developers at the moment since there is a lack of plug-ins released so far, but if you want to get a headstart on using them/enabling the hidden menus, add in a DWORD to HKCU\Software\Microsoft\MSNMessenger with a key name of 'AddInFeatureEnabled' set to 1.

I'm always a sucker for a good plug-in for Outlook, and even more so when the cost is $0. I have a feeling this is going to end up on my little USB keychain drive to take wherever with me. This allows you to look up addresses from within Outlook and also get directions.

http://www.microsoft.com/mappoint/outlook/download.mspx

My house is a stones throw away from Muskegon county. We are technically in Ottawa county but our mailing address is in Muskegon county. We are within a few miles of Muskegon and Kent county.

I *really* hope that their coverage reaches our house because right now I am using 1xRTT CDMA for "broadband".

News article about it:
http://wimaxnetnews.com/archives/2006/04/samsungs_80216e.html

The company involved:
http://www.arialink.com/residential_products/home_services.html

This is a handy utility that will patch your XP box from SP2 all the way up to the May 2006 security updates plus a little bit more, if you want. I typically carry a copy around with me wherever I go to avoid updating machines all day long by downloading everything from Windows Update. With one EXE, you can be up to date.

http://www.neowin.net/forum/index.php?showforum=89

It is unsupported currently, but it doesn't look too difficult to do.

http://blogs.lv0.net/mpatest/archive/2005/11/18/182.aspx

Transportable shadow copies previously were reserved for the Enterprise and Datacenter editions, but with this update, even the Web edition can take advantage of them.

This update also seems to fix a lot of other issues people have been seeing with paged pool exhaustion and VSS.

KB 913648

Excellent time saver, and fairly unknown still in the Windows world. Use this tool to migrate old 'hard-coded' server resources to a new consolidated DFS root.

http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en

Only 3 gotchas that I have run into from time to time is that you have to be running W2K3 Enterprise Edition to support the DFS consolidated roots and the server that is running the consolidated roots cannot be a domain controller. If you are running W2K3 RTM, you will need to download a DFS related fix (KB 829885). If you are running SP1, you are all set.

This goes along with the %0 trick I mentioned previously but if you are still using DOS style scripts for logons, whether to support older clients, or to keep an old setup around for historical purposes, make sure to call out the executable with a complete pathname and/or at least the correct extension.

This might seem like a really minor point but everytime the OS has extra "work" over a starved connection, performance will stall due to directory lookups and such.

So, instead of calling:
notepad newfile.txt

Use:
%windir%\notepad.exe newfile.txt

A side effect of stating 'notepad.exe' instead of 'notepad' is that the command prompt won't go looking for notepad.bat, notepad.com, or notepad.cmd, across the wire.

This makes a difference because any file extension mentioned in %PATHEXT% is cycled through until it finds a match.

This also helps in the case where a virus hijacks 'notepad.bat' somewhere in the path and you end up not running the intended executable. It is a bit of a security 'fixup' if you want to think of it that way.

Some might view this as overkill but when you are stuck logging into a domain over a cell phone data connection, you will thank me later. Ideally, you would want to convert your scripts to a VBScript or a PowerShell script, but that isn't always possible or feasible.

Many times I've seen logon scripts that will directly reference a certain domain controller's SYSVOL or NETLOGON share when running an executable or script that resides in the 'scripts' folder of the SYSVOL.

This defeats the purpose of having geographically located domain controllers if everyone is going to be pointing to a certain server everytime.

For instance if you have a DC in New York and a DC in London, but all your scripts refer to \\wsvr-dc-ny\netlogon\con2prt.exe, you will have a lot of traffic (theoretically) going over the wire to and from New York everytime someone logs in, in London.

So, as an example, if you are still using DOS style scripts, you would want to change:

\\wsvr-dc-ny\netlogon\con2prt.exe /c \\wsvr-ps-london\fax

to something that looks like:

%0\..\con2prt.exe /c \\wsvr-ps-london\fax

Why? It will use the logon server in London, if someone logged in, in London, assuming the system determines that it should use the London server as the logon server. You can always doublecheck by checking the %LOGONSERVER% environment variable.

Most people don't know about the "%0\..\" trick, so that is why I'm writing about this.

It also removes hardcoded server names in your scripts, which I try to do whenever I can, since it makes migrating to different naming schemes and other admin activities a lot easier.

This will basically work with any Windows OS that has the 'systeminfo' command.

systeminfo | find "Up Time"

You can think of 'find' much like 'grep' under Unix.

It will return something that looks like "System Up Time: 4 Days, 1 Hours, 53 Minutes, 36 Seconds"

If you are on an older OS, you can always do "net statistics workstation" and look for the second line which will say something like "Statistics since 5/18/2006 11:17 AM"

It won't be accurate 100% of the time, such as in the case where you have restarted the workstation service, but 9 times out of 10, it will be correct.