We have less than three weeks till we kick off our next European tour! Be aware, seating is limited, so if you have not registered, you will want to do so soon before all the remaining spots are taken.

What can you expect at our five-hour free Tour Workshops?

• Learn about Office 2010 key IT investments.
• Learn about fast and easy deployment  and application compatibility strategies and tools for Windows 7.
• Learn about virtualization tools and techniques for Windows, Office and Internet Explorer.
• Gain a clear understanding of the tips and tricks you need now to jumpstart the successful deployment and management of your Windows desktop environment today.
• Meet and network with members of the Windows and Office US Product Teams, as well as local Microsoft Technology Evangelists for technical training, professional networking, and real world guidance.
• All attendees will receive a 16GB USB key with a copy of our Proof Of Concept kit.(The PoC is a virtual hard disk that can be installed to a server for the deployment., It is a set up and ready to go environment with trial versions of Windows 7 Enterprise, Server 2008, Office 2010 and all the tools like MAP, MDT, ACT, OEAT that you will need to test your applications in a live environment as well as a great sandbox to test your pilot and deploy strategies.)
• The first 150 registered attendees who attend each event will receive a certificate to download a free RTM copy of Microsoft Office 2010 Professional. (The certificate will given out at the end of each days event)

This is a great opportunity to learn, network and get your Windows 7, MDOP, Office 2010, and Server 2008 R2 deployments on track and moving forward.

So, where will we be?

Amsterdam, Netherlands	Monday, 25 October
Stockholm, Sweden	Wednesday, 27 October
Helsinki, Finland	Friday, 29 October
Reading, UK	Monday, 1 November
Rome, Italy	Wednesday, 3 November
Vienna, Austria	Thursday, 4 November

To reserve your spot or learn more about the tour, visit Springboard Series Tour. See you all very soon!

Steady State was designed to work with Windows XP and Windows Vista, and was a really popular toolkit because it made it easy to do things like automatically  discard all changes to a system that users may have made on the PC, lock down the desktop to control what Windows applications a user could use as well as control what Windows settings that users might be able to change.

Think about a large group of PCs that might be used in a public library. Because these PCs are accessible for use by anyone, you probably wouldn’t want users to be able to change the desktop appearance, reconfigure system settings or install unauthorized applications or malware, or add documents or files to the system. Windows Steady State made it quick and easy for admins to define the types of controls they wanted to place on what  users could do, as well as to completely reset the desktop to a pristine state later.

A Windows 7 version of Steady State was not created and we’ve heard loud and clear from IT Pros that this is something they wanted and needed.  After we evaluated the types of functionality Steady State provides, we found that using new Windows capabilities that are built into Windows 7, Group Policies and free tools from Microsoft, the majority of Steady State functionality could actually be replicated by IT admins.

We have just released a whitepaper along with an accompanying document that describes Group Policy settings that you can use to configure computer and user settings and also a reference excel worksheet which can be used to look up and filter the settings described in the whitepaper.

We think that most customers will be able to take advantage of this set of whitepapers  reference guidance to recreate the Steady State experience.

• Creating a Steady State by Using Microsoft Technologies
• Group Policy Settings for Creating a Steady State
• The Steady State Reference Spreadsheet

Visit the Manage Windows 7 Zone on the Springboard Series on TechNet for more information on how to lock down and manage Windows 7 in your environments.

Let us know your thoughts – enjoy!

Amsterdam - 25 Oct | Stockholm – 27 Oct | Helsinki – 29 Oct | Reading – 1 Nov | Rome – 3 Nov | Vienna – 4 Nov

The Microsoft Get On the Bus Tour is taking a winter hiatus to bring you a new tour – the Springboard Series Tour: Microsoft Windows, Office and MDOP Deployment Workshops!  Amsterdam marks our first stop on a 6-city European tour, en route to TechEd Europe, in Berlin, Germany. Are you looking to plan, pilot or deploy Windows and Office? Our workshops will cover the Office 2010, key deployment strategies for Windows 7, the Microsoft Desktop Optimization Pack, as well as show you the value of getting trained and certified in these key products.

Learn why Windows 7 has received rave reviews from IT organizations and is setting records as the fastest selling operating system in history, and find out why so many IT Pros are ready to deploy Office 2010. Give us five hours, and you will have a clear understanding of the tools, tips and tricks you need now to jumpstart the successful deployment and management of your Windows desktop environment today. Come join members of the Windows and Office US Product Teams, as well as local Microsoft Technology Evangelists for technical training, professional networking, and real world guidance. Don’t miss your chance to attend one of these free workshops in the 2010 Springboard Series Tour, rto learn more or to register, visit www.springboardseriestour.com.

Get your Tour updates first! Follow us on Twitter, @MSSpringboard

