April 15, 2009 5:37 PM
Posted by: Ed Tittel
April 2009 Scheduled Updates
, Enterprise Vista
, Microsoft Patch Tuesday
, Windows security updates
Patch Tuesday items hit yesterday between 1:00 and 1:30 PM Central Daylight Time on servers that I could see. The MS09-April Bulletin Summary from Microsoft covers all the details, but here’s what I hope is a good overview and synopsis of what you’ll find therein. Interestingly, none of this stuff is reflected in updates pushed (or rather, not pushed) for the Windows 7 beta now underway. I’m guessing that MS doesn’t patch betas the same way it does production code, and is probably seeking to avoid additional release cycles.
Here’s a table for the 8 security bulletins published for the patches/fixes/updates pushed yesterday, in bulletin order. The ID/Link column provides the standard MS security bulletin IDs, which range from MS09-009 through MS09-016 for this month; Critical updates are bolded, Important ones in italics, Moderate in plain text. The Title column repeats the Microsoft bulletin title verbatim with the related KB article number in parentheses trailing, while Vulnerabilities data take the form n/m where n is the number of public vulnerabilities addressed, and m the number of private ones addressed, by a bulletin. SW Affected lists the OSes and applications affected; where Windows is bolded, Vista is included.
April 2009 Security Bulletins
||Vulnerabilities in Microsoft Office Excel Could Cause Remote Code Execution (968557)
||Vulnerabilities in WordPad and Office Text Converters Could Allow Remote Code Execution (960477)
||Windows, Office 2000-2007
||Vulnerability in Microsoft DirectShow Could Allow Remote Code Execution (961373)
||Vulnerabilities in Windows Could Allow Elevation of Privilege (959454)
||Vulnerabilities in Windows HTTP Services Could Allow Remote Code Execution (960803)
||Cumulative Security Update for Internet Explorer (963027)
||IE6 and IE7, including Vista
||Blended Threat Vulnerability in SearchPath Could Allow Elevation of Privilege (959426)
||Vulnerabilities in Microsoft ISA Server and Forefront Threat Management Gateway (Medium Business Edition) Could Cause Denial of Service (961759)
||ISA & ForeFront Security
Only the items with Vista explicitly mentioned or with Windows in bold will be of interest to those who manage only Vista desktops. As usual, I include everything because few people on the job are actually in that position and must usually also manage updates for other MS platforms and applications as well. Time to get patchin!
April 13, 2009 3:12 PM
Posted by: Ed Tittel
, suprising production use of Win7
, upgrading Vista to Win7
, Win7 clean install
, Win7 Release Candidate install
, Win7 upgrade install
, Windows Vista
An interesting report from ComputerWorld surfaced this morning — namely, a request from Microsoft for Windows 7 beta testers to restore Vista on their test machines before upgrading to the upcoming release candidate (RC) version of that software. This is a reworked version of a story that originally appeared in the print edition of the magazine on April 7, but I can only link to the Web version here. The original material comes from the Engineering Windows 7 blog, in a posting entitled “Delivering a quality upgrade experience” (I had real trouble getting this post to open, and was only able to access it via IE after numerous tries, never on Firefox).
Basically, the post asks beta users to roll their machines back to Vista before installing the next RC so that MS can benefit from a larger user base in evaluating the upgrade install from Vista to Win7, believing that this will represent the bulk of the user base’s own experience when the time comes for all of us to work with the final, commercial release of Windows 7. MS cites “telemetry” that they received during the install process to back up this claim, noting also that “most of you did clean installations onto new partitions” (that’s exactly what I did on every single one of my test machines, in fact).
Here’s what they say about the next release, quoted in full:
We’ve also learned that many of you (millions) are running Windows 7 Beta full time. You’re anxious for a refresh. You’ve installed all your applications. You’ve configured and customized the system. You would love to get the RC and quickly upgrade to it from Beta. The RC, however, is about getting breadth coverage to validate the product in real-world scenarios. As a result, we want to encourage you to revert to a Vista image and upgrade or to do a clean install, rather than upgrade the existing Beta. We know that means reinstalling, recustomizing, reconfiguring, and so on. That is a real pain. The reality is that upgrading from one pre-release build to another is not a scenario we want to focus on because it is not something real-world customers will experience. During development we introduce changes in the product (under the hood) that aren’t always compatible with what we call “build-to-build” upgrade. The supported upgrade scenario is from Windows Vista to Windows 7. Before you go jump to the comment section, we want to say we are going to provide a mechanism for you to use if you absolutely require this upgrade. As an extended member of the development team and a participant in the Beta program that has helped us so much, we want to ask that you experience real-world setup and provide us real-world telemetry.
In other words, they want even those users who’ve set up and tweaked their machines to full production status to start over again with the next release. Then, as a sop to those people who simply don’t want to wipe their Win7 partitions clean and start over, they provide a step-by step method to bypass the pre-RC build check that disables an upgrade install on such machines. Here’s a summary of the steps involved (consult the original blog for more details).
- Download the ISO and burn it to a DVD
- Copy the entire image to some storage location from which you’ll run the upgrade install (such as a UFD)
- Browse to source directory
- Open the file named
cversion.ini in a text editor (such as Notepad)
- Modify the Minclient build number to a value less than the down-level (current) build
- Save tfe file with its changes
- Run setup from this modified copy and version check is bypassed
Of course, MS wants the data on the “default scenario” (clean partition, or an upgrade to Vista) so that’s why they put hurdles in the way. Kudos to them for providing a workaround, and knocks for making it necessary. Interestingly, with nearly 60% of the Windows installed base running XP anyway, I find it fascinating that the focus here is on Vista. I’ll be very interested to see what kinds of tools emerge to address the real default scenario when that time comes!
April 10, 2009 4:34 PM
Posted by: Ed Tittel
, Windows Update
, Windows Vista critical security updates
, Windows Vista Important security updates
, Windows Vista Moderate security updates
, Windows Vista security updates
Next Tuesday, April 14, is Patch Tuesday for this month. As usual, Microsoft e-mailed its Advance Notification yesterday to let us all know what’s coming (there’s also a Web version as well). Here’s what to expect, Windows Vista-wise from the 8 bulletins (5 of which are critical) to be released that day:
- Windows (which often involves Vista): 3 Critical, 1 important, 1 moderate. All 3 Critical bulletins pose potential remote code execution vulnerabilities, while the Important one involves an elevation of privilege for attackers. The Moderate item involves a potential elevant of privilege as well.
- Internet Explorer and Excel: Two more critical bulletins, both of the remote code execution variety.
- Internet Security & Acceleration Server (ISA): One important bulletin that could involve Denial of Service for Microsoft Forefront Edge Security software.
- 6 of the 8 items require a system restart, while the other two may require a restart, depending on local conditions on patched PCs.
- Of the 5 Windows bulletins, 3 of them involve Vista (Windows 2, 4, and 5); the IE patch also affects IE7 on Vista as well.
Looks like we’ve got some patching in our future. Stay tuned for details next Wednesday, April 15.
April 8, 2009 5:15 PM
Posted by: Ed Tittel
, Windows Vista paging file
, Windows Vista tweaking and tuning
, Windows Vista virtual memory
One question that I get frequently about Vista, especially from power users, tackles the size of its paging file. Remember, the paging file (which resides in a file named pagefile.sys on Vista machines, often on the system drive, sometimes on one or more other physical drives present on a Vista PC) provides extra “scratch space” for the operating system to use, especially when moving applications in and out of physical memory. The combination of the page file and physical memory creates an aggregate work space so that Vista can manage multiple applications, services, and so forth simultaneously, without having to keep all of them in memory all of the time.
When Vista creates a paging file, it normally creates one that’s twice the size of physical memory, sometimes more than that (actual values depend on free space available on the target drive(s) at the time the page file is situated). Microsoft recommends no less than the amount of physical memory plus 300 MB for the minimum value, and sets the maximum at three times the amount of RAM installed in a PC. Conventional wisdom is that the defaults are fine, particularly on drives that have sufficient free space to allocate three times RAM to the paging file as an ultimate high-water mark.
Most of the power user questions add some interesting wrinkles to this discussion. Thus, for example, consider that 32-bit Windows can address only 4 GB of RAM period. A common form for this query is something like: “Why is a paging file necessary when the amount of RAM matches what Windows can handle anyway?” The answer is interesting and a bit counterintuitive:
- on 32-bit systems video memory, BIOS memory space, DMA, IRQ, and other system memory maps and hardware addressing usually consume memory from the top down. That’s why on 32-bit systems with 4 GB installed, Task Manager usually reports only 3xxx MB of RAM (3317 on my Dell D620 notebook and 3581 on my Intel desktop, for example) rather than 4096.
- some Windows applications require access to a paging file so they can operate properly, and will crash if you try to run them with the paging file disabled.
- Windows itself prefers to have access to a paging file, if only to help it manage the process of loading and unloading applications scheduled for execution (on the way in) or for termination or swap-out (on the way out).
- You can’t capture memory dumps from stop or blue screen errors without a paging file (even minidumps require a 64 KB paging file, and the Vista minimum size is 16 MB in any case).
This discussion kicks up a notch when power users run 64-bit Vista with more than 4 GB of RAM, but the issues remain more or less the same. In general, it’s not worth messing with the defaults unless there’s some compelling reason to do so (limited space on a notebook SSD, for one example, or demonstrable performance slow-downs attributable to paging, for another).
When downsizing a paging file, here are some points to ponder:
- experimentation shows that at least 512 MB of paging file is the absolute minimum that delivers reasonably stable operation, with values of 1 – 2 GB sometimes offering even better stability.
- if you want to capture a complete memory dump, the paging file must be at least as large as the amount of physical memory installed on the machine (this file usually appears in a filed named MEMORY.DMP in the %SystemRoot% directory, which is C:\Windows on most Vista machines).
- be sure to check all the applications you’ll want to run on that machine, and keep an eye out for insufficient virtual memory messages. These will appear until you re-size the paging file to a point where all applications find sufficient virtual memory available for their use.
This kind of testing, requires a lot of patience, time, and effort which is why only power users (and mildly obsessive ones at that) are usually willing to go through this exercise. For most users, especially those uninterested in tweaking and tuning their Vista notebook or desktop PCs, the system-defined defaults should work just fine.
April 6, 2009 6:46 PM
Posted by: Ed Tittel
, Windows Vista
, Windows Vista adoption
, Windows Vista blocked
, Windows Vista legislation
On April 2, ComputerWorld reported that the Texas Senate included a rider in its 2009-2010 state budget that blocks state agencies from upgrading to Windows Vista without first obtaining written consent from that body. State Senator Juan Hinojosa, chairman of the Senate Finance Committee, explained he included the rider “because of the many reports of problems with Vista.” He went on to say that in addition “…the XP operating system is working very well” and that his body is “…not in any way, shape, or form trying to pick on Microsoft.”
Interestingly, the rider requires Texas state agencies to otain written approval from the Legislative Budget Board (LBB) before acquiring any Vista licenses, even for PC’s that include pre-installed copies of this much-maligned OS. Alas, it’s too late for many existing installations. The Texas Department of Information Resources (DIR) reports that over 40 state arms has spent more than $6M on Vista purchases and upgrades, though the DIR itself uses Windows XP and Mac OS X. Given Microsoft’s overall clout, and the fact that it employs over 1,500 people in the state, with sales and development offices in most major Texas cities (Houston, Dallas, San Antonio, Austin, and others), it will be interesting to see if this injunction can withstand the budget reconciliation with the house version, and pressure from Microsoft and business interests allied with that company.
But those whose thoughts about Vista might have occasionally included the phrase “…there oughta be a law…” can now claim some legislative satisfaction, no matter how fleeting or transitory this ruling may turn out to be. Personally, I find it fascinating that the legislative machinery includes room for this kind of activity along with everything else that’s involved in keeping government going!
April 3, 2009 3:11 PM
Posted by: Ed Tittel
Mark Russinovich technical blog
, Windows 7
, Windows 7 blogs
, Windows 7 Feature walkthroughs
, Windows 7 forums
, Windows 7 springboard
Thanks to a recent email from the Microsoft Learning PR rep, the ever-helpful Andrea Platt Dayal, I now know about the Microsoft Springboard Series, which she describes as a source of “…additional information for IT pros on Windows 7.” True though this statement may be, it fails to do justice to what you’ll find there. After digging into and through some of its offerings descriptive phrases like “treasure trove” or “fabulous collection” somehow spring to mind.
Let me list some of the items I found there by way of explanation:
- Long-time Windows internals guru and MS Technical Fellow Mark Russinovich offers a Channel9 preview of the long-awaited revision to his Inside Windows book with a show called “Mark Russinovich Goes Inside Windows 7.” If you follow the link to his “Pushing the Limits of Windows: Paged and Nonpaged Pool” you’ll find an interesting discussion of Windows memory pools and the first really cogent and concise of the dreaded IRQL_NOT_LESS_OR_EQUAL stop error code I’ve seen.
- A nice series of Windows 7 Feature walkthroughs is also available. Topics covered include Windows PowerShell 2.0 (a major upgrade from the 1.0 and 1.1 versions available to Vista), the User State Migration tool and Windows 7 AIK, BranchCache, DirectAccess, UAC, the new Windows Troubleshooting Platform, AppLocker, Deployment Image Servicing and Management (DISM), and a whole lot more of great potential interest to enterprise admins.
- Interesting spots of coverage in the Windows Client blog, including blogs related to Engineering Windows 7 and this very Springboard Series.
- Links to news and highlights items (with an RSS feed to match), as well a link to the Windows 7 Beta forums. Makes it easy to keep up with recent developments, and the forums provide ample insight into what users love and hate about the current beta.
Do yourself a favor: if Win7 interests you, even only as a matter of curiosity, check these links out!
April 1, 2009 4:18 PM
Posted by: Ed Tittel
, enterprise Vista desktop
, Windows Vista stability
, Windows Vista troubleshooting
, Windows Vista vs. Windows 7
I jsut read a marvelous story from the Sydney Morning Herald entitled “Windows 7 looking good, especially after Vista woes.” It includes a brief but telling remark about Windows Vista to which I can’t help but ascribe epigram status — namely, “Windows Vista is widely reviled, and sometimes seems so bad that it resembles malware (malicious software).” While I can’t agree with this statement, I can’t dispute its accuracy or relevancy, either. As you read through the story, and I encourage you to do at your earliest opportunity, you’ll find plenty of other interesting and diverting bits of techno-trivia.
What I’ve had ongoing trouble with right up to the present is with Vista’s complexity and lack of incisive controls. On certain hardware configurations, I’ve repeatedly found myself in situations where Vista would keep limping along, but an increasing number of applications would fade into the “Not Responding” state. At the same time, I found myself unable to bail out of the OS using either CTRL-ALT-ESC to get into Task Manager, or CTRL-ALT-DEL to call up the login/logout/control screen. Rebooting to re-establish system stability is kind of a cop-out anyway, but I’ll be darned if either the System or Application logs in Event Viewer can provide me with any data about what caused my system to hang, and required me to peform yet another “disruptive shutdown” to regain control over my machine.
In working with Windows 7, I’ve been able to get the two “attention sequences” (CTRL-ALT-DEL and CTRL-ALT-ESC) to work as they should even when the system got extremely flaky owing to installation of an obviously incompatible driver. I have to ask: why won’t Vista work the same way? I’m not ready to put this OS in the same class as malware, and I do believe I’ve reached an “uneasy rapprochement” with Vista, to the point where I can get along with it on a day-to-day basis and keep my own and my users’ machines up and running most of the time. But I keep wondering why it gets flaky from time to time, and how I might be better able to maintain stable, long-term operation (for more discussion see my March 12 Blog at ViztaView.com).
If anybody has any wisdom to dispense here, or any war stories or hard-earned experience to share, please chime in. Surely it’s better for us to suffer together, than to do so alone! Just because you think Windows Vista is out to get you, doesn’t mean you’re paranoid.
March 27, 2009 4:00 PM
Posted by: Ed Tittel
, Internet traffic trends
, waiting for Windows 7
, Windows Vista
, Windows Vista marketshare
, Windows XP marketshare
On March 23, Sam Diaz blogged for ZDnet that Vista’s market share has apparently climbed past 30% for the first time, according to an analysis by Web traffic monitoring company StatCounter. According to that latter company’s CEO, Aodhan Cullen: “Based on daily data Windows Vista has only topped 30% a few times before and only for a maximum of three days running. This is the first time it has broken through 30% on a weekly basis suggesting that it is gaining some consistent traction in the US.” Based on an analysis of 4 billion pageloads monthly, this data also makes some other interesting observations possible:
- XP still predominates with a market share in excess of 55%.
- Vista traffic spikes on weekends, while XP predominates on weekdays. This underscores the presence of Vista in the consumer category, probably pre-installed on newer PCs, with the continuing presence of XP in the workplace.
- Mac OS numbers show slightly in excess of 8%.
- By extension, this puts Linux, Unix, and other OSes at about 7%.
While Vistaheads (like me) might be tempted to take some heart from this upsurge (which has climbed steadily since hovering around 10% until last fall), the real news here is that a big loyal installed base of XP continues to rule the workplace. With free support for XP scheduled to end on April 14, 2009, does this mean that companies will be boosting MS support coffers with paid support while waiting for Windows 7 to ship?
I don’t see how it’s possible to come to any other conclusion. It will be interesting to watch the Vista numbers for movement in the coming months, as businesses — especially smaller ones — start to realize what the end of free XP support really means, and to weigh the risks and costs of switching to Vista sooner or paying for the privilege of switching to Windows 7 later.
March 25, 2009 6:02 PM
Posted by: Ed Tittel
, Enterprise Vista
, Halfdone Development
, Unknown Devices
, Windows Vista setup and configuration
, Windows Vista troubleshooting
If you’re like me, you’re nearly always in the process of building or rebuilding one or more Vista systems, or checking specific systems out for currency and correctness. Especially when dealing with new or revised builds, or with systems you haven’t worked with before, you will occasionally come across devices that Windows doesn’t recognize. When that happens the first step toward finding the correct and likely MIA device driver is to identify the device that’s currently earning a yellow question mark in Device Manager.
That’s where Unknown Devices comes in. It goes through the Windows device enumeration process and records everything it discovers during that process. Even if the program itself can’t identify a device — and I’ve seen this happen in less than a handful of instances on all the systems I’ve tried it on —it provides you with a vendor ID string in nearly every case (so far, that means 100% for me in my personal experience, but I also know that it’s possible that you might come across a device for which the software can’t find such data). With that information in hand, you can almost always Google your way to device identification, and from there to a driver for your platform and OS.
The interface is pretty spare and simple, and consists simply of a list of device categories at the top level. These map to elements that appear in Device Manager as well, though you’ll find more elements in Unknown Devices than you may see on a specific desktop. For example, I’ve turned off the floppy controller and floppy disk drives in BIOS on those machines that have no floppy drives installed and they don’t appear in Device Manager any more; nevertheless, they still show up in Unknown Devices (though no entries appear under these headings on such machines, as you might expect).
Unknown Devices lists all devices it finds using familiar Device Manager categories.
Click on any category and you can examine a listing of its contents as shown here, for the Storage Controllers category (a green checkmark indicates a signed driver):
Items listed for the Storage Controllers category.
Right-click on any item, then select device details to see basic information about the device in question. Here’s a snap of the info shown for the motherboard’s built-in ICH9R RAID controller:
Basic device information is readily available.
Despite an occasional misspelling (Vender for Vendor, Visable for Visible) the tool nevertheless delivers lots of useful information, and can help you run down and pinpoint unknown devices pretty efficiently. Better yet, I’ve recently learned from direct experience that this tool works with XP, Vista, and Windows 7, even, which makes it very handy indeed. I’d wondered why Unknown Devices was part of the basic toolkit for the various WinBuilder projects (LiveXP, VistaPE, and Win7PE) and now I know. Try it out, and so will you!
WARNING! The information that Unknown Devices turns up is only as good as the various PCI, USB, and Chipset identification text files that drive the program. You’ll definitely want to follow developer Mike “Catfish” Moniz’ advice, and grab the latest version of the PCI, PCI-e, AGP, … devices list from the link he provides for that purpose. This program is no panacea for Windows device identification or troubleshooting, but it does come in pretty handy.