XP

There is a handy registry setting that you can set, as long as you have XP SP2 or above, that will reset the error count once an I/O error recovers on the IDE chain. This is particularly handy for devices that like to get punted into PIO mode even though they are perfectly capable of doing DMA , 99.9% of the time. I need this for a dying hard drive that can perform DMA all day, as long as I don't go into the bad sector area where the head crashed in the past. If you're curious, this is also the same laptop that runs the ChickenCam, which is now viewable by clicking the "ChickenCam" link on the right side of the webpage.

The registry key for the IDE Primary Channel in question is a DWORD set to 1, at location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001\ResetErrorCountersOnSuccess

Depending on how many IDE channels your system has, you may need to increment the key by one for each channel.

For instance, the next channel would be listed under key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002\ResetErrorCountersOnSuccess

Read more about it here!

Hopefully, the ChickenCam will run marginally faster now. You can only torment a Pentium 2-333mhz chip so much with streaming video and routing packets.

The long running joke about instantly getting a performance boost inside Vista, especially when it is a guest VM, is to do net stop wsearch.

The next best thing you can do, besides limiting what folders are indexed, is to update your Windows Search to version 4.0. Most of the changes between the version included in Vista RTM, and 4.0, revolve around performance enhancements. It becomes especially noticeable on systems with limited I/O bandwidth (think laptops with 4200 rpm HDs).

However, this still isn't perfect. I've talked quite a bit with the Search team about this at the MVP Summit earlier in the year. There is a tweak I do on every system that runs Vista/Windows 7 or Server 2008 with the search/indexing engine enabled. I make sure to use Windows Search 4.0, for the performance improvements and the additional GPO/registry settings available.

The tweak? Disable the indexer backoff. You probably didn't realize you could even do this, but it is an available option that tells the indexing engine, "Don't worry about system activity - just index and get it over with already!". I'd much rather suffer with high CPU / I/O usage for a little while than a long and drawn out 'trickle' of activity that gives Vista a bad name.

This is particularly noticeable on a new install of Xobni when it indexes your Exchange mailbox and touches almost all your mailbox contents. With the indexer backoff enabled, which is the default on all operating systems, Outlook performance drags for a long time. With the indexer backoff disabled, the SearchIndexer.exe process will kick into high gear, finish and fall back asleep. Perfect.

How do you disable the indexer backoff?

For use in a group policy object (GPO):

Assuming you have the Windows Search 4.0 .ADM template added to your domain, or are on a Windows 7 system, look under Computer Configuration\Windows Settings\Administrative Templates\Windows Components\Search. The setting to disable the indexer backoff is not surprisingly called Disable indexer backoff. By default, it is set to Not Configured but you will want to set this to Enabled.

For a non-domain joined computer, or a single PC, you can set this DWORD registry key:

HKLM\Software\Policies\Microsoft\Windows\Windows Search\DisableBackoff with a value of 1.

You can download a pre-made .REG file here.

If this makes a difference for you, performance-wise, positive or negative, please let me know.

Buffer underflow in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2, Vista Gold and SP1, and Server 2008 allows remote attackers to execute arbitrary code via a Server Message Block (SMB) request that contains a filename with a crafted length, aka "SMB Buffer Underflow Vulnerability."

It is unusual to see the amount of attention given to this update and the speed at which it was released, especially out-of-band.

Thankfully for Server 2008 and Vista, the attacker has to be an authenticated user, but Server 2003 and XP users are not so lucky.

Most firewalls already block RPC traffic from external sources, so that attack vector is somewhat mitigated, but what I am worried about is the possibility of a 0-day worm getting inside an organization and worming around the entire network due to internal/client firewall rules.

It is particularly interesting that they released an update for Windows 7 pre-beta, build 6801, which I believe is going to be the build version given out at the PDC.

If you are running the beta builds of the Forefront Stirling TMG that have the GAPA protection enabled, you are already protected at the firewall level from the exploit due to the updated definitions already released by Microsoft. You can sort of think of it like Snort signatures.

I haven't seen Active-eXploits out in the wild yet, but it is only a matter of time.

You can read the Homeland Security National Vulnerability Database report on it here.

You can read a more in-depth report from the Microsoft Security Vulnerability Research and Defense team on the update here.

Direct download links to the patch, per OS:
Win 2K SP4
Win XP x86 SP2/SP3 / x64 RTM/SP2
Win 2003 x86 SP1/SP2 / x64 RTM/SP2
Win Vista RTM/SP1 x86/x64
Win Server 2008 x86/x64

Other sites with additional information on the exploit:
SecurityFocus
FRSIRT
SecurityTracker
Secunia
XForce (1 of 2)
XForce (2 of 2)

Your one stop for MMC 3.0 updates can be found in KB 940848. It is especially important for SCCM deployments because earlier versions had a knack for crashing your console without warning.

It is available for XP, Server 2003 and Vista.

You can download the update here.

This seems to be a hot topic because of the lack of description provided by the Live installation program.

To quote Len, one of the Windows Live MS employees:
Choice Guard is a piece of code that is responsible for setting the users homepage and search default if they chose those options during setup. Typically, this is a simple task of writing a value into a registry key.

However, several of our competitors install a "service" that is always running on your machine that prevents the registry key from being changed, even if that is what the user decided to do. So Choice Guard looks for the presence of those apps that might be preventing the user's choice from being carried out and works around their block to set the search default.

It only does this one time. If the user attempts to change it again, either manually or programmatically, they are free to do so. It turns out that in order to set the search default and homepage on the Firefox browser you need to install yourself as an add-on, which is why Choice Guard is appearing in the list.