The Springboard Deployment Learning Portal is an online assessment and learning tool, designed to help IT Pros identify their knowledge strengths and information gaps around Windows 7 deployment.  Based on interactive assessment responses, the participant is provided targeted learning to help them gain critical deployment know-how, keeping them at the top of their game. 

The Springboard Windows 7 Learning Deployment Portal is designed to guide IT Pro’s deployment education by:

• Enabling individuals to measure their proficiency and knowledge against key benchmarks
• Identifying specific skills gaps or areas of weakness to address
• Create personalized learning plans through direction to resources based on the areas and scope of knowledge gaps
• Provide informal knowledge checks through learning and re-assess areas initially identified as knowledge gaps
• Recognizing critical Windows 7 deployment skills and helping to build IT Pro confidence to deploy Windows 7

The Deployment Learning Portal content and methodology helps to bridge the gap between Springboard’s online managed experience content and formal training.

What languages will it be available in?

• Windows 7-Bereitstellung: Lernportal (German)
• Portal de aprendizaje para implementación de Windows 7 (Spanish)
• Portail de formation au déploiement de Windows 7 (French)
• Windows 7 ??????? ???? (Japanese)
• Il portale di distribuzione di Windows 7 (Italian)
• Windows 7 ?? ?? ?? (Korean)
• Portal de Aprendizagem sobre a Implantação do Windows 7 (Portuguese)
• ??????????????? ?????? ?? ????????????? Windows 7 (Russian)
• Windows 7 ?????? (Chinese- Simplified)
• Windows 7 ???????? –(Chinese- Traditional)
• Windows 7 Deployment Portal

It requires a separate registration and login process other than the Windows Live login process used by TechNet, allowing us to understand portal usage by locale and assessment scores.

All the training modules were created by the team that wrote the Windows 7 certification exam, including Preparing Your Deployment, Configuring a Windows 7 Image, Migration and Compatibility Testing.  At the end of each module the user will receive learning recommendations based on their score, these recommendations direct IT Pros to the most relevant resources across Springboard, MS Learning and TechNet, and provides next steps to certification. The Springboard Series Deployment Portal can be accessed here.

A little (recent) history…

In Fall of 2009 there was a perfect storm of tools and automation to enable something I have wanted to do for some time, automate local physical-to-virtual migration of a Windows client machine and redeliver and integrate that old environment within a new Windows build using full automation. The pieces we had in November 2009 were:

1. Sysinternals Disk2VHD
2. Virtual PC with shell integration
3. RemoteApp hotfixes for Windows XP SP3 and newer clients
4. Microsoft Deployment Toolkit 2010

At that point, the ingredients were fundamentally there to get everything working. In the Spring another valuable component came online to enable Virtual PC on machines without Hardware Assisted Virtualization. With all of these components in place, it was time to glue everything together and get it working end-to-end. Being a deployment guy, I’ve always been a fan of task sequencing engines and I knew that MDT could do everything I needed to configure the right things at the right times and drop the right components needed in the process.

Michael Niehaus and I had a working prototype in December, but before I could proceed any further, I had to look into the licensing and activation implications of doing this. Since we are transferring the install from one PC to another (even though it is a “virtual” PC), OEM-installed copies of Windows cannot be P2V’d, as they do not allow for a transfer to another PC. Retail copies of Windows (for example, if you buy a full Windows DVD copy from your local retailer) allow for a transfer from one computer to another. Software Assurance and Volume License (VL) media enables a couple of things for this: the right to create custom desktop images, the right to run up to four additional virtual clients for PCs covered with Software Assurance, and the Volume Activation on VL-media-based copies of Windows to ensure that end-to-end automation works without prompting for reactivation after the system has been P2V’d. In Windows XP VL media for instance, the activation remains in a valid state after P2V and in Windows Vista and newer VL media, we can use the Key Management Service to automatically reactivate after P2V. Non-VL installs will require reactivation. These rules apply to all P2V operations of Windows client operating systems, whether the tools come from Microsoft or third parties.

In parallel to looking at these issues, I worked with Mark Russinovich to get some additional needed features built into the Disk2VHD tool. Mark added command line scriptability, a generic mass storage driver for Virtual PC, and finally a fix to boot.ini on Windows XP systems that prepare them for use with Virtual PC with a new default boot entry while keeping old configurations with the previous boot entry. At this point Disk2VHD is now in version 1.62 and several of the point releases were made to enable local P2V migration with Virtual PC as the VHD viewer.

MDT 2010 Update 1 development was in full swing until the update released in July and we were working on additional requirements to get the solution supported when finished. At that point, we formalized the project under the moniker of “P2V Migration for Software Assurance.” The “for Software Assurance” part in the title isn’t because we are gating the tool’s downloadable content to Software Assurance customers, it is more of an indication of when P2V is a legitimate practice for Windows client operating systems and when the automation will work end-to-end, which then in-turn means what is tested and will be supported.

