Pretty nasty bug out there right now with 32-bit Windows 7 and Software Updates. If you are struggling with getting your clients to download/install updates. Check your WindowsUpdate.log, if you see the following error:
WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E
Then I’d strongly encourage you to apply the following KB/Hotfix (KB3050265).
Here is also a great article explaining what is going on from the ConfigMgr Team Blog. Read that article here.
After applying this update in my client environment, patches immediately started working again.
Nice to know: A simple branding kit for your Windows 7 deployment
Mon, 23 Jan 2012 23:40:16 GMT
Even if this is anything else but important, branding your OS could sometimes be needed for fun or for profit. The basic concept is to replace some of the images in Windows with your own corporate ones. This simple kit will change the logon UI, the background picture and it will add the OEM logo for the famous company ViaMonstra (The company that Johan Arwidmark and I use as a sample company when we write our books). Since everyone on this planet are using MDT to create your reference image you just import this as an application, modify the pictures and then add the application to the task sequence and create the reference image. Done!
The reason that I never posted this is that all the pictures are my customers, not mine. But then Johan Arwidmark started writing “Deployment Fundamentals Vol III”. That is about Deploying Windows 7 using SCCM (extended with MDT) we thought that branding would be fun to have in the book, and suddenly I was in the position to create graphics that we can use in the book. So now I have something to share, and here it is. The ViaMonstra Branding Kit!
Read the full post at the link above…
Ben Hunter has a new post over on The Deployment Guys Blog.
If you are using MDT Update 1 to deploy Windows 7 SP1 language packs then please pay attention, this post will save you time.
MDT 2010 Update 1 does not address the Enhanced Language Pack handling in Windows 7 SP1. This means that if you add a Windows 7 SP1 language pack to the workbench it will not appear in the task sequence wizard.
Thankfully the solution is fairly simple. You simply update the language handling function in the DeployWiz_Initialization.vbs script.
For details of the updates on how to make this update please see – http://support.microsoft.com/kb/2547191
This post was contributed by Ben Hunter, an Architect with Microsoft Services
If for some reason you don’t want to use Group Policy to disable the Windows 7 Action Center, then there is a registry key you can set to disable it.
Once the registry key is set to a value of “1”, certain items will be greyed out in the Action Center configuration, and you will no longer see the Action Center icon in the system tray.
There is a simple Group Policy setting for this as well, this is generally my preference, but I had a client who wanted to disable it in the image regardless.
User Configuration – Policies – Admin Templates – Start Menu and TaskBar – Remove the Action Center Icon
A "Set Network Location" dialog box appears when you first log on to a domain-joined Windows 7-based client computer
First download the KB from the above link. Once you have the files extracted out, we will need to import those updates into the Deployment Workbench.
Open up your deployment share, and then expand to the packages node. Right-click and select “Import OS Packages”.
Point the package source directory to the location containing the 2 hotfixes.
Once you have imported the updates. Create a new folder called “Windows 7”.
Move the updates into the Windows 7 folder.
Expand Advanced Configuration, then right click on Selection Profiles and select “New Selection Profile”.
Create a Selection Profile called “Windows 7 Hotfixes”.
Select the Windows 7 folder that we previously created.
Next we need to open our Windows 7 Task Sequence and expand “Preinstall”. Click on the “Apply Patches” step.
We need to change our selection profile to match the new “Windows 7 Hotfixes” Selection Profile that we created.
Now you can rebuild your reference image to include KB2028749 and eliminated the “Set Network Location” prompt.
Hope that helps.
An update is available that lets you add Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1 as supported platforms for Configuration Manager 2007 Service Pack 2
On a computer that is running Microsoft System Center Configuration Manager 2007…
On a computer that is running Microsoft System Center Configuration Manager 2007 Service Pack 2 (SP2), you have the following features:
- Software distribution
- Software update management
- Desired configuration management
However, the following products are not listed as supported platforms for these features:
- Windows 7 Service Pack 1 (SP1)
- Windows Server 2008 R2 Service Pack 1 (SP1)
Deployment master Michael Niehaus has created a nice post on Windows 7 SP1.
With the release of the Windows AIK for Windows 7 SP1 supplement (see http://blogs.technet.com/b/mniehaus/archive/2011/02/17/windows-aik-for-windows-7-sp1-released.aspx for details), there is a new version 3.1 version of Windows PE available. If you plan to install this update, you need to be aware of an issue when using this with MDT 2010 Update 1.
To explain the issue, first you need to understand the way the MDT boot image creation process works. Fortunately, I explained that almost two years ago (http://blogs.technet.com/b/mniehaus/archive/2009/06/27/mdt-2010-new-feature-7-boot-image-creation-optimized.aspx):
With MDT 2010, Deployment Workbench will look for a “boot.wim” file from one of the imported operating systems that has the same build number as Windows AIK (e.g. “boot.wim” from a Windows 7 RC, build 7100, operating system to go with the Windows AIK for Windows 7 RC). If it finds a match, it will use that WIM instead. Why do we do this? Because the “boot.wim” contains the Windows Recovery Environment (Windows RE), a component that isn’t available in Windows AIK.
That’s kind of high level, so let’s get a little more specific……
Nice post over on TechNet by “Joseph”, there are some great comments below the post as well.
I like to read about how Windows is affecting peoples lives, specifically, the servicing components. One of the common threads I noticed in my recent web trolling was the question “Can I delete the \Windows\Winsxs directory to save space?”. This is usually asked in conjunction with what the directory does and why its consumed the space it has, but I’ve already covered that in prior posts.
So, to answer the question, the answer is simply: No.
Why? Because the component store (\Winsxs) is needed to repair the OS binaries in the event that a file becomes corrupted or, in worst case scenarios, compromised. There are a few directories in the component store so let’s look at them and what their general role is in Windows.
1.\Winsxs\Catalogs: Contains security catalogs for each manifest on the system
2.\Winsxs\InstallTemp: Temporary location for install events
3.\Winsxs\Manifests: Component manifest for a specific component, used during operations to make sure files end up where they should
4.\Winsxs\Temp: Temp directory used for various operations, you’ll find pending renames here
5.\Winsxs\Backup: Backups of the manifest files in case the copy in \Winsxs\Manifests becomes corrupted
6.\Winsxs\Filemaps: File system mapping to a file location
7.\Winsxs\<big_long_file_name>: The payload of the specific component, typically you will see the binaries here.
So, can you delete these? Sure, you could I guess. What would happen? Well, it depends. So long as the files in the \Windows\System32 directory are valid, most likely you wouldnt see any problems initially, the machine would “most likely” operate properly. However, the first time you attempt to update a binary, apply a service pack or service a component, it’s going to fail because the backing components needed arent there. The way the files end up in \System32 are via hardlinks. This should help answer another common question I see regarding how VSS is used in servicing. Short answer: It’s not. We use NTFS hardlinks to project the file to the file system from the component store. That’s why the \Winsxs directory is so important. The files there can be seen as the “authoritative” versions on the file system. When you encounter an issue and that binary needs to be replaced, running an SFC /SCANFILE against it will check the directories above and if the version doesnt match, it will re-project it so that its working.
Here’s an example of how you can see the hardlink via CLI:
C:\Windows\System32\drivers>fsutil hardlink list ntfs.sys
This isnt the best overall example but its one I use often as a quick and dirty way to see the links in the OS. You can see that the NTFS file has a link to the \Winsxs directory and if that version of NTFS were to become corrupted, we could go back to the component store and find you a new copy. The backup directory in \Winsxs is there in the event that the version in that directory has also become corrupted. It’s a good way of having protection on the OS without consuming a huge amount of space.
Also, as Andre mentions in the comment below, its worth noting that the new servicing structure does remove the $NTUninstall$ folders that many people have become accustomed to from Windows NT to Windows 2003. Updates, if they are marked removable, no longer contain that structure. Instead, updates are recommended to be removed via the Control Panel –> Programs –> View Installed Updates path. You can remove the updates via the appropriate switches in DISM.EXE or PKGMGR.EXE, but the control panel method tends to be cleaner.
Hope that helps.
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.