Although you should probably be using Microsoft Deployment Toolkit 2008 Update 1 (say that five times fast) for any new desktop rollout or DDPS session, the older versions are handy to have around for features/operating systems that get retired/depreciated over time.

If you have a need for any of these versions:

BDD 2.5 Standard
BDD 2.5 Enterprise
BDD 2007
Microsoft Deployment
MDT 2008

You can grab them from here.

After rereading my post here about buying the Hava device, I remembered that I never updated that post to reflect how I fixed Sabrina's PC lockup issue. Although I no longer have any of the crash dumps that happened while the Hava client was running on her computer, it seemed as though the system was crashing in the middle of processing a network packet. To go along with that theory, the network adapter in her older PC, a CNet Pro200WL, would stay 'lit up' on the physical interface lights on the card until the system was physically powered down. You could soft boot numerous times but the chip onboard would never recover from the crash. It was acting like a hardware bug or defect more than a driver problem.

Unfortunately, I think many of these cards at one time or another were bundled with Dell PCs because they were so low priced compared to quality chipsets. Her PC in question is a Dell PC that was donated to her by her grandparents not too long ago, much to her delight.

Running with that theory, and not wanting to have a kid constantly complaining about an unstable computer, I popped in my trusty SMC EtherPower, which is over a decade old. Not to be confused with the truly awful EtherPower 2, it is based on the excellent Digital DECchip 21140 (Tulip) chipset, which eventually was used as the "virtual chipset" that Virtual PC uses as an emulation platform for 10/100 ethernet.

Although it had higher latencies than some of the busmaster capable NICs that would come out after it, it was always a workhorse that had support in virtually every operating system. It has outlived a dozen of my personal PCs so far and was going to prove itself again in the year 2008.

Long story short: I put the old SMC network card in the 'practically new' PC and XP identified it correctly as an "Intel 21440 ethernet adapter". Intel bought the rights to Digital's network IP when Digital went out of business. I fired up the Hava client and no matter how many network packets I throw at the system, I can no longer blue screen the system once it starts seeing multicast/HAVA traffic.

Moral of the story: DEC chipset good, Davicom chipset bad.

This hasn't been my first encounter with flaky behavior from a Davicom network card. I remember having nothing but trouble under Linux with the Davicom network adapter that was built into a MSI Book PC.

This download link might be from IBM, but these are “generic” reference drivers, which mean they will work with any Broadcom NetXtreme II based chipset.

The added benefit is that these seem to support Hyper-V better.

Problems with the Server 2008 inbox drivers are well documented here.
You can download the complete updated driver collection for Broadcom here.
Thanks go out to the comments in that referenced blog post for providing the IBM Broadcom link.

Most of the time when you encounter this error, it is too little, too late and you are using the recovery console to get rid of the bogus Intelppm.sys entry in the registry and/or filesystem on an AMD system, but this update here is the official fix for the problem.

This update is intended to be installed on XP SP2 systems before applying SP3, if they are running a Sysprep image that was originally created on an Intel machine that ends up getting deployed on an AMD machine. The worst offender seems to be HP OEM machines.

The old Vista and XP TechCenters have been retired and combined into a brand new site, which goes along with the other revamps that MSDN and TechNet have received in the past few days.

Highlights of the new site:

New “zones” for top tasks related to application compatibility, User Account Control (UAC), imaging, hardware compatibility and performance, desktop security and encryption, and networking.

Improved organization of resources by lifecycle phase and technical level (overview or advanced)

Advice from subject matter experts at Microsoft and in the community

New information on ways to advance and simplify desktop management

To check it out, go here.

Most of the time, Windows 2003 and XP behave correctly when communicating with a Windows 2008 Read Only Domain Controller. RODCs are extremely handy for branch offices, especially when combined with Bitlocker, for extra security for remote locations.

This update, KB 944043 helps work around some of the known issues that 2003 and XP do not know how to handle out of the box, because RODCs did not exist when they were originally programmed.

In general, you'll want to deploy this on your network before you deploy any RODCs to prevent any of these potential "gotchas". So far, it has been my experience that "everything just works" with RODCs without these updates, but I don't have some of the exotic setups that these known issues arise from.

Go here for the fix if you are experiencing this issue.

I have experienced this problem on my little Thinkpad 240 laptop that I use as a poor man's EVDO router. Believe it or not, it makes for an extremely portable "Internet hot-spot on the go".

Sometimes when the Novatel NDIS adapter 'falls asleep' on the receive side, I have to reset the connection. This only happens rarely, but before this fix was installed, DNS resolution of the ICS clients would fail unless I hard-coded external DNS servers on the client systems.

Of course, the hard drive on the Thinkpad has an expired warranty and is an IBM DeathStar with bad sectors, so it is only a matter of time I have a massive hard drive failure. I have a system image backup for when that day comes. I've been saying that for the past 2 years.

Now that I've mentioned it on here, I am sure it will fail within a week.

When that day comes, I can roll out a beta of the Forefront Threat Management Gateway for our house.

Windows Script 5.7 comes with XP SP3, so if you are running XP SP3, Vista, or Server 2008, you already have WScript 5.7.

This is a relatively small upgrade compared to other releases but it does come with some performance improvements and bug fixes which are noted here.

If you want to download Windows Script 5.7 for these older operating systems, go here.

If you want more in depth information about this release, check out the KB article here.

If you are curious what fixes made it into XP SP3, take a look at KB article 946480.

Go here to read about the issue and update your MDAC on XP SP2, XP SP3, Vista RTM, Vista SP1, and Server 2008 to this latest revision to prevent potential data loss in certain (rare) cases.

This is the bug that caused the delay with XP SP3 due to problems with CRM.