The refresh process at the PC looks just like what I announced originally to the MDT Connect community last week and these are probably the best images I have to explain what happens:

If you want to see a video of how to get it working with a demo of the machine I used to capture the images above, check out the video blog we just posted on TechNet Edge (skip to about 12 minutes in to see the client experience).

While everything was fully-automated and working for the in-place computer refresh scenario for many months (where the virtual machine is captured on the same machine we install Windows 7 on), the computer replacement scenario (where we retire the first PC and transfer the VHD and user state to a new PC) and System Center Configuration Manager support needed to be built. That is roughly what we’ve been working on since MDT 2010 Update 1 shipped in July. The current Beta has support for the Refresh and Replace scenarios without Configuration Manager at the moment; another Beta release with Configuration Manager documented/working and better international support is coming in the coming days. The same video above shows what you need to do to get it working if you already have a Microsoft Deployment Toolkit environment running. Once you install P2V Migration, the task sequence option is just a drop down like the others included in MDT:

You just need to build a new task sequence and select one of the new entries for P2V migration – replace or standard – used like the normal MDT template task sequences and try it out on a client with Windows XP SP3 or newer operating system.

What are the limitations?

This process has a few limitations. First, you probably shouldn’t be using this on more than a handful of blocking desktops. The best way to deliver a standardized local Virtual PC environment to many users is to use Microsoft Enterprise Desktop Virtualization. It enables provisioning and management of much lighter weight VMs, lets you manage how links are published to applications from the VM, redirect URLs to the VM’s browser and back, start the VM when the user logs into the physical machine, etc. It also requires that you know about and manage the applications going into the VMs. Where P2V Migration comes in is where you don’t have the source media, don’t want to include rarely required apps into a standard VM (all this applies to Internet Explorer customization as well). For that handful of users with highly-specialized and otherwise deployment-blocking PCs, you can target them for P2V Migration.

The biggest technical limitation is Virtual PC’s maximum VHD size. Virtual PC cannot use a VHD container larger than 127GB – that means even if the P2V’d system was consuming 10GB of disk space for example or I made the Windows partition with 10GB on a 160GB or larger hard disk, we still cannot boot into it using Virtual PC. This is documented on the Sysinternals Disk2VHD site and in the solution documentation. The other main issue will be using non-VL media Windows on the starting system. It will break the automation and require reactivation in the VM after you convert it to a VHD. This is the same with all P2V tools whether from Microsoft or third parties – you need a qualifying version of Windows to do this without stopping the automation and requiring reactivation. The Release Notes document additional limitations, many of which are in scope for a future Beta release in the coming days.

Where to Download P2V Migration

P2V Migration for Software Assurance is available on Microsoft Connect in Beta 1 form. As with any Beta, we are looking for people to run this through its paces and test the P2V scenarios integrated with their MDT and/or System Center Configuration Manager deployment environments. Uptake has been good so far, but more testing will ultimately bring a higher quality release.

1. Migrating from Windows Internet Explorer 6 on Windows XP to Internet Explorer 8 on Windows 7: Strategy, Standards, and Support - As organizations deploy Windows 7, many still depend on web applications that were designed for Internet Explorer 6. Will they still work, and what can you do when they don’t? On Sept 30th, join a panel of IT Professionals, Microsoft specialists and technical experts to discuss best practices to simplify and accelerate the migration to Internet Explorer 8. Topics will include an explanation of the causes of and solutions for application compatibility issues (including policy, code, and virtualization solutions), an introduction to tools, and a review of best practices. Send us your questions to be discussed on the show to vrtable@microsoft.com.
2. Internet Explorer 8 Application Compatibility List for IT professionals - The Internet Explorer 8 Application Compatibility List for IT Professionals is a Microsoft Office Excel-based spreadsheet listing software applications which are compatible or not compatible with Internet Explorer 8, based on public support statements from software publishers, or statements made to Microsoft from software publishers. This list will be updated on a regular basis.
3. Addressing Application Compatibility When Migrating to Internet Explorer 8 - Many corporations are still relying on Internet Explorer 6 based web applications that have been built and customized over the past decade. Organizations planning to deploy Windows 7 need to have a comprehensive strategy and an execution plan in place to migrate legacy web applications to Internet Explorer 8. This document provides IT professionals a detailed overview of Internet Explorer 8 compatibility issues and discusses remediation strategies for migrating web applications, while providing an introduction to tools and processes. Watch for the companion developer piece coming to MSDN soon!
4. Internet Explorer local URL lockdown restriction - This screen cast shows how you can lock down Internet Explorer 6 or greater to only browse to the URLs you specify.  This is most commonly used when you are virtualizing IE 6 or 7 for legacy applications and using IE 8 or greater for your primary browser which is not locked down
5. Solving Enterprise Application Compatibility Issues with Internet Explorer 8 (Part 1 of 2) and (Part 2 of 2) - By far, the single largest obstacle to deployment of Windows Internet Explorer 8 for many organizations is the 10 years of accumulated Web applications that may have a dependency on Windows Internet Explorer 6. How big is the problem really? How can you address it using best practices gleaned from Microsoft Enterprise Services engagements with other enterprise customers? In this video, we explore the workflow, the tools to leverage through this workflow, and the remediation techniques Microsoft Enterprise Services has used with other large customers to successfully navigate the application compatibility challenge.
6. Internet Explorer Virtualization with MED-V - Learn how you can utilize MED-V to virtualize your web applications which require Internet Explorer 6 or 7 in your environment. If your organization is considering an upgrade to Windows 7 or Internet Explorer 8 but is concerned about the expense, time, and IT staff effort needed to update your older (or legacy) LOB web applications, using a virtualization option might be a an effective solution until you can run your web applications natively with IE 8.

