One ongoing and legitimate beef about Windows Vista is that it doesn’t support older Windows applications, particularly those written specifically for older Windows versions or that don’t follow well-established guidelines for “good behavior” in terms of referencing APIs, interacting with hardware, and so on and so forth. Now, Microsoft comes to the rescue with a product called Microsoft Enterprise Desktop Virtualization aka MED-V. It’s still in beta, and you have to register with Microsoft connect to obtain access to this otherwise free download, but you gain the ability to install Windows 2000 or XP in Vista using Microsoft Virtual PC 2007 (also free) so that the VMs can do for you and your users what Windows Vista sometimes cannot.
A commercial version of this software is expected later in 2009, and is based on technology that Microsoft acquired when it purchased desktop virtualization firm Kidaro in mid-2008. The idea, of course, is to spur upgrades and migrations to Windows Vista because previous obstacles to such motion are now mitigated by a solution that permits immovable legacy software to run in a back-rev Windows VM on top of Vista. This also lets enterprises impose centralized management and control over construction, deployment, and maintenance of system images, both virtual and real, and helps to add structure and organization to sometimes-chaotic desktop environments. Microsoft itself makes much of TCO improvements that switching to its Desktop Optimization Pack can confer. Above and beyond MED-V and application virtualization, this also includes an advanced Group Policy manager, an asset inventory service, a diagnostics and recovery toolset, and a tie-in to System Center for desktop error monitoring. It’s definitely worth checking out.
But if you’re fighting to migrate or upgrade systems to Vista, and legacy apps are getting in the way, MED-V may be just the lever you need to break that particular logjam. Give it a try!
Tomorrow, February 11, is the second Tuesday in February–hence, “Patch Tuesday” is once again at hand. Microsoft publishes advance notification for security bulletins each month on the preceding Thursday, so I can tell you what to expect in tomorrow’s updates. There are four items that should be included (though last-minute additions and deletions have been known to occur):
- Critical: Internet Explorer 7 versions remote code execution fix. XP, Vista, Windows Server 2003 and 2008, 32- and 64-bit versions.
- Critical: Exchange Server versions remote code execution fix. Exchange 2000 Server SP3 with 8/04 update rollup, Exchange Server 2003 SP2, Exchange Server 2007 SP1 (32- and 64-bit versions).
- Important: SQL Server remote code execution. Too many versions to enumerate here (check the advance notification link in the first paragraph for details).
- Important: Visio remote code execution. MS Office Visio 2002 SP2, MS Office Visio 2003 SP3, MS Office Visio 2007 SP1.
As usual, there will also be an updated version of the Microsoft Malicious Software Removal tool (KB890830) and the Windows Junk E-mail Filter (KB905866) for February, 2009, included as well. There will also be cumulative updates for Media Center for Windows Vista (KB950644) and Media Center TVPack for Windows Vista (KB958653), plus an update rollup for ActiveX Killbits for Windows (KB960715). These are described in more detail in KB894199 and also in the other KB articles cited for each item.
Given that all the major updates relate to remote code execution and the system compromises such vulnerabilities can produce, it’s probably time to start testing and/or deploying these patches to your clients and servers on an ASAP basis.
If you read my previous blog, you already know that VistaPE is a project that uses WinBuilder to automate the construction of a WinPE 2.0-based bootable image from the Windows Automated Installation Kit (WAIK) as well as the Vista OS install media (or a hard-disk copy thereof, for much better build-time performance). What may not have been clear in that posting, has now become crystal clear to me, thanks to spending a large part of the last two days devouring the forum posts, tutorials, and how-to’s available at Nuno Brito’s stellar site www.Boot-Land.net, the home of WinBuilder and an affiliate site for VistaPE.net.
What I didn’t immediately realize but am now keenly aware of, is that this site is a treasure trove of Windows internals lore, tools references, and information that has to be explored to be believed, and deeply pondered to be fully understood. I have learned more in the past two days about Windows boot structures, how the boot process begins, about the various types of file systems and MBR records that PC BIOSes can create and the various versions of Windows can accommodate, and how to build bootable floppies, hard disks, UFDs, and optical media than I ever imagined possible.
To me, Boot-Land.net is a stunning and entirely convincing demonstration of the power of open source and community effort. There’s no way a commercial outfit would be willing to disclose the kind of information that people want and need to know about low-level inner workings of operating systems, bootstrap loaders, BIOS operations, and related forensics and construction tools–at least, not without feeling like its “valuable intellectual property” had been given away purely for good will. Boot-Land.net does this as a matter of deliberate policy, design, and support for community.
Any Windows professionals, including those who work with XP and Vista, as well as other versions both older and newer, will find lots of interesting, valuable, and useful information here about how to design, build, and install compact boot environments for Windows machines. They’ll also learn about lots of tools they can include in such environments for installation, automated deployment, troubleshooting, and system repair.
I’d have to recommend this as one of the best resources I’ve ever seen when it comes to understanding how the Windows OS is put together, how it loads and boots, and what kinds of specifics are necessary to fit customized configurations to particular collections of hardware (motherboard, CPU, chipsets, devices, peripherals, and so forth). My only beefs against the site are its “sink or swim” approach to organizing and presenting information and providing guidance to newbies, and the incredible amount of information through which interested parties must work to find the items of greatest interest and relevance to them. But when compared to the treasures and wisdom so liberally scattered around its collection of goodies, those are pretty minor beefs indeed.
You simply must check it out! http://www.boot-land.net/forums/
As I’ve learned to build various types of bootable CDs and UFDs with the Vista-based WinPE environment, I’ve also been working to learn more about its inner workings and capabilities. As I struggled to figure out how to add Windows Explorer and some kind of Web browser to a runtime WinPE image (which usually takes the form of a Windows image file named boot.wim or something similar) I discovered what might not unfairly be called the “ultimate Windows PE resource.” It’s a Web site that serves a very active and capable developer and user community called VistaPE.
Let me explain what makes VistaPE tick first and foremost, then explain what VistaPE has to offer. The foundation for VistaPE is a scripting and Windows build tool called WinBuilder. It works from either Windows XP or Vista to create boot disks (and in fact, incorporates WinPE 2.0 for Vista into the Vista side of that equation), but it goes way beyond what the basic Microsoft toolkit provides via imagex.exe and the other basic elements in their toolbox. VistaPE builds on this foundation to add significant applications and capabilities on top of the WinPE 2.0 kernel to support a more-or-less complete graphical user interface (GUI) environment. Thus, the VistaPE runtime environment–which is incredibly user-configurable and flexible, and continuously extended and expanded upon through a growing script library–is more like a “real Windows” than a basic command line interpreter (CLI) environment.
Here’s how I found VistaPE: In seeking to extend my WinPE skills and abilities, I’d started trying to research methods to include Windows Explorer in the WinPE environment after reading several postings online that (a) mentioned this could be done and (b) finding no concrete details on exactly how to do so. My basic computer science training told me that it would require mapping out the code dependencies from within Explorer to determine what other DLLs and executable elements were required to make the program run. I quickly discovered thereafter that some DLLs must be registered with Windows as well as present in the runtime environment to work properly, after a simple analysis with Mark Russinovich’s dllist utility failed to produce the desired results. That’s what led me back on the research trail and, ultimately, to the VistaPE Web site.
I knew I’d struck paydirt when, after downloading and installing WinBuilder and the VistaPE script library, I was able to produce this screenshot:
As it turns out, adding Explorer just barely begins to describe what VistPE can do within WinBuilder. It also provides an alternate and somewhat more functional graphic file system interface tool called BS Explorer 2, and even supports the Linux-inspired Grub4DOS boot management toolset.
But beyond the VistaPE Base toolset shown in the preceding screenshot, please note the other major checkbox elements in WinBuilder’s left-column pane:
- Addons: scripts and settings for common WinPE components (WSH, MDAC, HTA, WMI, and XML), plus a GUI for diskpart.exe, common dll-based libraries for Visual Basic and more, Internet Explorer 7, PE’s network configuration tool (PENetCfg), and lots more.
- Drivers: drivers required for chipsets, LAN interfaces, storage devices, and standard VGA graphics.
- Tweaks: elements to enhance the user interface, control various applications, manage graphic shells,…
- App: add-ins for a huge library of basic applications from antivirus, to file compression, to data recovery, and a great deal more.
- OtherOS: access to other OS tools and environments for multi-boot setups.
- Finalize: tools use to complete the construction of a Windows image (.wim) file from all the preceding VistaPE scripts (which include binary code as well as assembly instructions, so you can add executables right into the boot.wim base image)
- Virtual Test: lets you load and run your Windows image file in a virtual machine to see how (and if) it works as you want it to.
- Debug: used to mount and inspect .wim files and edit Registry hives to check and fix problems.
To me, VistaPE is an entirely new and wonderful world of capability and functionality that cries out for more study and improved understanding. I’ve already been able to use it to build much more powerful and capable boot images than I had been able to hand-craft on my own. But I can also see that there’s a great deal more going on here than immediately meets the eye, or falls readily into my grasp. If you dig into this environment, you’ll come to the same realizations equally quickly yourself. Please check it out soon!
Since December 2007, Microsoft has offered a Windows Service Pack Blocker Tool Kit to organizations that wish to prevent deployment of service packs in their environments. Blogging for the Vista Team Blog, Microsoft Windows Communication Manager Matt LeBlanc indicated on 1/29/2008 that this tool will soon relinquish its ability to block XP SP3 and Vista SP1. The expiration date for XP SP3 is 5/19/2008 and for Vista SP1 is 4/28/2009, each 12 months to the day from the original release of those service packs, and each in keeping with the tool’s stated ability to block current service packs up to 12 months after their release dates. After these dates, these SPs will be available directly from Windows Update.
With Vista and Windows Server 2008 shortly to become the focus of a shared SP2 release (currently guesstimated for April, 2009), this tool retains its capability and may be used to block or defer installation of this new SP for up to 12 months after its eventual general availability date. The Blocker offers admins three different ways to manage Service Packs:
- An MS-signed executable that manages a Registry Key (in HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate) to block or allow Windows Update delivery of a current SP.
- A script that works like the MS executable except that it allows the admin to supply the name of a remote machine where the block/unblock operations may be performed.
- An administrative (.ADM) template that permits admins to import GPOs to block or unblock delivery of SPs into a Group Policy environment.
As Microsoft observes in connection with the Blocker “this toolkit will not prevent the installation of the service pack from CD/DVD, or from the stand-alone download package. This simply prevents the service pack from being delivered over Windows Update.”
For environments where more time is often needed to test and accommodate SPs, the Blocker can be a handy tool. As long as admins understand it does not last forever–in fact, a year from the SPs general availability date is as much leeway as it can provide–the tool can be a useful element in their Vista, XP, and Windows Server 2008 toolbox.
Hey! It seems that not all the latest Vista new and information is completely negative. According a recent Red Hat Newsblog entry RHEL 5.1 Offers Customers New Features and Capabilities dated 1/20/2009, Vista support has been substantially beefed up in this latest release of RedHat’s flagship OS offering.
According to additional coverage of the release at InternetNews, RHEL 5.3 includes the following Vista-oriented updates and fixes:
- Updates and improvements to the built-in Samba environment, which provides support for the Server Message Block (SMB) protocol used for Microsoft network file access and other communications.
- Updates to the Common Internet File System support in RHEL 5.3, so that Linux can work as a client with Windows Servers.
- Although the current version does not include support for the Network Access Protection (NAP) mechanisms introduced with Windows Server 2008, Red Hat plans to add support for NAP in the next point release for RHEL (5.4) in another six months or so.
This could be good news for Vista administrators who must also work with Red Hat servers as part of their network infrastructure. And it’s also a refreshing change to see a company touting its support for Vista, when so much other coverage seems to focus on low adoption rates, plans to skip over Vista entirely for Windows 7, and other, similar “doom and gloom” topics.
TechARP, our regular source for Microsoft release rumors, has updated its estimated dates for Windows Vista SP2 release dates. As of last week, dates have slipped by at least one month. That means that the SP2 release candidate (RC) won’t be built until March, 2009, and also means that the RTM build originally scheduled for April won’t occur until May or possibly even June. Thus, launch must also be delayed until May or June as well “barring any further delays” as TechARP so sagely observes in this connection.
It’s also interesting to read current reports that Vista had a hand in recently lowered financial results/expectations for Microsoft, and thus also how Vista played a role in Microsoft’s recently announced layoffs for 5,000 of its employees. It should be interesting to see if the layoffs turn around and lead to further stretching on this already-stretched out schedule.
Hopefully, Microsoft won’t let these delays stretch out too far. Enterprise buyers already waiting for Windows 7 and planning to jump straight from XP to the newest desktop will surely take heart from any further schedule lapses, making Vista’s problematic status only more so.
I’ve just finished writing a story for Tom’s Guide on using a bo0table WinPE UFD, and doing the research for that story led me to a few interesting discoveries. First and foremost, no self-respecting Vista administrator should be without a bootable WinRE UFD–but perhaps, WinRE is more recognizable as the Windows Recovery Environment that you can fire up from the Windows Vista installation media.
It turns out, you can also follow my instructions on building a bootable WinPE UFD, and then use the imagex utility from the Windows Automated Installation Kit to capture the recovery environment Windows Image (.wim) file from your installation media. All you have to do then is swap the boot.wim file that my process creates in your ISO\sources directory with the boot.wim file that you export from your install media, and presto! you’ve got a WinRE console that boots in under two minutes, instead of having to wait three to five minutes for the same functionality to become available from the Vista installation DVDs.
Because I’m always messing with various Vista installs, I have to resort to the recovery environment at least once a week where I work. I’m guessing that busy system admins with any number of Vista machines to care for can beat that frequency with ease. In such cases, a bootable UFD with the WinRE console ready to hand can help save lots of wait time, and enable more “work time” on affected Vista systems.
Another, perhaps more esoteric use, might be on netbook PCs where disk space can be at a premium. I’m learning how to extend the WinPE environment to run other programs, including Windows Explorer (and some claim, even IE) from within the WinPE context. Because most simple Windows GUI apps (think items in the Accessories folder, as good examples of what this means) will already run in WinPE, it’s not hard to conceive that a somewhat extended WinPE environment could be workable for netbook users seeking to slim runtime system size to 0.5GB or smaller (by itself, the WinPE I describe how to build in my previous blog is about 367 MB in size; WinRE is less than 250 MB, but lacks network drivers and access).
As time goes by, I’m sure I’ll figure out some other cool uses for WinPE as well. If you know of any, please share them with me in the meantime!
Over the past week or two, I’ve been messing around with the Windows Vista SP2 beta. For a release with beta status, it’s amazingly stable, and some of the new functionality is welcome (burning Blu-ray media works as advertised, and indeed wireless connectivity is a bit easier and more straightforward). The update roll-up makes it much more convenient to build a new system: by my seat-of-the-pants comparison it shaves about an hour off the time required to get a new Vista system up and running, thanks mostly to cutting the number of updates required from 60-plus to less than 10. By the time Microsoft released the RTM version the first number will undoubtedly grow, and the second number will depend on the time lag between the RTM date and the public (RTW) release date.
Some interesting observations when building Vista SP2 systems, or doing an upgrade:
- Keep your drivers handy: although “normal Vista” finds and supplies drivers for all hardware components on my test systems, Beta SP2 somehow did away with some key elements, including network interface drivers, some mouse and keyboard drivers, and a few other odds and ends, mostly USB related.
- Use on several notebook PCs shows improved power management promises are true, but not excessively dramatic. I observed battery life improvements of about 20-55 minutes on various systems, right at or under the 10% improvement Microsoft promises.
- I read about but haven’t tested issues with Wireshark (WinPcap problems? Microsoft Monitor Driver, says VNUnet.com) related to an inability to capture dial-up or VPN sessions with this tool.
- Though MS claims SP2 requires fewer resources for and better performance from Windows Sidebar, I wasn’t able to observe a noticeable difference between “before” and “after” systems (though Task Manager does report lower memory consumption).
Recent rumors (see the update to TechARP ED#106) indicate that the SP2 release has slipped by one month, as MS hunts down some substantial bugs. Apparently that now means RTM in April or later, with release to Web about six weeks thereafter. Stay tuned! I’ll keep you posted as things develop.
Starting Up Windows Vista covers hardware startup, BIOS, POST, then bootstrap load via MBR, and takes you all the way through the boot-up process until the initial log-in prompt appears, after which the login process, services start-up, and the overal startup process completes. I learned a fair amount from this course, although the material was already 90% familiar to me, thanks to over a year’s daily experience in working with Windows Vista.
Here’s how the course lays out
- Starting up Windows Vista
- Windows Vista startup process
- BIOS and MBR (Master Boot Record
- Windows Boot Manager in Windows Vista
- Windows Vista OS loader
- Interoperation with earlier Windows versions
- Logging On to Windows Vista
- Overview of User Logon Process
- Process for computer logon
- User and Kernel modes of operation
- Process for initializing drivers in Windows Vista
- Process for starting services in Windows Vista
- Process for User Logons in Windows Vista
- Using Other Start Mechanisms and Startup States
- Windows Vista Preinstallation Environment (WinPE)
- Pre-boot execution environment and Windows Deployment Services
- How Windows Vista Starts Up from the Network
- Additional Startup States in Windows Vista
- How Windows Resumes from the Sleep State
- How Windows Resumes from the Hibernate Stare
- Using Windows Advanced Boot Menu Options
- Windows Vista Advanced Boot Menu Options
- What is Safe Mode in Windows Vista?
- What is the LKGC Option in Windows Vista?
- What is Boot Logging?
- The Low Resolution Video Opotion
- Guidelines for selecting Boot Menu Options
- Lab: Managing the Vista Startup Process
- Scenario & Exercise Information
- Troubleshooting Missing Startup Files
- Troubleshooting Missing OS Files
- Launch Labs/Lab Review/Module Summary
Microsoft told me it would take about two hours to work my way through the class, and they were right. By and large, most of the material was well-presented and made a reasonable amount of sense. I found myself visiting TechNet a few times throughout the class when the level of detail didn’t quite go low enough to help me understand what was going on (more information about BCDedit, and a demo on running various boot-time utilities would have worked better for me than their simulated labs, wherein the interface didn’t work properly, or perhaps just not as it said it should).
This is definitely a class for those interested in learning more about Windows Vista’s inner workings. Was it worth $40. Maybe: I knew enough of this material already that I found myself wanting more, but then I have already worked with all/most of the facilities covered in the modules for the class. Somebody just digging into Vista would undoubtedly find it useful and informative, particularly if their prior experience had all been with XP and previous Windows versions (the Vista boot environment includes some significant additions to and changes from previous versions).
All in all it was a pretty interesting experience.