Archive for February, 2011
Today’s post is from David Trupkin, Sr Product Manager from our Windows Virtualization Team.
As I’ve talked to IT pros at events around the world, many of you have told me that the biggest barrier to your Windows 7 deployments has been incompatible legacy applications. These applications may run on Windows XP or they might be browser-based applications that run in Internet Explorer 6 or 7. While many older applications just work in Windows 7, some may require compatibility shims. Others may require upgrades or patches. You may decide to replace some applications or retire them altogether. For those applications that are left – the ones that simply must run on Windows XP – you should know about Microsoft Enterprise Desktop Virtualization (MED-V) 2.0. MED-V bridges the “last mile” of application compatibility between Windows XP and Windows 7, allowing older applications to run inside Windows XP compatibility workspaces but integrate seamlessly into your users’ Windows 7 environment.
Don’t confuse MED-V with Microsoft’s consumer and small business compatibility tool, Windows XP Mode. MED-V expands on the capabilities in Windows XP Mode by adding enterprise features such as the ability to use a custom Windows XP image, automated first time setup, control of Internet Explorer URL redirection, automatic network printer mapping and easy packaging for enterprise distribution. MED-V version 1, first released in 2009, was based on a client-server model and required dedicated management servers. MED-V version 2, in Release Candidate status now and due for release before the end of March, 2011, is based on an application model which eliminates the need for a dedicated server. You can deploy and manage MED-V 2.0 with your existing software distribution management tools, like System Center Configuration Manager (SCCM).
Let’s spend some time looking at MED-V 2.0 and its requirements. On the client, the MED-V Host Agent installs on Windows 7 Professional, Enterprise or Ultimate with a minimum of 2GB RAM and will support either x86 or x64 architectures. At least 10 GB of disk space is recommended, although you may use more or less disk space depending on your particular workspace image and combination of applications. You’ll also need to deploy WVPC and WVPC KB977206 (which allows WVPC to run on systems without hardware-assisted virtualization) to systems that do not have them installed already.
MED-V Workspace Packager lets you package your Windows XP virtual machine for use as a MED-V workspace. The documentation included with the Workspace Packager will guide you through the process of:
•Preparing your Windows XP image
•Creating a MED-V Workspace package for deployment
•Testing and deploying your MED-V workspace
•Managing applications and software updates within MED-V and
•Managing MED-V settings after deployment
Often, you’ll deploy a management agent such as the SCCM client inside of your MED-V workspace to allow for application distribution and update along with patch management. The SCCM team has provided a client hotfix, to be installed on your SCCM SP2 Site Server, which improves SCCM functionality when you’ve configured your MED-V workspace to use network address translation (NAT). The hotfix allows a MED-V workspace that is also an SCCM client to use the same SCCM site and distribution point assignment as its host.
Once you’ve created your MED-V workspace package you’ll have a MED-V Workspace Package – a standard application file set that’s ready to deploy. You’ll find:
•A .medv file that is a compressed copy of your workspace VHD file and
•An .msi installer
You can create installation tasks within your software deployment tool to install MED-V and its prerequisites together, or you can create separate tasks that deploy the individual components. If you are using SCCM, you can create packages and a Task Sequence to install the MED-V and WVPC components.
In this sample batch script for MED-V component installation, the MED-V components are installed in inverted order, allowing the installation to complete with a single reboot. There are two things to keep in mind about this batch script. First, while the MED-V Client installer and MED-V workspace package installer will detect if they are running on an x86 or x64 system and will install the appropriate “bitness”, the WVPC update and associated hotfix are specific to x86 or x64 systems. Second, the MED-V installation will not be complete until the system is restarted.
REM install the MEDV Host Agent
start /WAIT msiexec /i MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
REM install the MED-V workspace package
start /WAIT .\setup.exe /qn OVERWRITEVHD=1
REM Install Windows Virtual PC (this example is for Windows Virtual PC x64)
start /WAIT Windows6.1-KB958559-x64.msu /norestart /quiet
REM Install Windows Virtual PC update (this example is for the x64 version of the update)
Windows6.1-KB977206-x64.msu /norestart /quiet
Here are command line examples for creating packages within SCCM:
•MED-V Host Agent
•msiexec /i MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
•MED-V workspace package
•WVPC installation (Note: This example shows the x64 version of WVPC. If installing within a Task Sequence, use “Run Command Line” instead of “Install Software” to avoid a reboot at this step.)
•wusa.exe Windows6.1-KB958559-x64.msu /norestart /quiet
•WVPC update (Note: This example shows the x64 version of the update. If installing within a Task Sequence, use “Run Command Line” instead of “Install Software” to avoid a reboot at this step.)
•wusa.exe Windows6.1-KB977206-x64.msu /norestart /quiet
Once MED-V 2.0 and Windows Virtual PC have been deployed, and any necessary reboot completed, the MED-V First Time Setup runs and legacy applications published from MED-V are available in the Windows 7 Start menu. Legacy web based applications or sites defined by the MED-V administrator are seamlessly redirected to Internet Explorer 6 or 7.
For more information on MED-V 2.0 and to try it yourself, register on Connect and check out the MED-V 2.0 Release Candidate today and for a complete library of information on MED-V, App-V, VDI and other desktop virtualization solutions, visit the Desktop Virtualization Zone on the Springboard Series on TechNet.
Great post over on the Remote Desktop Services Team Blog.
We are busily writing and publishing Step-by-Step guides to help you explore the new features of Remote Desktop Services included with Windows Server 2008 R2. Below is a list of the guides that are currently available. Please check back often, as we plan on publishing more documentation in the coming months.
What’s New in Remote Desktop Services
Installing Remote Desktop Session Host Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=147293
Web version: http://go.microsoft.com/fwlink/?LinkId=147292
Deploying Remote Desktop Web Access with Remote Desktop Connection Broker Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=131928
Web version: http://go.microsoft.com/fwlink/?LinkId=131927
Deploying RemoteApp Programs to the Start Menu by Using RemoteApp and Desktop Connection Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=154799
Web version: http://go.microsoft.com/fwlink/?LinkId=154798
Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=154800
Web version: http://go.microsoft.com/fwlink/?LinkId=154801
Deploying Virtual Desktop Pools by Using RemoteApp and Desktop Connection Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=154803
Web version: http://go.microsoft.com/fwlink/?LinkId=154802
Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=147908
Web version: http://go.microsoft.com/fwlink/?LinkId=147909
Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=147907
Web version: http://go.microsoft.com/fwlink/?LinkId=147906
Deploying Remote Desktop Gateway Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=142251
Web version: http://go.microsoft.com/fwlink/?LinkId=142250
Deploying Remote Desktop Licensing Step-by-Step Guide
Word document download: http://go.microsoft.com/fwlink/?LinkId=128418
Web version: http://go.microsoft.com/fwlink/?LinkId=141175
Driver management is always an interesting topic, I typically have some links that I give to people to read on the subject. I’ve found that that list has grown over the years. So this post is meant to be a compilation of links on the subject. If you have additional information, please ping me and I’ll get them added here to this post:
Microsoft Deployment Toolkit:
Driver Management Tag on my blog:
Microsoft has created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .
You can get the update here: http://support.microsoft.com/kb/2023591
Here are some things you should be aware of:
- Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
- Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
- If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
- This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.
The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.
Also Michael Niehaus has a blog about the release of this KB that are of note.
A new hotfix for USMT 4.0 was released today to support migrating Office 2010 settings. (It includes other fixes too.) You may want to download this and integrate it into your deployment processes. The full instructions for doing this (including what needs to be done with MDT and ConfigMgr) are included in the KB:
There is one complication that you should be aware of if you are using ConfigMgr and moving from Windows XP or deploying Windows XP. USMT 4.0 uses a set of manifest files to determine what needs to be migrated from Windows XP. These manifest files are stored in the “DLManifests” folder, which is part of your USMT package in ConfigMgr. There is an issue though where Scanstate.exe can’t find this DLManifests folder when run from ConfigMgr. In MDT 2010 Update 1, we included a workaround for this, copying the folder where Scanstate can find it:
‘ Workaround for USMT bug in Windows 7 AIK
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" then
oUtility.RunWithHeartbeat "cmd.exe /c xcopy /iesryhd """ & sUSMTPath &"\DlManifests"" """ & oEnv("SystemRoot") & "\system32\DlManifests" &""" 1>> " & oLogging.LogPath &"\zticopyUSMT.txt 2>>&1 "
Notice that this checks specifically for build 6.1.7600.16385 of Scanstate.exe, the version released in the Windows 7 version of Windows AIK, as we expected this problem to be fixed in the next version of USMT. Well, it wasn’t. But once you install the KB 2023591 hotfix, the version changes to 6.1.7601.21645 and our fix stops working.
You can work around this by fixing the fix, to read like this:
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and (oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" or oFSO.GetFileVersion(sFoundScanState) = "6.1.7601.21645") then
If you aren’t using ConfigMgr or don’t have Windows XP around any more, you won’t need to worry about this.
This came from the myITforum SMS email distribution list. Credit to Richard Benfield for figuring this out and posting the solution to the mail list.
Here is the long and short of getting the SCCM vNext VHD Test Drive to work for Native VHD Boot:
1) Download the SCCM vNext VHD Test Drive from the following link (Note it is over 9.5 GB so it will take a while):
2) Download the VHD Resizer from the following link and install it:
3) Download all of the appropriate (Server 2008 x64 compatible) drivers for your model system.
4) Extract the contents of the SCCM vNext VHD Test Drive (Note the vhd is 20 GB, so it will take a while)
a. You only really need the two .\*.mht files and the .\Virtual Hard Disks\*.vhd file
5) Decide what size you want the VHD to be. (The actual used space is about 25 GB and you won’t want to cut it too close)
a. I decided on 50 GB for my use.
6) Use either the “Disk Management” console or the “Diskpart” command-line utility to shrink the volume in the VHD
a. You will need to attach the VHD, select the larger volume of the two, shrink it to the desired size minus 100 MB, then detach the VHD
7) Run the VHD Resizer and change the VHD to Fixed and the size listed for “Min” (again, this will take a while)
a. FYI, it sat there for a long time appearing to do nothing. I was convinced it wasn’t working and may not be compatible with 2008×64, but eventually it started cranking away.
8) You may want to move and rename the VHD. (I renamed mine SCCMvNext.vhd and moved it to C:\VHDBoot\)
9) Use the process described at the following link to copy the Windows 7 or Server 08 default BCD entry and point it to your VHD file.
10) Either change your systems SATA mode to ATA in the BIOS or inject the appropriate Mass Storage Controller Driver in the VHD image.
11) Boot up and choose the new boot entry from the menu.
12) Login and install the drivers…
That’s pretty much it, at that point you have a Windows Server 2008 R2 x64 Native VHD Boot system with SCCM vNext preinstalled on it for testing/demos…
Someone had some questions about Hyper-V today and this link was given. WOW. Talk about the mother load of information!
This is a list of Hyper-V resources you can add too, and feel free to rearrange. Just click the "Edit" button above the article. For organization ideas, and other important links, see:
Microsoft Virtualization Community, because virtualization at Microsoft involves a lot more than Hyper-V.
Recently has some internal discussions around these two items. I wanted to post the information for others to find so they don’t have to “dig” for it as we had to. The specific questions at hand were:
1) For a thin client, can we push software to a Windows Embedded Standard 2009 system while leaving WPF lock in place?
2) Can we use OSD to deploy the HP Thin State Client (Linux) to a system?
Here are some key points around these topics:
- The supported ConfigMgr client platforms are at http://technet.microsoft.com/en-us/library/cc161860.aspx.
- Quest has a client for Unix Systems.
- Johan Arwidmark – Deploying Ubuntu 8.04.1 using WDS (Windows Deployment Services)
- For ConfigMgr 2007, the XPe topics are actually documented right in the ConfigMgr 2007 product documentation. Start with http://technet.microsoft.com/en-us/library/bb932159.aspx.
- Customers will also need to use XPe’s Target Designer to build their XPe image with all necessary pre-requisites to install and run ConfigMgr client. The following download contains the XPe macro component for ConfigMgr client. If the customer is not authorized by their hardware vendor to build their own images, they will need to request this be done by their hardware vendor.
System Center Configuration Manager 2007 Service Pack 1 has reached the end of its service pack support date
I just wanted to send a quick reminder that System Center Configuration Manager 2007 Service Pack 1 has reached the end of its service pack support date:
Note that per the Lifecycle Policy:
The Microsoft Support Lifecycle policy requires that the product’s supported service pack be installed to continue to receive support (including security updates).
Note new Service Pack Lifecycle Support Policy effective April 13, 2010: http://support.microsoft.com/gp/newSPlifecycle
Service Pack Support Policy
- When a new service pack is released, Microsoft will provide either 12 or 24 months of support for the previous service pack
- Support for the previous service packs is either 12 or 24 months, varying according to the product family (for example, Windows, Office, Servers, or Developer tools)
- Support timelines for service packs will remain consistent within the product family
- Microsoft will publish specific support timelines for a previous service pack when the new service pack is released
- When support for a service pack ends, Microsoft will no longer provide new security updates, hotfixes or other updates for that service pack. Limited break/fix troubleshooting will continue to be available, as described below.
- When support for a product ends, support of the service packs for that product will also end. The product’s support lifecycle supersedes the service pack support policy
Customers are highly encouraged to stay on a supported service pack to ensure they are on the latest and most secure version of their product. For customers on unsupported service pack versions, Microsoft offers limited troubleshooting support as follows:
- Limited break/fix support incidents will be provided through Microsoft Customer Service and Support; and through Microsoft’s managed support offerings (such as Premier Support).
- There will be no option to engage Microsoft’s product development resources, and technical workarounds may be limited or not possible.
- If the support incident requires escalation to development for further guidance, requires a hotfix, or requires a security update, customers will be asked to upgrade to a supported service pack.
Have a great week!
Erin Williams | Product Quality Program Manager
Note: The section titled How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point was updated with two additional steps (19 and 20) on 1/6/2011.
This is a general guide on properly setting up and troubleshooting the System Center Configuration Manager 2007 (ConfigMgr 2007) PXE Service Point.
Common errors that are seen at the PXE boot screen when the PXE Service Point is either not configured properly or experiencing problems are the following:
PXE-E53: No boot filename received
PXE-T01: File not found
PXE-E3B: TFTP Error – File not Found
PXE-E55 Proxy DHCP Service did not reply to request on port 4011
However the error messages can vary depending on the PXE implementation on the client PC. Another common symptom is that the Windows Deployment Services Server (WDS) service will not start.
To resolve these issue and to prevent them from occurring in the first place, follow the guide below This guide is broken down to the following sections:
- Setting Up IP Helpers
- How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point
- Reinstalling WDS And The PXE Service Point
- Testing The PXE Service Point
- Monitoring And Troubleshooting The PXE Boot
The guide is written in chronological order of the actions that need to be taken properly get a ConfigMgr 2007 PXE Service Point working and operational. Refer to the appropriate sections as needed.
Where else to find great articles but on the ConfigMgr Support Team Blog
We always seem to get a lot of questions regarding how to configure Configuration Manager 2007 for the best performance and while we’ve had this information published in TechNet for a while I thought it would be worth a mention here. Whether you’re setting up ConfigMgr 2007 for the first time or you have an implementation that’s been up and running for years, you’ll probably find something valuable here:
The topics in this section provide performance recommendations that are the result of testing scenarios based on data processing for a central site, with the maximum number of 200,000 supported clients in a Configuration Manager hierarchy, and 2 child primary sites, with the maximum number of 100,000 supported assigned clients each in a Configuration Manager site.
For more information about capacity planning for Configuration Manager site systems, see Configuration Manager Site Capacity Planning.
Note : This is not a complete listing of every feature and function implemented during performance testing but rather an example of general performance testing objectives. For more information about common Configuration Manager 2007 performance related questions and sample configurations, see the technical whitepaper at http://go.microsoft.com/fwlink/?LinkID=113136.
- Assigned clients were divided between 2 child primary sites with each supporting 100,000 assigned clients.
- 200 boundaries were defined to manage client site assignment.
- Computer collections for these sites were created ranging from 1,000 clients to 200,000 clients.
- Client hardware inventory, including asset intelligence data, was collected (for both full and delta inventory report information).
- Client software inventory was collected (both for full and delta inventory report information).
- Active Directory discovery methods were used both for computers and for users.
- The heartbeat discovery method was enabled.
- Software distribution performance was tested using 100 distribution points with software distribution advertisements targeting 2,000, 60,000, and 200,000 clients.
- Software metering was implemented using 1,000 software metering rules.
Before performance testing began, to obtain realistic performance metrics, the Configuration Manager site database was populated with a representative set of Configuration Manager objects.
For each primary site, supporting 100,000 clients, the database size was approximately 40 GB after the initial Configuration Manager object data was imported into the site database.
To continue reading see Configuring Configuration Manager Sites for Best Performance.
J.C. Hornbeck | System Center Knowledge Engineer