The Task Sequencer… the Key to Thin and Layered Images

There are always critical innovations marking the fundamental turning point when things go from being painful to usable, for automated deployment this is the task sequencer. Some might argue drive cloning tools were the turning point and they were definitely important, but all of the stuff you need to do before and after a cloned drive is applied can take even more work. Think about it, you’re gathering system information, validating the install itself will work, backing up data that needs to be reapplied later, moving in and out of Windows PE (Preinstallation Environment), joining a domain, adding/removing applications after the OS is laid down and restoring the data you backed up in the beginning. With only drive cloning tools, this would work well on factory floor with all hardware and builds being equal, but once you start throwing variables at it, you need task sequence automation. Conversely, you could have full control and do this manually, spending about 4-5 hours per desktop where there is data and personalization… or strip out steps in the process… or keep your control and automate the whole thing and more.

We have quite a few things we can use to automate pre and post Windows installation routines. Some will script it all pretty heavily and just use an unattend.xml file to automate the Windows setup portion, others will seek more extensible ways. Thankfully, the pioneers of task sequencing pooled resources at Microsoft and the fathers of what used to be Automated Deployment Services (ADS) and Automated Provisioning Framework (APF) got together and built a shared task sequencing engine for System Center Configuration Manager. A free version of this engine is also in the Microsoft Deployment Toolkit (MDT). I can remember a time when there were half a dozen extensible task sequencing engines for deployment-related tasks buried in various Microsoft products and Solution Accelerators around 2005, but the major ones share the same core and therefore it is easier to move from MDT to Configuration Manager and back. Let’s see what a deployment task sequence normally looks like:

MDT Deployment Task Sequence

As you can see from the task sequence, these are all the steps you’d take to migrate a user from an old operating system to a new one. I had to paste together two UI images to show everything in the sequence (which explains the curious-looking scroll bars), but you get an idea of everything that needs to happen. This is a default MDT task sequence, so you don’t need to figure all of this stuff out yourself – just populate the deployment share and go. Without this, the scripting to do everything is possible, but would be a nightmare to get everything right. For those who do figure it out and build it all via scripts or build their own task sequencing mechanism, the major benefits are typically job-security and knowing precisely how everything works, but it will take way longer to reinvent a wheel that has already been invented and is officially supported (even in the free MDT version). If you want to save time and achieve a good and customizable outcome, then you can use the task sequencer in Configuration Manager or MDT.

The reason why the task sequencer is the key to thin and layered images is because it can dynamically install packages (aka language packs and updates), inject necessary drivers and install or uninstall applications to/from the core image. What that means is that you can keep a lot of this stuff out of your core image and apply only what is needed just-in-time at install time. Since WIM files are file-based and offline-serviceable, you can inject components into a mounted image or in the case of deployment automation, steps at the right time in the process can install these components for you.

You can manage drivers and put your faith into plug-n-pray play IDs (which seem to be getting more reliable in general) or if you want complete control, you can assign drivers based on hardware make/model queries. The only image you really need to pack additional non-in-box in are Windows PE images and full OS images in cases of the occasional unexpected NIC or mass storage driver requirement (tip: look out for in-box RAID requirements on client hardware).

Beyond drivers, we can also change the operating system language before first logon, Windows Updates, add things like Virtual PC and importantly we can install applications which are not needed by every user. All of these things support the goal and vision of a single, dynamically composable image, respecting user and hardware-specific needs at install time. You might think this is really hard to build, but this is how MDT and Configuration Manager are intended to be used out of the box in their default configurations and task sequence templates.

Thick or Thin Images – Which are Better?

