“This guide contains technical reference, conceptual, and troubleshooting information for the Windows User State Migration Tool (USMT) 4.0”.
This just appeared in my inbox, regarding a new beta available on Connect:
“P2V Migration for Software Assurance uses the Microsoft Deployment Toolkit and Sysinternals Disk2VHD to convert a user’s existing Windows XP or newer client environment to a virtual hard disk then automates the delivery of an updated and personalized Windows 7 operating system containing a virtual machine with the user’s previous Windows environment, applications and Web browser. The user’s previous virtual desktop retains its existing management components, domain membership and policies. The process also publishes applications and the browser for the user to access them seamlessly within Windows 7’s start menu.
Help Reduce Windows 7 Deployment Times: The ability to perform P2V conversion of Windows XP or newer 32-bit systems as part of Windows 7 and/or 64-bit deployment means that IT organizations do not need to wait as long to get value from Windows 7. IT organizations will deliver the new Windows 7 operating system builds while preserving the old environments of a limited set of users that would otherwise delay production deployment.
Extend the Timeframe to Mitigate Application Compatibility: Using this solution, targeted users can have access to their previous set of applications, just in case something was not provisioned as part of the Windows 7 deployment. Accessing previous applications is also easy for end users, as those applications are published to the Windows 7 start menu.
Users can Access Incompatible Legacy OS Applications: Using this solution, targeted users can have access to their previous set of applications, just in case something was not provisioned as part of the Windows 7 deployment. Accessing previous applications is also easy for end users, as those applications are published to the Windows 7 start menu”.
Folks, this summer the following products will be end of life, i.e. no support of any kind for the following products:
- XP SP2 – upgrade to a newer service pack
- Vista RTM – upgrade to a newer service pack
- Windows 2000 – upgrade to Windows XP SP3 or later, Windows Vista SP1 or later, or Windows 7
- Windows Sever 2000 – upgrade to Windows Server 2003/2003 R2/2008 or migrate to Windows Server 2008 R2.
Go to the Microsoft product life cycle site for precise details.
For the server replacement, I’d strongly consider you look at moving to an x64 server operating system. Making the jump now will ease future upgrades. A few notes:
- Microsoft hates upgrades because they are messy. Problems are inherited/created.
- You cannot upgrade from x86 to x64 or vice versa.
- You cannot upgrade from a full installation to a core installation.
- You need the correct licensing for the server and the CAL’s.
- Check application compatibility.
- Test, test, test and verify with application/hardware vendors before making changes.
KB976002 describes what operating systems will receive a choice of Internet browser and how this process will work. This will bring Microsoft into compliance with the much discussed demands of the European Union on this subject. Affected OS’s are:
- Windows XP Service Pack 2 and Windows XP Service Pack 3
- All editions of Windows Vista
- All editions of Windows 7
- Future versions of the Windows client operating system that are released within the duration of the agreement with the European Commission
Some more information on the process can be found on Stealth Puppy. I’ve not seen the update yet but it appears to be delivered by Windows Update. If you don’t have Windows Update enabled then I guess you don’t get a choice.
If you are running tightly controlled corporate PC’s then you’ll be glad to hear that you can prevent the update from being deployed via WSUS/ConfigMgr/etc. You can also use the registry, according to KB2019411 (and therefore group policy) to prevent the update from executing:
- Key: HKLMSoftwareBrowserChoice
- Value: Enable (REG_DWORD)
- Possible settings: Enabled = 1, Disabled = 0
As was first reported by people on SANS and the Microsoft Answers forum, the cause of the MS10-015 blue screens of death was actually malware called Alureon or TDSS, i.e. a root kit that was already on the machine and had damaged it. The update legitimately updated the system and the root kit failed, causing a blue screen.
This highlights a few things:
- Get your anti-malware installed and keep it up to date. AVG has a free product. Avast has a free product. Best of all, Microsoft Security Essentials is also free. Microsoft’s free anti virus would have protected those people who were impacted. Their business product would have protected those business users.
- 64-bit computers have a built in process that defends system files. They were not affected. Walk into a PC store and have a look at the Windows 7 PC’s. I bet you all (not the netbooks maybe) are running a 64-bit edition of Windows 7.
- This situation was a great story for Microsoft Answers, the forum aimed at supporting the consumer. This was where consumers raised awareness of the problem, Microsoft responded with a workaround, and they could gather information to identify the cause.
- Make sure your patches are kept up to date. Configure Windows Updates on home/small office PC’s and use WSUS/ConfigMgr to manage updates in the business/enterprise. Quite often, these malware attacks leverage vulnerabilities that MS would have released patches for quite some time before.
By the way, Microsoft Windows lets you know of issues in the System Notification area (bottom right) with a red shield. That allows you to quickly get at a tool to view your security setup where any update or configuration problems will be highlighted.
Microsoft have explained the issue in depth. The long and short of this one was that people did not defend their PC’s adequately. Free tools that were marketed and advertised would have protected those people. Take the time now to check your PC and your security settings.
I came home tonight to see reports of blue screens of death and failed boot up/reboots for XP machines that had installed the MS10-015 security patch or hotfix. There is a long thread on Microsoft Answers.
After installing the patch you have to reboot. You are then greeted with:
STOP: 0x00000050 (0x80097004, 0x00000001, 0x80515103, 0x00000000).
The posted fix by Microsoft in the thread is:
- Boot from your Windows XP CD or DVD and start the recovery console (see this Microsoft article for help with this step). Once you are in the Repair Screen..
- Type this command: CHDIR $NtUninstallKB977165$spuninst
- Type this command: BATCH spuninst.txt
- When complete, type this command: exit
There is what appears to be some misinformation or hysteria about this. For example:
- Some news articles are claiming that Windows 2003 and Vista are reported in this thread as being affected. I saw no mention of those operating systems.
- I saw one article (a random find) that tried to make it look like that this affected Hyper-V. Pah! It does not from everything I have read. There are no reports of issues with Windows Server 2008 or Windows Server 2008 R2. Put the Kool-Aid down and step away from the cup.
I cannot claim there are not problems there but they are not in that thread.
EDIT: Overnight after this blog post was originally written, some people did post about Vista and W2003 suffering issues with blue screens caused by the update.
It is bad that a patch has affected many. I’m sure MS will be making someone feel very uncomfortable overnight about this. It’s bad that it happened at all. But let’s face it. Not everyone is affected. There is some combination in factors that is contributing to the blue screen. There is some scenario that MS didn’t test or couldn’t predict. These things happen. It could be some niche piece of software or driver that reacts badly to the patch.
EDIT: I’ve read on one site that some people are finding an issue with the ATAPI.SYS file not looking like the genuine file supplied by MS. They suspect an old malware issue causes an incompatibility with the fix!!!
This situation (whatever the actual cause of the blue screens) is why I think people like Steve Reilly who preach that we should all push out security updates immediately and without question are wrong for me (maybe not wrong for you). How many zero day exploits have there ever been? Not many. Think of the big bad attacks … Nimda, SQL Slammer, MS Blaster, Conficker. They all attacked vulnerabilities that were fixed with patches long before hand. What’s a couple of weeks? It’s because of the rare occasion when a patch goes wrong that I run a 3 phase process for patches.
I have three groups in WSUS. I configure my Windows Update agents either via group policy (AD members) or registry edits (.REG files for workgroup members) to be members of 1 of 3 groups:
- Testing – contains VM’s with various blends of OS and application
- Management – Our production AD, management systems, and online applications
- Hosting– Hosted customer servers
We’re a hosting company. WSUS has an automatic approval policy for the Testing group. The machines in that group are VM’s on my Hyper-V lab server. They patch in the late morning/early afternoon (around lunch) so we can see how they reacted.
Ideally that group would contain samples of the various bits of hardware you have on the network to include drivers in the mix. I was lucky enough to be able to do that with one employed in the past – but we did push out updates in less than a week from release. However, I need to be cost conscious and that is not an option now.
When we’re happy we sit and watch the news. If all is well, change control happens, and then we approve the updates for the management network. Stealing a line from Microsoft, we eat our own dog food. Over the 3 nights of the following weekend (Friday, Saturday, Sunday), machines are patched and reboot automatically. Some services are clustered/replicated and we do them on different nights or time slots. We have scheduled scripts on the OpsMgr RMS to put machines into maintenance mode.
Now we watch how that went and continue to watch the news wires. If there’s no more problems then we approve the updates for the hosting customers after another change control process. Patches then deploy according to their pre-agreed time windows.
The end result is that within 2-3 weeks all security updates are deployed. You could compress this down to a week. We are totally minimizing the risk of being stung by a “bad” update. Like I said earlier, MS probably did test the update as far as is realistically possible. There is always the chance that something bad happens.
Steve Reilly’s argument was that if you get a bad update then you call easily rollback your server farm because it’s probably 90% virtual. In my opinion you shouldn’t really use snapshots in production on Hyper-V. They’re supported but they suck the life from your VM’s. DPM or 3rd party solutions that are using the Hyper-V VSS writer are cool for this. But really, do you want to risk your production network going down for hours while you recover (starting at 3am when your patch failed) because of the rush to deploy an update that will likely not have an attack vector for quite some time?
Weigh the various risks and make an informed decision for yourself. Maybe Steve Reilly’s approach to push out updates without testing is right for you. Maybe my phased and cautious approach is. Maybe there is a middle ground that you prefer. Do the research and be sure you know why you make your decision and that it is based on fact.
There is strong suspicion that the BSOD’s are actually happening on machines that were already infected by a rootkit called TDSS. It attacks ATAPI.SYS and replacing that file appears to fix the BSOD issue as well. Microsoft Security Essentials appears to be able to detect it.
Do you want to use an older version of IE on Windows 7? You cannot install an older version natively; you have to use IE8. Compatibility mode may fix most things but there’s possibly that LOB application that won’t play nice. You can do things like get the app vendors to update it (maybe they are gone, maybe it takes too long, or will cost too much). You can run an older generation OS on Terminal Services.
However, a tidy way to do it is to use XP Mode and use the older versions of IE that will run on XP. The shortcut can be published to the Windows 7 start menu to make it easy to use for the end user. We showed this and explained this scenario in some of the Windows 7/Server 2008 R2 launch events in Ireland. I put it together at the last second in the Dublin events as one of the speakers talked about the scenario … yeah we were that “seat of the pants” and we reacted to questions being asked. Flexibility rules.
Ben Armstrong (product manager AKA the Virtual PC Guy) blogged how to do this. It is very easy.
Many people will be (or have already done it) making the jump from Windows XP or Windows 2003 to Windows 7 or Windows Server 2008 R2. Home users and small businesses will have been using NTBackup and will now face a new Backup and Restore tool that uses VHD instead of .BAK files. So how do they restore an old backup?
“Utility for restoring backups made on Windows XP and Windows Server 2003 to computers that are running Windows 7 and Microsoft Windows Server 2008 R2”.
Microsoft released lots of updates for Operations Manager over the last couple of weeks. There are lots of updates to management packs, too many for me to go posting them at this time of night. Have a look on the catalogue and you’ll see them. Or check your console if you’re using OpsMgr 2007 R2.
Most importantly is KB971541, Update Rollup for Operations Manager 2007 Service Pack 1.
“The Update Rollup for Operations Manager 2007 Service Pack 1 (SP1) combines previous hotfix releases for SP1 with additional fixes and support of SP1 roles on Windows 7 and Windows Server 2008 R2. This update also provides database role and SQL Server Reporting Services upgrade support from SQL Server 2005 to SQL Server 2008.
The Update Rollup includes updates for the following Operations Manager Roles:
- Root Management Server, Management Server, Gateway Server
- Operations Console
- Operations Management Web Console Server
- Audit Collection Server (ACS Server)
- Reporting Server
The following tools and updates are provided within this update which may be specific to a scenario:
- Support Tools folder – Contains SRSUpgradeTool.exe and SRSUpgradeHelper.msi (Enables upgrade of a SQL Server 2005 Reporting Server used by Operations Manager Reporting to SQL Server 2008 Reporting Server)
- Gateway folder – Contains a MSI transform and script to update MOMGateway.MSI for successful installation on Windows Server 2008 R2
- ManagementPacks folder – Contains an updated Microsoft.SystemCenter.DataWarehouse.mp which requires manual import
For a list of fixes and tools addressed by this update rollup, see KB971541.
This update is supported for application on System Center Operations Manager 2007 Service Pack 1 only.
The System Center Operations Manager 2007 SP1 Rollup 1 contains:
- All binary hotfixes released since Service Pack 1 release
- Support for Windows 7 and Windows Server 2008 R2
- Operational and DataWarehouse database support on Windows Server 2008 R2
- Additional stability hotfixes”
- Supported Operating Systems: Windows 7; Windows Server 2003; Windows Server 2008; Windows Server 2008 R2; Windows Vista; Windows XP
- System Center Operations Manager 2007 Service Pack 1
This update must be applied to each computer that meets the following criteria:
- Hosts a Microsoft Operations Manager Root Management Server
- Hosts a Microsoft Operations Manager Management Server
- Hosts a Microsoft Operations Manager Operations Console
- Hosts a Microsoft Operations Manager Web Console Server
- Hosts a Microsoft Operations Manager Reporting Server
- Hosts a Microsoft Operations Manager Manually installed Agent
- Hosts a Microsoft Operations Manager ACS Server
Before applying this update it is strongly recommended that Operations Manager databases, Management Server, Report Server and Web Console roles be backed up.
To extract the files contained in this update and installation of the update on the Operations Manager roles above:
- Copy the file – SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI – To either a local folder or accessible network shared folder.
- Run the file – SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI – locally on each applicable computer that meets the predefined criteria.
You can run SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI from either Windows Explorer or from a command prompt.
- Select the appropriate role to update from the Operations Manager 2007 Software Update dialog.
NOTE: To run this file on Windows Server 2008 you must run this file from a command prompt which was executed with the Run as Administrator option. Failure to execute this Windows installer file under an elevated command prompt will not allow display of the System Center Operations Manager 2007 Software Update dialog to allow installation of the hotfix”.