If there ever was a religious debate on imaging the top theme would be about “thick vs. thin imaging.” Answer: It depends. There are always instances where thick images will make more sense: manufacturing, cases where EVERYONE needs an identical build and set of applications, where one language is spoken, etc. In almost all other cases, it will make more sense to have something that can be configured at deploy time. If you feel the need for speed and that is your biggest concern, then thicker imaging can be faster, but you can get creative with it; have your build automation uninstall unnecessary applications and migrate user state. The tools are there and can do anything you want them to do before and after the core image is applied. Most will use a combination of both thin and thick, a “hybrid image”, and follow the 80/20 rule to pack in the essential and infrequently changing applications that 80% of the user population needs, the other 20% can be applied as-needed at install-time.

If you were paying attention in the last blog, you read that I was thinking about the similarities between thick file-based images and sector-based images. Assuming you equate all thick images to monolithic things that include all drivers, updates, and applications, then the decision criteria around sector-based imaging is roughly equivalent to that of a thick file-based image (By the way, they don’t need to be thought of like this, because thick file-based images can still be serviced offline and both sector and file-based can be customized with build automation). I think a number of people do think like this, because the most frequently asked imaging question I get is “How do I use ImageX and related tools like the drive imaging tools I’m used to using?” If you are using some of the newer versions of sector-based tools that incorporate Volume Shadow Copy service and can run online, then I will say that using an imaging tool which requires you to boot into Windows PE or a similar environment to capture an image is more difficult in general, but tools like MDT will generate the Windows PE environments, run sysprep and do everything else for you to capture a “golden” or “reference” computer for cloning.

Tool Recommendations for Imaging

With all of the imaging options put forward, I can start to materialize them into real recommendations. There is nothing really “new” or “revolutionary” here, a lot of it is common sense. As I talk with more and more desktop administrator friends, I also find that the reason many of the processes exist as they do out there is because of tradition and the whole “it’s good enough” syndrome. I’m not buying that excuse though, and once they tell me the user needs to send their machine to a lab for a day and either be without a computer or use a loaner; a tech needs to visit the user’s desk with a pre-imaged hard drive and screwdriver (and maybe ask the user to backup what data they want to keep beforehand); or the other all-to-common taboo deployment practices – I know there is a better, more-automated way that doesn’t take someone like Mark Russinovich to learn and master.

If you do need a UI for everything, it’s there in System Center Configuration Manager and MDT. As a comment to the first blog post highlights, some IT guys have an aversion to Command Line Interfaces (CLIs). I tend to do whatever is fastest and that means I’m in CMD or PowerShell quite a bit. If you want to customize things beyond in-box functionality, create rules, manually operate DISM.exe or ImageX.exe in CMD, you can and it usually makes sense to know what the tools do by themselves, but to answer that original commenter about use of CLIs, you don’t need to go into a CLI to get everything working – that is actually the point of MDT in relationship to the Windows Automated Installation Kit’s command line tools. Some might argue that people in IT roles with an aversion to CLIs highlights a bigger issue, but that is another topic for another blog post I probably won’t be writing.

What all that in mind, let’s take a look at when different imaging methods make sense. I enumerate three common approaches. “Traditional Thick Sector-Based Images with Limited Install-time Customization” essentially means what most people are doing today – building a reference computer with a bunch of applications and available drivers, then hopefully using Sysprep and capturing. “File-based Images with Build Automation for User and Hardware Customization” is the process where a typically thinner, file-based image is used alongside heavy deploy-time build automation to customize the environment as needed by the user or hardware. “Thick File-based Images used like Traditional Sector-Based Images with Limited Install-Time Customization” is related to options one and two, where one is comfortable with the first approach and would like to retrofit that somehow to the file-based imaging tools because they are offline-serviceable and free (aka the frequently asked “How do I use MDT like Ghost?” question). On the vertical axis are the common and up-and-coming desktop service architectures and considerations.

Desktop Environment Type / Image and Build Type	Traditional Thick Sector-Based Images with Limited Install-time Customization	File-based Images with Build Automation for User and Hardware Customization	Thick File-based Images used like Traditional Sector-Based Images with Limited Install-Time Customization
Thick local client environment with user and region-specific applications, local user state and variance in hardware	No	Yes	No
Completely homogeneous environment for all users (no local user state, one language, draconian hardware standardization) – either physical or hosted	Yes	No	Yes
Thin client hardware environment with main user desktop environment hosted in the datacenter	Yes	Yes	Yes
Datacenter-hosted user-specific desktop environments	No	Yes	No
OEM Computer Manufacturing Process	Yes	No	Yes
Any Combination of the Environment Types Listed in This Column	No	Yes	No

“It depends” is the right answer again. If you look down the left column and identify your environment type, then you can see which imaging types and build automation levels make the most sense. There are also shades of grey with everything and there will also be debates about sysprep usage in hosted desktop environments where all hardware is defacto identical as a virtual machine, but that would warrant another complete blog in itself. If your environment looks like a combination of two or more items in the left column, then you should definitely be looking at file-based imaging with build automation.

Basically anything that might cause unnecessary image sprawl should drive the conversation for a move to more build automation and file-based images. Image sprawl tends to multiply if you use sector-based images and have hardware, region, language and user-specific customization to contend with. Sometimes these factors are not even in your control; some governments for example don’t allow use of certain wireless frequencies others may not allow hard drive encryption or Trusted Platform Modules in hardware, etc. If this sounds like you and you want to send the same image to your OEM provider that you use with your deployment servers, then you’ll typically need use composable builds that change dynamically based on environmental variables.

I think most people will fall into the “Thick local client environment with user and region-specific applications, local user state and variance in hardware” at the moment. If the visionaries are right and virtual desktop infrastructures, stateless PCs and “the cloud” is indeed the future of desktop computing, then my table covers most of those scenarios as well. I did set out with a goal here to get you thinking about your current imaging approaches and considering other approaches if you are using thick, sector-based images now for deploying Windows. In some cases, sticking with what you have might be the best option for you, but I think that will be the exception rather than the rule – especially if you want to save time and enjoy automating complex processes with things that aren’t really that hard to use; but I’ll let you decide.

Thanks for reading,

Jeremy

Windows Deployment

I want to be true to real feedback and experiences here and the definition for ImageX in the TechNet Library kind of does that, but it also doesn’t really highlight the benefits of sector-based images. This is a pros and cons article and I’ll start with the Microsoft-defined benefits (or “pros”) of the file-based imaging tool, ImageX then move to sector-based images. The “cons” are really described in the paragraphs as I explain the “pros” – I’ll save a nice table comparing everything for the next and last post in the series.

Benefits of ImageX

The limitations of sector-based imaging led Microsoft® to develop the ImageX tool and the accompanying Windows image (.wim) file format. You can use ImageX to create an image, to modify the image without extracting and recreating the image, and to deploy the image to your environment. Because ImageX works at the file level, it provides the following capabilities:

• More flexibility and control over the deployed media.
• Rapid extraction of images to decrease setup time.
• Reduced image size due to "single instancing", which means that the file data is stored separately from the path information. This enables files that exist in multiple paths or in multiple images to be stored once and shared across the images.
• Non-destructive image application. The ImageX tool does not perform an all-inclusive overwrite of the contents of your drive. You can selectively add and remove information.
• The ability to work across any platform supported by Windows.
• Two different compression algorithms, Fast and Maximum, to reduce your image size further.
• The ability to treat an image file like a directory. For example, you can add, copy, paste, and delete files from a file management tool, such as Windows Explorer.

Many OEMs and corporations need to deploy and install Windows as rapidly as possible, including all relevant updates, applications, and settings. Reduced deployment and installation time lower manufacturing costs for OEMs, and can decrease cost and scheduling risks for corporate deployments.

Is all of this really so one-sided though? Let’s look at each of the bullets individually and see what a typical naysayer would respond with.

• More flexibility and control over the deployed media. 
  • I actually agree with this one, but… you do need some expertise in creating the deployed media and figuring out stuff like how to inject drivers real-time to make sure the hardware you’re targeting installs as desired. Truth is if you haven’t been sysprepping and are creating an image per hardware class or HAL, then ImageX will build an image that will install on like hardware or HAL as with the sector-based tools you might be using. Problem with that is that you can’t guarantee those images will move from device-to-device. The file outputted by ImageX is also serviceable offline, so you can mount it like an ISO file and start adding or removing stuff from it. The Windows 7 image files even have providers to enumerate drivers, packages (updates, hot fixes and language packs) and features – so you don’t need to do things like mount registry hives and add files then change registry values – offline servicing does that work as part of the process.
• Rapid extraction of images to decrease setup time.
  • This isn’t really a fair comparison with the sector-based tools. I’ve seen sector-based images come down and apply quite quickly. Where the time savings are really visible here are when you compare a WIM-based setup or apply versus an unattended setup with the good ‘ol “I386” folder in Windows XP source media. Even though Windows XP Pro x86 source media is a paltry 600MB or so compared to Windows 7 Enterprise media of 2.25GB, Windows 7 will usually install faster – you wouldn’t think that was possible with almost three times the file size, but try it. So if a retail image from the Windows 7 DVD takes about 20 minutes to install, Windows XP might take 25 minutes on the same hardware, but I’ve seen sector-based images lay down in 15 minutes or less with a sysprep specialization pass included. Speed is actually the key advantage of the sector-based image, so I’ll actually give this bullet to the sector-based imaging side.
• Reduced image size due to “single instancing”, which means that the file data is stored separately from the path information. This enables files that exist in multiple paths or in multiple images to be stored once and shared across the images. 
  • That’s a mouthful, isn’t it? I don’t see this as a real advantage unless you are appending image WIM files to a master WIM file. Windows 7 Ultimate media has up to five images in the same WIM file and we can select the SKU we install based on the image index number we apply with ImageX. That helps in cases where you may be using multiple image and appending them together (might make sense in multi-language environments or when you have a mix of Professional and Enterprise), but if you have a standard set of apps for every user, they all get an X86 image and they all have drivers we manage, then there really isn’t a huge need to append image files. We’ll call this benefit then a wash for most customers.
• Non-destructive image application. The ImageX tool does not perform an all-inclusive overwrite of the contents of your drive. You can selectively add and remove information. 
  • Now we’re talking! If I apply a sector-based image to a drive with data, that data is gone. “Yeah, but I like to format my drive anyway to ensure a ‘clean install’.” That’s fine, but if you need user data from the drive you’re applying the sector-based image to, be prepared to deal with the laws of physics and bus and network speeds to pull that data off the drive and then eventually put it back on. That means refresh and break/fix rebuild scenarios just got several hours longer in many cases. Now if I use a WIM file, I can apply it to a drive with data on it – yes, it’s true. That means I keep the user data on the same volume I am applying the WIM image to – or in other words save those hours of time it took to move the data off. “But won’t the drive be fragmented when we’re done?” Maybe, it will defrag itself once a week and we can force one if we really want to when we’re done. 
    
    If it helps, think of the outcome you might get if you used Robocopy to apply the entire set of operating system image files with their attributes to a hard drive with files and folders already present. Then why doesn’t Robocopy by itself work? What if I was willing to give up the compression and single-instancing that ImageX and WIMs give me? I was on this great email thread a few months ago with two personal heroes of mine, Michael Niehaus and Mark Russinovich. We were trying to figure out the best way to move files from a larger VHD container to a smaller VHD container. Robocopy will keep file attributes and almost do this but it doesn’t handle short filenames (aka 8.3 filenames) in all cases. So let’s say I have a “jeremy~1.xml” and a “jeremy~2.xml” file, it’s possible that Robocopy will reverse those and turn “jeremy~1.xml” to “jeremy~2.xml” and vice-versa during the file copy. NTFS file systems have had native support for long file names for many years, but there are still many applications that will rely on short filenames and we don’t want to break any applications.
• The ability to work across any platform supported by Windows. 
  • A sector-based image isn’t really limited here either, sure the Boot Configuration Database (BCD) may need to be rebuilt and hooks into the Windows Recovery Environment re-established, but this can generally be done with either WIM file-based image installs or sector-based image installs. I’ll call this benefit slightly favorable to a file-based image though just because we can mount images across Windows client and server platforms and versions and peruse them using Windows Explorer or CMD.
• Two different compression algorithms, Fast and Maximum, to reduce your image size further. 
  • I’ve never put much thought to this feature and tend to select “Fast” – in somewhat thin image environments, I don’t see a huge difference in size. The compression in general is a great thing and helps keep the size of images and image repositories in check. Advantage goes to file-based images based on compression alone (and single-instancing if used), but I’m not seeing a lot of people overly excited about two different levels of compression.
• The ability to treat an image file like a directory. For example, you can add, copy, paste, and delete files from a file management tool, such as Windows Explorer. 
  • This is pretty cool. The image itself isn’t a black box file, so you can mount it and add or remove things in it. I’ve already written about this at length. To be fair, there are explorer tools for the common sector-based images to view image contents and sometimes extract individual folders or directories. These tend to work with the FAT and FAT32 file systems for editing – which is fine until you need to add something to an NTFS image. Most images from Windows XP forward are going to be NTFS, so the limitation to not add things to an NTFS offline image is a major limitation. It basically means you need to build the machine again, configure it and recapture. Not necessarily a fun or fast operation.
• What about benefits of a sector-based image? 
  • I’m not writing this blog to say that sector-based imaging is always bad. Like I always say, a good IT pro will answer just about every question with “It depends…” and this is no different. The thing I have been thinking about lately is how closely the advantages of sector-based images mirror those of thick images. Let’s explore the advantages of sector-based images.
• Sector-based images apply faster. 
  • I won’t disagree here, but many of the same factors apply to the sector-based image as the file-based image. How good is the network connection to the imaging server and NIC? How big is the image? Is there data to migrate and restore before and after the machine is (re)imaged? On bare metal installs, a sector-based image (or even a thick file-based image) is often going to be faster than a file-based image or a build that adds applications and other configurations outside of core image. This makes a lot of sense in manufacturing, bare metal installs where every machine needs the identical image and cases in companies where few languages are spoken and applications requirements are extremely static and consistent across all users in the company. The biggest problem is you can’t really service it offline, so builds and recaptures may be much more common than with thin or thick file-based images. That said, I’ll give the sector/thick file-based image the advantage in build speed.
• Sector-based images are guaranteed to work when moving from like machine to like machine. 
  • The sector copying process doesn’t really care about things like files, their attributes or whether they are corrupted. ImageX and copying mechanisms tend to be affected by irregularities with files in the image. That is good and bad. It ensures that captured and applied images have files in good states, but it won’t clone a system where you might be willing to live with files in a bad state. Backup and restore mechanisms need this quality and things like the Volume Shadow Copy service in Windows relies on this as well to capture a sector view of the machine, regardless of the state of the files. This does provide a sort of “guarantee” that it will work if it was captured on the same hardware.
• Sector-based images are good for cloning hard drives when replacing or moving to larger/faster hard drives.
  • I won’t argue that. ImageX was designed and scoped for imaging and not as a complete PC backup and restore mechanism. It assumes things like the PC to be captured is in a good state, isn’t domain-joined and has been prepared for cloning by sysprep. On the other hand, a sector-based tool doesn’t really care if the preparation steps have been taken, so you basically capture the image of any hard drive and apply that to another, resize partitions accordingly and you can replace or upgrade your hard drive (or keep it backed up). “Backup and Restore” in Windows 7 does a really good job of system and directory level backups on a machine-by-machine basis. This is actually a sector-based (and extremely thick) VHD image created using the Volume Shadow Copy service.
• Sector-based imaging tools have multicast and file-based tools do not. 
  • Wrong. I threw that in there because it is a perception like image application speed that people often wrongly assume. File-based images can be multicast, but your deployment server needs to be running Windows Server 2008 or Windows Server 2008 R2. Multicast capability was a huge differentiator for third party tools for a long time and I still hear people say it can’t be done with WIM files. Not true, it can and the Windows Servers that can do it often already exist in your environment, you’ve already paid for them and can use them, or they tend to be cheaper than third party image deployment servers with multicast capabilities (if you haven’t already acquired them).
• Closing thoughts for Part 2 of ‘Improving Your Image…’ 
  • I’ve written a bit more than I had planned in part 2 of the series, but I think it is valuable and hopefully you find it unbiased. You should start to see cases where file and sector-based images will make the most sense. Part 3 will be about build automation and I’ll build a table with recommendations for scenarios when sector-based, file-based thin and file-based thick images make the most sense. You can start to extract that from above and draw your own conclusions, but we haven’t really hit on the fun part yet of automation and task sequences. That stuff really changes the game and even if you are a good scripter and insist on using sector-based images for everything, there is a ton of value you can get from a task sequencer even when used for post-OS-install per-user customization. Stay tuned, I promise it will all be clear after part 3.

Goodbye for now,
Jeremy Chapman
Windows Deployment

Windows 7 will continue to enable the widest range of people across the world to use Windows in their own language by providing Language Interface Packs in over 55 languages. LIPs are built using MUI technology and provide translation of the UI (User Interface) most commonly used by Windows users. LIPs do not require a separate software license.  They are available to downloaded for free and installed on any edition of a Genuine copy of Windows 7: Starter, Home Basic, Home Premium, Professional, Enterprise, or Ultimate.

Because the entire UI is not translated, LIPs require that the base or parent language requirement be present on the machine before installation. After the LIP is installed and selected as the UI display language, the elements of the UI that are not translated into the LIP language will continue to be displayed in the base or parent language. Some LIP languages can be installed over more than one parent language. For example, the Catalan LIP can be installed over the Spanish or French language pack. The parent language requirements are specified on each LIP download center details page, and are also listed on the Windows Languages page here.

Here are some great resources to help you find out more about parent language requirements and language support for Windows 7, plus obtain step-by-step guidance on multilingual deployments:

• Download Languages for Windows 7
• Understanding Multilingual Deployments
• Planning MUI Deployments for Windows 7
• Windows LIP: Frequently Asked Questions
• Microsoft Local Language Program

The Windows 7 and Windows Server 2008 R2 SP1 Beta helps keep your PCs and servers on the latest support level, provides ongoing improvements to the Windows Operating System (OS), by including previous updates delivered over Windows Update as well as continuing incremental updates to the Windows 7 and Windows Server 2008 R2 platforms based on customer feedback, and is easy for organizations to deploy a single set of updates.

The Windows 7 and Windows Server 2008 R2 SP1 Beta will help you:

• Keep your PCs supported and up-to-date
• Get ongoing updates to the Windows 7 platform
• Easily deploy cumulative updates at a single time
• Meet your users' demands for greater business mobility
• Provide a comprehensive set of virtualization innovations
• Provide an easier Service Pack deployment model for better IT efficiency

The public beta is best suited for IT pros, tech enthusiasts and developers who need to test the service pack in their organization or with the software they are developing.

In order to download and install the Windows 7 and Windows Server 2008 R2 SP1 Beta you must currently have a Release to Manufacturing (RTM) version of Windows 7 and Windows Server 2008 R2 already installed. The Beta is available in English, French, German, Japanese and Spanish.

To learn more about piloting, deploying and managing Windows 7, visit the Springboard Series on TechNet.