Springboard Series Blog

New Windows 7 Application Compatibility List for IT Professionals

Stephen L Rose — Wed, 18 Nov 2009 06:32:00 GMT

Until now there were a couple of ways to determine if your applications were compatible with Windows 7 – you can test everything, look them up one-by-one in the Windows Compatibility Center, or inventory your production machines using the Application Compatibility Toolkit 5.5 and synchronize your inventory with hosted compatibility data from Microsoft and ISVs. For about a year, we’ve been posting regular updates to the Windows Vista Application Compatibility List for IT pros and even though compatibility between Windows Vista and Windows 7 is pretty high, there has still been huge demand for a Windows 7-specific list. If you already have a list or inventory of the applications you want to move forward in a Windows 7 deployment, the new Windows 7 Application Compatibility List for IT Professionals lets you download a spreadsheet of known vendor-supported applications so that you can query the list against your pre-existing application inventory. This list represents a sample of the total ecosystem focusing on top products as defined by customers and deployments with a public statement of support provided by the vendor.

As you can see, there is compatibility status listed for both 32- and 64-bit versions of Windows 7, plus each application’s major and minor version numbers are listed to help normalize your data queries. Since October (yes, last month) we have already collected more than 5500 applications and the list is growing every day. If you are working through a list of hundreds or thousands of applications, this list will help you validate your applications more quickly. We will be updating this list regularly, so keep checking back to avoid any unnecessary testing. Click here to download the spreadsheet and get started.

If you are in the process of testing in-house developed applications, download the Application Compatibility Toolkit (ACT) and use its in-box evaluators and test tools. Although we released ACT 5.5 back in April coinciding with Windows 7’s RC release, there were no changes needed to support the RTM version of Windows 7. Even though you will see an occasional “RC” in ACT’s reports, ACT 5.5 is the RTM-supporting version.

To access these and other application compatibility resources, check out the Springboard Application Compatibility Zone where we host the latest application compatibility content for Windows 7.

Jeremy Chapman
Windows Deployment

Need to prepare your end users for Windows 7?

Stephen L Rose — Tue, 17 Nov 2009 07:37:22 GMT

With Windows 7 now available to everyone, we are beginning to hear more and more requests from IT Professionals for content they can use to get their support teams and users up to speed on the end user features of Windows 7. We have spent a lot of time creating this content and you can find it various places like the Windows 7 Help and How To page, Springboard Series IT pro Tip and Tricks and the Microsoft Learning site, but we know there is a lot of content out there and you want a simple way to find it.

To help you find this information quickly and easily, we have updated the Enterprise Learning Framework (ELF) with content for Windows 7. ELF is a is a web based tool that helps corporations develop a training and communication plan for employees during a Windows 7, Windows Vista, and 2007 Microsoft Office system deployment. The tool helps you find content for three different audiences, Information Workers, Influential Information Workers, and Support. It also helps you find the right content for topics you are interested in, within particular deployment timeframes. ELF even gives you the ability to generate customized email messages or a Microsoft Office Word document that you can send to your users with all content you find.

The Enterprise Learning Framework is a great tool to help you prepare your end users and your support staff for Windows 7. You can find the tool here.

TechEd Berlin Wrap Up

Stephen L Rose — Fri, 13 Nov 2009 18:38:00 GMT

What an amazing week here in Berlin. We had over 60 sessions presented by over 80 different speakers on Windows 7 this week.

We had hundreds of people stop by our Springboard Series on TechNet booth and the Talking About Windows booth. Since we localize Springboard in 10 languages we had a cool time showing demoing the site in all of the different languages. I also want to give out a huge thanks to our STEP (Springboard Technical Experts Program) members who helped to work our booth. These amazing guys came from Ireland (Aiden), Bolivia (Miklos), New Zealand (Erdal) and the UK (Justin) to help support Springboard and Windows 7.

I even had a chance to be part of the Pre-Keynote. Check out the video of the bus arrival with keynote hosts Hyper-D and Hyper-T.

We met tons of IT pros excited about Windows 7 as well. We worked with a STEP member named Alex de Jong from the Netherlands. Alex asked the delegates at Teched EMEA about their Windows 7 experience. Alex contributes to NGN, the Dutch community of IT Pros. To learn more about Alex and all he does for the community, follow him on Twitter at @alexdejongngn. So ready to see the cool interviews and hear what over 100 IT pros from all over the world had to say about Windows 7 and Springboard? Check out our Talking About Windows events page under the TechEd EMEA event listing here. (Also a huge thanks to his crew, Ed Wens and Michel van den Einden who did all the camera, editing, and production).

Also, make sure to check our our newest Engineering and IT pro videos on the main page from Lidiane Souza, Greg Lambert, Stephen Hall and Peter Menadu.

Tuesday night was our Springboard Party at the Water-Gate Club. Over 300 It pros from around the world showed up to party and share their love of Windows 7 and Springboard. It was a great time with great music courtesy of DJ Joey Snow and DJ David Lowe. Thanks again to our co-sponsors on the Windows Server team and TechNet+ team as well as everyone who showed up to celebrate with us.

It was a week of listening to amazing speakers, everyone asking great questions,cool demos, people working in HOLs all day and getting certified that evening, amazing food and people passionate about all of our products. All of this and the 20th anniversary of the fall of the wall. Our motto, “Life Without Walls” really took on a whole new meaning for me as I stood in front of the wall and outside the Brandenburg Gate on Monday.

Thank you Berlin for an amazing time.

Stephen

Getting Off The “Get On The Bus” Tour

Stephen L Rose — Sun, 08 Nov 2009 13:43:00 GMT

For those of you reading our newsletter, following our Twitter feed or blogs, you are aware that I the Springboard Series partnered with Microsoft Learning for the “Get On The Bus Tour” The goal was to bring information on Windows 7, Server 2008 R2, Exchange 2010 and Certification. So, I agreed to spend 5 days working, traveling and even sleeping on a bus.

I have to first start by stating what an amazing group of people I had the chance to work with. From Ken Rosen, Tjeerd Veninga, Liberty Munson, to Brad McCabe from the MDOP group and Ian Hameroff from the Exchange team. All true professionals who can go from speaking to an 18 yrs old to 80 yrs old attendee without missing a beat.

The bus tour during my week onboard visited Amsterdam, Frankfurt and Munich in Germany, Vienna, Austria, Prague in the Czech Republic and then a final stop in Berlin where I am am now preparing for TechEd.

We spoke to IT pros in Amsterdam, made a visit to the local Dell office and ended the day with a event complete with a Oscar statues, a red carpet and real “American style” popcorn where Windows 7 was the main event. We spoke to groups of IT managers in Frankfurt (where I learned knocking on a table at the end is a good thing) and to a high school in Vienna were we spoke to around 100 students about Microsoft, technology and the career paths. It was amazing to see the excitement and enthusiasm around our technology.

We visited Munich were again much table knocking ensued and then on to Austria where we did sessions for our TDM (Technical Decision Makers) around the cost savings and benefits of the new products.

Finally, after a long nite and short sleep, we arrived in Prague where we spoke at the new football (soccer for our US readers) stadium for Slavia Praha where we got an great behind the scenes tour of the stadium.

Times are tough all around. So bringing this opportunity directly to the people who can best benefit from it was a great experience. The many questions and thanks I received from all
who attended really made the cold, the lack of sleep and the long days well worth the time spent.

Thank you again for all who attended our events. I have made some great new friends and have learned so much from all of you. I look forward to seeing some of you here in Berlin during my stay.

To see more photos and videos from the tour visit the Bus Tour site here.

Auf Wiedersehen for now.

Stephen

PS-

Also huge thanks to Melissa Bathium our tour coordinator, Bob Simms our contest winner and of course to Celine Allee and Janett Garcia-Riseland for sponsoring this amazing event.

Coming to TechEd EMEA in Berlin?

Stephen L Rose — Sun, 08 Nov 2009 12:33:00 GMT

Coming to TechEd EMEA? Well make sure you stop by the Springboard or Talking About Windows booths! Why? Well, in addition to all the cool information on Windows 7 we have to share with you we have tons of cool opportunities and prizes!

Talking About Windows booth

Attendees who find the Talking About Windows Video crew and record their thoughts about Windows 7 will have the opportunity to win prizes. Videos will be shown in the booth on the TAW plasma and on the TAW web site. Plus, we will be giving out some cool prizes.
Talking About Windows Interviews - Come hear from our community experts and ask questions live during our video podcasts. Stop by for a list of speakers and times.
Live MVP Call – At 10 am on Wed, join us for a live MVP call with Karen Anne Young of the MVP group and Graham Watson of Culminus.

Springboard Series on TechNet Booth

Springboard Series Community Influencers Party
Tuesday, 10 November, 17.00 – Midnight
Hosted by: Springboard Series, Server & TechNet+
Audience: MVP, TechNet+, MCT, Microsoft
By invitation only
Springboard Series Learning Plans - Complete a Springboard Series Learning plan for a chance to win a Flip HD video camera

Plus we have swag and other cool opportunities so stop by, say hi and learn about all the cool information we have to help you Discover, Explore, Pilot, Deploy and Manage Windows 7.

See you at the show!

Stephen

Part 5: Automating the migration from Windows XP to Windows 7 End-to-End

Stephen L Rose — Sun, 08 Nov 2009 10:31:00 GMT

So this is the fifth and final part of the series about deployment and all of the subtasks you need to do. Admittedly, I set out to do this in one page and I think with small font and a decent-sized plotter, you may just be able to get this to print onto a single page, but most people won’t. For the astute readers out there, you might be thinking two things, “I just read several pages of what is essentially intro content?” or “Wait, Jeremy, you forgot all about drivers!!!”

To the first question, I was on the team that originally wrote the ominous “1500 pages of desktop deployment guidance” back in the Business Desktop Deployment (BDD) 2.0 and 2.5 days. We’ve “streamlined” that down to a couple hundred pages now in MDT 2010, but in doing so, left out most of the content around project management, business case, Microsoft Solutions Framework and so on. The result is the often-requested, “click-here, do this” guidance, but if you crave the all-up project management best practices content, we’ve posted archived builds of MDT and BDD releases.

If you’re one of those guys that refuses to use stuff branded as Windows XP SP2 or Windows Vista because it doesn’t look current, the archives may not be for you. If you do want sample project plans and project templates for deploying an OS and are ok replacing an occasional “Vista” with a “7”, then you’ll be able to get value. Here’s a secret, the all-up set of processes for deploying Windows XP is roughly the same as deploying Windows 7. Sure the tools have gotten better and cover more areas/scenarios and the OS is more flexible for imaging and offline servicing, but the all-up process is basically the same it has been for years.

Remember the “BDD Wheel?”

All of this still applies today to whatever OS you are deploying. Even though I have the source files for this image that we built in Microsoft Office Visio in 2003, fundamentally, I could use that original graphic today with Windows 7. That is why I’ve covered most of these areas in my last four blogs.

Automating the End-to-End Migration Process

I will answer the driver question as I go into the process automation. To be honest, I want to downplay drivers a bit, because if you’ve installed Windows 7 (or even Windows Vista), you’ll know that in-box driver coverage is in a whole new league compared to Windows XP. The important stuff like mass storage and network drivers are pretty well-covered, as are most other driver categories. You will need to ensure that display drivers are included in your process and any other OEM-specific applets you want to keep are there, and we’ll cover that in a minute.

One thing you’ll need to think about relatively soon is the Windows activation method that you’ll be using for Windows 7. Windows XP activation usually entailed you baking a key into your unattend process. You can still do that now with the revised unattend.xml using Windows System Image Manager and a Multiple Activation Key (MAK) or you can set up a Key Management Service (KMS). I recommend KMS, since we don’t need to worry about managing keys in the build process. Once the system is online and can reach the KMS server, it activates automatically – no keys to manage or potential key leaks during the deployment itself. Read more on this in Volume Activation guidance.

I was using “fun” a bit sarcastically in previous blogs, but this is truly the fun part of deployment for me – automating things. Whether you are using Microsoft Deployment Toolkit 2010 or System Center Configuration Manager 2007 SP2 to build your deployment task sequences, you basically need to add the same ingredients to your build:

1. An Operating System

2. Applications

3. Drivers

4. Packages

Here is what that looks like in the MDT 2010 Deployment Workbench.

I actually like my sequence of ingredients better, since the operating system is the only “required” piece of the four I listed. If you do have a thick image with applications and just want to use the task sequence to capture and re-apply user state and maybe hit your update server or Windows Update, you can get by with only the operating system image. For a thin image, you can get by with just importing a set of flat Windows 7 retail source files.

The next thing we do is add our packaged applications. We need the application source files and the silent install commands. We can also do things like set up application dependencies, so if Microsoft Office Communicator is dependent on Microsoft Office 2007, then by choosing to install Communicator we’ll preclude that automatically by the entire Office package.

Like everything else in the Deployment Workbench, you right-click the item, select “New Application” and follow the wizards. Once you’re done, you’ll have something that looks like this:

As you can see from the “CommandLine” field, install command lines vary dramatically depending on the application you’re installing. Now is also the time where you want to check for drivers that were shipped as application installer packages and you’ll be treating them as applications in this case.

Now you can add “normal” drivers with INF extensions in the “Out-of-Box Drivers” area. Drivers will be installed automatically based on their PnP IDs by default or if you want total control, you can group them using Selection Profiles in MDT 2010. Once you’ve imported drivers into the Deployment Workbench, it will look something like this:

I want to note here as well that if you are using a straight Windows Deployment Services environment with Windows Server 2008 R2, we can also use the driver store in Windows Deployment Services to keep drivers centrally on our deployment server and have them install based on PnP IDs. Likewise, System Center Configuration Manager has a great driver store as well to control how drivers are installed. The last thing you can do for driver installation is opt via the deployment task sequence to hit Windows Update for updates and drivers. Chances are, between these approaches and an optional call to Windows Update, that even untested devices will successfully install with most (if not all) drivers ready to go.

The last ingredient we’ll add to our build are packages. Packages can be Cabinet (.cab) or Microsoft Update (.msu) files. There is a mechanism to do this in the Deployment Workbench and ConfigMgr and when we detect language packs in MDT, we’ll even expose them as optional packages (as opposed to installing everything that qualifies for our OS). Once you’ve added packages, you’ll see something like this with varying package types:

At this point we have all of our ingredients. MDT 2010 and ConfigMgr also have vital components like USMT and Windows PE to migrate user files and give us an installation environment for laying down the Windows 7 image. If you want to customize Windows PE, you can do that using MDT 2010 as well, but MDT will automatically create the custom Windows PE environment for you as part of the standard build process. I introduced task sequences as the thing that combines all of the migration processes together and even listed the core steps in the last blog. The great thing is that the standard client and server task sequences in the box in MDT and ConfigMgr will do essentially everything they need to do and in many cases, you won’t need to create any custom tasks. Here is what the task sequence looks like and everything it does.

Among all of the steps, there are a couple of “Inject Drivers” steps that allow you to either rely on the PnP ID mechanism by default or choose a selection profile from the drop down list as seen above. After you’ve created the task sequence and everything else is done, you can start testing. Now you can use a file server, Windows Deployment Services or standalone media to deliver your Windows 7 builds. This will perform all the steps I listed out in the last blog and you’re far along on your way to start migrating Windows XP machines to Windows 7 in a highly automated way.

Last Thing

Before I finish this series, I just want to cover one last thing. Once you get everything working using MDT 2010, the first thing you’ll probably want to do is remove some of the Lite Touch deployment wizard screens like I’ve done in following video.

(Insert Part 4 deployment video here)

Here is the trick. You can modify a file called “customsettings.ini” in your MDT 2010 distribution share. The file in located in the …Deploy\Control folder. Using this file, you can eliminate one, many or all of the wizard screens by pre-populating the fields that you would otherwise have to fill in or skip screens and use the defaults in other cases. A completely automated customsettings.ini file looks like this:

I’ve also added mandatory applications to control which applications are part of this build. Using a customsettings.ini file with the standard client refresh task sequence, you will automate all migration steps.

With that, you have the basis to start automating migration from Windows XP to Windows 7. In less than 20 pages, I have covered a lot of ground and I’ve been pointing along the way for more guidance per task. If you’ve gotten value out of this series, I would encourage you to subscribe to the Deployment Guys Blog and keep checking back to the Springboard Series on TechNet for the latest content.

Thanks again for reading and get automating,

Jeremy Chapman

Windows Deployment

Part 4: Choosing and Image Strategy and Building Windows 7 System Images

Stephen L Rose — Sun, 08 Nov 2009 10:23:00 GMT

Now that we’ve talked about deployment all-up, data migration, and application compatibility, let’s focus on imaging. Now this is not the imaging that involves photos and cameras, but the imaging of computer disks.

Quick History Lesson for System Imaging

Imaging tools have been around for a long time and the most basic of which essentially backup an entire hard drive sector-by-sector and we and can restore that drive if desired to the same or another computer. This is basically a form of drive cloning and it was popularized in the 1980s and 1990s. Like I said in the first blog, this type of imaging when used for deployment in the enterprise is fairly archaic, since you’ll need to maintain an image per Hardware Abstraction Layer (HAL) type and often for people managing Windows XP, you’ll often see an image per language or region as well. What does this mean? Usually it means tens or hundreds of images to manage for many organizations, all requiring maintenance when “Patch Tuesday” or similar events or updates come around.

But sector-based imaging can’t be that bad right? Well, let’s say you have everything centralized and you have 20 images to manage and up to 20 computers in your lab, once that critical update hits, we’ll spend an hour rebuilding each of those machines, maybe an hour configuring them and then up to three hours recapturing the image with sector-based imaging tools. That means 100 hours per month if you maintain things monthly or 1200 hours per year. To be fair, you aren’t clicking and configuring things manually the entire time, but it’s probably fair to say you’ll spend 2 hours per system across all tasks and you’ll eventually have terabytes of system images to find space for. If you are using the System Preparation Tool (sysprep) to generalize the image for installation on other computers, then you get only three passes of the tool per system image over its lifetime, so you generally need to capture each image before running sysprep and afterward, so you can start next month from the pre-sysprepped image, or else you need to start completely from scratch each time and apply all the changes since the last service pack.

Fast forward to 2003 when engineers were determining the future of system imaging and along comes the Windows Imaging Format or “WIM” file. I was working with Microsoft’s Systems Management Server (SMS) and Solution Accelerator teams at the time and WIM was a prerequisite for the Operating System Deployment Feature Pack released back in 2004. WIMs are file-based and compressed images that can also save the contents of a drive. WIMs used with Windows XP were a pretty good option from a deployment standpoint based the reduced image size and ability to pass that package over the network, but they were still tied to one HAL type.

Fast forward to around 2006 and early iterations of Windows Vista… WIMs used for Windows Vista and Windows 7 imaging and deployment take on a whole new meaning. Remember those tens or sometimes hundreds of images to maintain and up to five hours per month per image? With Windows Vista and Windows 7, you can get down to a single image per operating system architecture (i.e. a 32 bit image and/or a 64 bit image). As an example, right now I am in an airplane writing on a Fujitsu U820 ultra mobile tablet PC uniproc that I built using the same image I’ve applied to my bigger and less airplane-friendly Lenovo T60P 15” multiproc laptop as well as countless other hardware types.

But it gets even better than just a single image to manage for all hardware (and languages by the way, too). Remember the five hours or so we would spend building, configuring, and recapturing that old sector-based image? With file-based images of Windows Vista or Windows 7, we can mount them to file folder and service them offline. In other words, I need one computer in my lab to use as a reference machine for all computers, I can use a free tool in the Windows Automated Installation Kit called ImageX to capture and apply system images, and I don’t necessarily even need to use that reference computer in my lab to service my one image on Patch Tuesday. I can mount the image in a folder on my image storage server if I want, use the Windows 7 and Windows Server 2008 R2 in-box tool called dism.exe (“Deployment Image Servicing and Management” in case you’re wondering) and enumerate the contents of the image to see packages, updates, drivers and features and modify those contents offline using dism.exe – again without building that reference lab computer. Those 5 hours it took you to apply the 3 critical Patch Tuesday patches can take as little as about 2 minutes to mount the image, 10 minutes to service it and 2 minutes to unmount it. I’m usually pretty happy if I can save 4 hours and 45 minutes performing an otherwise boring, but necessary task and instead of doing it 20 times and using 20 physical machines, I’d do it once. Makes sense, right?

To show some of that, here is a video of sysprep and ImageX to generalize and capture a custom

Video : Preparing an Image using Sysprep and ImageX

And this is a video of dism.exe servicing an offline mounted Windows 7 image:

Video: Deployment Image and Servicing Management

I had to take a brief excursion from the deployment task at hand to give the history lesson, because in all my interactions and talking to IT pros and my desktop admin friends lately, I see two common things when it comes to imaging; 1. the majority of people I talk to are still using the sector-based imaging tools they’ve been using for decades and 2. the majority aren’t maintaining Windows Vista or Windows Server 2008 images, so they aren’t able to do offline image management. Even more troubling are the situations where Windows Vista or Windows Server 2008 are in place, but people are using the 20 year old tools and processes to manage them and aren’t even using or aware of sysprep, so an image per HAL type is still needed or lots of luck that the non-sysprepped image installs on foreign hardware (this scenario without using sysprep albeit unsupported is still somewhat common).

Building Your Image

Windows Vista and Windows 7 are delivered by a file-based WIM image and image-based setup. That DVD you might have or the ISO file you downloaded contains a 2+ GB file called install.wim in the Sources directory. The amazing thing about this WIM is that it actually can contain multiple operating system captures. In fact, the Windows Server 2008 R2 Enterprise image contains 8 operating system variants and Windows 7 Ultimate contains 5 variants. This would normally be larger than the Windows 7 Enterprise install.wim or a custom captured image with a single operating system image, right? Not really. WIMs use single instancing of shared files, so you can have multiple operating systems available in an image that might be about the same size as one captured operating system. This is important as you determine your image strategy, because you can do things like have multiple operating systems of differing languages packed into a single WIM file and even with multiple languages these should only be marginally larger than a single language WIM image. WIMs can also be used to compress and deliver data, so you can package multiple applications, drivers, packages into the data WIM, then mount and call them at install time using scripted OS installations.

Now that you know a bit about WIM files, let’s cover the basics of imaging strategy. There are three primary strategies used for imaging and all are valid depending on the use case:

1. Thick Image. I like to refer to this as the “old school” approach to imaging where you basically build a reference machine, install all possible applications to ensure users have the applications they could ever possibly need and usually more. Once that is done you apply software updates for the OS and all the applications, then you sysprep the computer and capture the image. Then you make sure everything works and ensure that sysprep didn’t affect any applications.

2. Thin Image. This approach takes things to the other extreme. Little or nothing is installed on the reference computer and that is sysprepped and captured. Or some will just use the image as shipped in the Windows 7 retail DVD or ISO with zero customization. This strategy assumes you’ll be customizing the installation with applications and other necessary data dynamically at deploy time. This also means all of your applications are packaged for unattended installation or you are willing to pre-stage them for users to install when they want or you use something like Application Virtualization (App-V) so application profiles follow users regardless of the device they log into.

3. Hybrid Image. In between Thick and Thin is a Hybrid Image, where applications that everyone uses or needs are captured in the base image (perhaps your VPN software, your anti-virus software, your version of Microsoft Office and the App-V client). Aside from those core applications, additional applications are layered on at deploy time based on user needs.

All three of these strategies can be justified, though I personally tend to favor thin images. The thick image approach is useful in situations where the company has a homogeneous environment, uses a single language and all users use and need exactly the same set of applications. When using thick images in larger organizations, the trade-offs are that you pay for several applications that may not be necessary for all users, images are larger and multiple applications can affect performance, plus the image is more difficult to maintain and flexibility is greatly reduced. Thin images are the most flexible and easiest to maintain, but customizations need to happen at deploy time and that means applications are packaged for silent install and application updates can be installed silently as well. Installation speeds can be slower compared to thick images since each application needs to install itself one-by-one at deploy time and more automation is required. Hybrid images include many of the components of thick images, without necessarily wasting licensing costs, required disk space and often the performance hit of multiple unused applications.

Getting to Thin Images

If you currently use thick images, you might be asking, “What tools are there to move to thinner images then?” Enter deployment task sequencing. Recognizing the limits of using thick images, many people have developed task sequencing engines to not only install applications, but also perform the other common operating system deployment tasks in an automated way. Task sequences are extremely important for computer refresh and computer replacement scenarios, since they:

1. Validate that the target hardware can install the operating system

2. Capture user files and settings

3. Invoke an installation environment like the Windows Preinstallation Environment (Windows PE)

4. Customize the installation environment

5. Apply the operating system image

6. Apply drivers required by the hardware and connected devices

7. Apply software updates

8. Apply applications based on your selections

9. Join the machine to a domain

10. Re-apply user files and settings

11. Configure additional things like BitLocker Drive Encryption or server roles

All of this gets done in a completely automated way using deployment task sequencing – you launch it for a minute or schedule it centrally if using System Center Configuration Manager and the rest just happens without you needing to touch the machine. For someone new to the space, it sounds difficult to get configured, but this is a standard in-box task sequence from the free Microsoft Deployment Toolkit or the enterprise-class System Center Configuration Manager console.

Here’s a video of what preparing a build looks like using the Deployment Workbench in the Microsoft Deployment Toolkit 2010:

Video: Deployment Workbench in Microsoft Deployment Toolkit 2010

The task sequence brings together the tools we need for the deployment to end-to-end. I like to think of everything we’re using in terms of music. If you think of unattend files, the User State Migration Tool, Windows PE, applications, and drivers as instruments, then the task sequence is like the conductor and sheet music. The end product is a symphony of automation that you have complete control over. Once everything is finished and ready for automation, you can pick how you want to deliver your builds. But we won’t cover that here, let’s save that discussion for the next blog on image and build delivery.

Until then, I’ll leave you with a fully-automated migration with user data from Windows XP to Windows 7 that I built myself (but did not narrate) using the free tools described above:

Video: Windows XP to Windows 7 Migration

Thanks for reading and happy deploying,

Jeremy Chapman

Windows Deployment

Part 3: Application Management and Preparing for a Windows 7 Deployment

Stephen L Rose — Thu, 05 Nov 2009 13:47:00 GMT

If you are like most desktop service managers, you probably have several applications that you manage and depending on your users, there may be several applications that you don’t know about. There are a few places out there where “Standard User” or “Least-Privileged User” accounts aren’t the norm and users can just install whatever applications they want. If this sounds familiar, then you probably have a bit to do in terms of detecting, rationalizing, and testing the applications your users have to prepare for Windows 7. For any compatibility issues, you can address them using a variety of approaches and we’ll discuss all of those approaches in a minute.

The next major area you’ll need to worry about is how to get those applications or corresponding newer versions onto your users’ Windows 7 desktops. There is a fair chance that you’ve been cloning hard drives over the past couple of decades and don’t necessarily have automated installation packages for all the applications that you want to deploy into the new Windows 7 environment. Some applications aren’t packaged for silent installation, making it hard to customize installs to include only applications specific to user roles. That along with other factors means there are a lot of organizations out there having 20 to 50 applications present on every workstation – even if the users only need 5-10 of those applications on average. With the newer deployment tools, you can save your money on these applications and install what is required per user instead of giving them everything. This will save you on licensing and may improve the performance of Windows if any of those applications tend to launch at startup. I’ll talk a little bit about the application packaging process after we dig a bit deeper into application compatibility.

Application Compatibility

The application compatibility process contrary to popular belief doesn’t begin with testing. The first thing you’ll probably want to do is collect an inventory of your hardware and software assets. Be prepared to discover more applications than you thought you had. One tool you can use is the Application Compatibility Toolkit (or “ACT”). The Application Compatibility Toolkit isn’t a magic wand that you wave at applications to “make them work”, but it does provide the tools to inventory your applications, hardware and devices; evaluate runtime compatibility of applications while collecting data; and compare what you’ve collected to a central database managed by Microsoft with compatibility data from ISVs and the IT pro community.

When I present the toolkit at events, I often get asked:

“Hold on, did you just say the Application Compatibility Toolkit discovers hardware and devices and not just applications?”

Yes, it’s true. ACT finds the applications wherever they may reside and also reports on hardware and devices detected as well. One thing to point out here is that while most inventory tools relegate themselves to just data found in Add/Remove Programs, ACT also looks in multiple locations of the registry (run, run once, file extension handlers, app paths, etc.), and in services. ACT tends to find any application on the system or otherwise launched by the user while we’re performing an inventory. Once you deploy ACT’s lightweight Data Collection Package agent, ACT detects the information on your users’ Windows XP workstations and sends the information back the network location you specify, then processes the data and reports its findings to you.

Check out the ACT video about Data Collection Packages here.

Many IT shops have an inventory they are confident in and don’t necessarily want to deploy agents out to their users – it’s completely understandable. Is there anything better in this case than using the consumer compatibility site to search applications and devices one-by-one? Yes, if you have more than about 20 applications, using that site probably isn’t your best option and for that we also publish a list of known compatible applications that you can query against using your own application inventory database.

What’s next? If you have a thorough inventory, it is extremely likely that you won’t want to move all of the applications you find from Windows XP into your new Windows 7 environment. There might be five different media players or eight different applications that read PDF files on your users’ collective PCs. In fact, many companies can eliminate 90% or more of the applications they inventory, because they are duplicate in nature, hardware-based or undesired. You can even use filtering in ACT to help reduce the list.

This is important, because it is much easier to test 100 applications compared to 1000 applications and reducing your inventory list can often be done in a couple of hours. I’d personally rather test 100 applications than 1000, and I’m guessing that most would agree.

See the video for working with ACT inventories here

Now that we have the rationalized list of applications and static data from ISVs as to whether they are compatible or not, the fun starts with testing those applications without information. You should find that most of your applications work in Windows 7 and this is especially true for packaged (ISV) applications that were released in the last 2-3 years. The in-house developed applications that you’ve had for 5 or more years may require special attention. The major things to look for are applications that like to run under administrative context and have free reign of the computer they run on, or if they are locked to a specific Windows version number, or Web applications that require Internet Explorer 6. If you have Internet Explorer 8 already deployed and your users generally have Standard User accounts, then you won’t have as much work to do. You can find more information on why applications may experience issues running on Windows 7 in the “Understanding Application Compatibility” guide on TechNet.

Once we find out what is not working we have a couple of options to make them work:

· For packaged applications from ISVs, the best approach is always to find an application that runs natively on the version of Windows you want to install it on. Sometimes there are free updates for these applications and sometimes not. Using the application as intended and tested by the ISV for Windows 7 ensures that the ISV can support your users and you are running their application in a way that they have tested it for.

· For in-house developed applications, the best approach is to recode the application to make it run natively. If you don’t have the source code or there is an easy fix, you can use compatibility fixes (or “shims”) to get the application to run without recoding it. More information about shims can be found in the TechNet Library.

Check out the video on commonly-used application shims here.

If you just can’t make it work, then it isn’t necessarily “game over.” If you’ve exhausted all other options to make the application run natively, then you can use Virtual PC to run the application in a Windows XP environment. Virtual PC with RemoteApp integration is much more intuitive for end users that is has been over the years. With Virtual PC, we can now publish shortcuts on the physical machine’s desktop or start menu to applications contained in the virtual machine and applications can be launched individually without exposing the whole Windows XP desktop. The trade-off is that you’ll have two operating systems to manage per user. If you do get to this point and you have a managed environment, I’d recommend that you look into Microsoft Enterprise Desktop Virtualization so you can manage the virtual environment.

Once you’ve worked through all of your applications – inventoried them, rationalized them, and mitigated incompatibilities – you might think the fun is over. Almost. Now that everything is known to be working, you’ll want to figure out how to install your applications in an automated way. In the next blog I’ll talk about approaches to get to a thinner image, but if you’ve been packing applications into your base OS image and doing sector-based captures of your reference computers’ disks, then you may want to look at ways to get your image count down and use the hardware and language neutral benefits in Windows 7 to get a single image. Getting to a single image in a larger organization typically means application packaging work is required.

Application Packaging

For some, application packaging and figuring out how to automate installation of your applications will be as easy as finding the silent install commands from the vendor. Usually these are in installation guides, Internet forums, or found using the ever-handy “/help” or “/?” switches in command line.

For in-house developed applications, there is a decent chance that silent install commands don’t exist for all of your applications and those applications will need to be packaged for the first time or repackaged if the installer package didn’t work with your new configuration (common examples are 16-bit installers when moving to 64-bit OS or OS version checks in packages looking for Windows version 5.1). There are a couple of tools out there like Flexera Software’s AdminStudio to help you create MSI packages as easily as possible. These are handy; as they tend to follow normal msiexec.exe silent install commands. Microsoft Application Virtualization also provides what is essentially a packaging mechanism with the application sequencing it uses to create virtual applications.

For some things you can avoid packaging by not including those applications in the standard OS build process and pre-staging installation files locally or making them accessible to users on the network. In the cases where everyone in the organization needs the application anyway, you can install those applications on your reference computer and create a custom image using ImageX. We’ll talk about the balance of how many applications to include in the custom image next time though.

That’s all for today and thanks for reading.

Jeremy Chapman

Windows 7 Deployment

Part 2: Migrating User Files and Settings from Windows XP to Windows 7

Stephen L Rose — Wed, 04 Nov 2009 08:27:00 GMT

I debated on what part 2 of this blog series should be - hardware and software compatibility or data migration. I chose data migration purely based on the automation steps in the chain I listed out in the first blog and because there aren't many things that excite me more in the Windows 7 deployment space than Hard-link Migration. Think about the speeds of large file moves versus file copies. If you're inpatient like me and hate waiting sometimes 3-4 hours for user state to migrate per computer when the operating system plus applications takes under 45 minutes in many cases, then you might appreciate Hard-Link Migration like I do.

To be fair, you could use technologies and tactics like roaming profiles, folder redirection and disallow creation of local email stores, at which point many of the problems associated with user state migration might go away, but in this case I'll cover the traditional case of user state as part of the user's computer.

If you manage desktops you probably have multiple users with files in every possible location on their PCs and there are settings like Internet Explorer favorites, known wireless network connections, application settings you want back in the new operating system. We can handle all of these things except for migrating the applications themselves. In most cases we'll want to test compatibility of older applications and not necessarily attempt to migrate them in-place from Windows XP to Windows 7, plus we can completely automate installation of managed applications at deploy time or capture them as part of the custom operating system image. I'll cover all of that in the next blog when I talk about application management.

Bringing this back to user files and settings, we know that user data is typically stored in a couple of places:

"C:\Documents and Settings" in Windows XP, and
"C:\Users" in Windows Vista and newer versions of Windows

Then the question that begs to be asked is...

Can't we just use robocopy or something to move the files from "C:\Documents and Settings" to a folder somewhere on the network named after the computer name and just copy them back to the "C:\Users" folder once we're finished?

Well, yes and no; it isn't usually that simple though. Unless you have draconian standards and policies about where your users can save data on their local drives, this won't suffice. We also have to look through settings in the registry we want to retain on the new computer, create and enable user accounts and some of us might want to block things from getting migrated. You may not want Joe in the marketing department to store his 100GB music and video collection on your managed PC, so we may want to block certain file types in the migration process (hopefully we let Joe know about this in advance so he has time to backup his media collection). On the other hand, Joe may not know where his Microsoft Office Outlook PST files are and even if we catch that PST file with our robocopy command, he'll probably call the helpdesk asking where his cached email is after we've installed Windows 7.

The good news is that we have a tool for this, the User State Migration Tool (USMT). The even better news is that if you use the Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager (ConfigMgr) 2007 SP2, it's already part of the end-to-end OS deployment process. You may have seen the migration demos from Windows XP to Windows 7 occur in as little as 18 minutes (yes, with several gigabytes of data being migrated, too), but if you haven't check them out:

Both of these demos are using the Hard-Link Migration feature for the Computer Refresh scenario (remember I defined this and other scenarios in the first blog). In the old days, USMT could support a Computer Refresh without moving the files off the computer, but it was basically a file copy and double-instancing of files locally whereas now the files do not move on the disk when migrating from Windows XP, we simply reassign pointers to files to the appropriate locations in Windows 7. The index of hard-links consumes around 200MB, so you don't need a lot of free disk space to use Hard-Link migration. Again think about how much faster it is to "move" a 1GB file versus copy it to another location on the same disk; that is why Hard-Link Migration is so much faster and it doesn't really matter if we move 5GB or 50GB in the migration; the times will be pretty similar. Those times depend on the number of files we move and not the size of the files.

The User State Migration Tool is now part of the Windows Automated Installation Kit (AIK) (download it here) and USMT installs simply via a file copy. Once you install Windows AIK, the USMT tools for 32 and 64 bit by default are located in the "C:\Program Files\Windows AIK\Tools\USMT" folder.

You can perform a simple Computer Refresh using Hard-Link Migration and move from Windows XP to Windows 7 using normal Windows 7 install media (retail DVDs) and coupling that with USMT. I outlined the process in a video and on TechNet in written form. This will quickly migrate files from the default-created Windows.old folder when you install Windows 7 onto a Windows XP computer. Remember, if you don't follow the default process and format the Windows partition during the install process, then Windows.old won't be there to migrate from, so just follow the default install to keep your data and create Windows.old.

So you might be asking another question at this point...

"What if I am doing a Computer Replacement and the data needs to move from my users' old Windows XP computer to my new Windows 7 computer?"

Computer Replacement is pretty common as well and the tools are also built to handle this. Normally, the data is passed from the old computer to a network share and then from the network share to the new computer. Both ConfigMgr and MDT can be used to automate the entire computer replacement migration process using a network share. You can even encrypt the migration store on the network (as ConfigMgr does by default) to ensure data stores cannot be compromised. Another useful addition to the migration tools for Computer Replacement is support for Volume Shadow Copy. That means that we can gather files even while they are in use. One thing to point out with Computer Replacement is that you can't get the speed benefits from Hard-Link Migration, because we are at the mercy of physics moving the data to an external network location or external hard drive.

What about the types and locations of files that get migrated? The newest User State Migration Tool adds a new algorithm to find more user files than with previous releases versions of USMT. The control file (migdocs.xml) uses shared and comprehensive file detection logic with Windows Easy Transfer, so if you have used USMT in the past and had to extensively modify the previous control files (for example miguser.xml) to add file coverage, the new migdocs.xml should be a welcome addition.

I actually didn't set out to write this as an advertisement for the User State Migration Tool, but the truth is that the charter of USMT is to manage migration of user data and support as many mainstream options as possible for large customers. USMT does a great job in migrating user files and settings. Now for the people looking for a user interface for USMT, I would recommend you use it in conjunction with the Microsoft Deployment Toolkit or with System Center Configuration Manager. If you have used USMT in the past without a lot of success, the current version of USMT offers several enhancements to increase speed, flexibility and process reliability to make the migration portion of your operating system deployment easier and more predictable.

In the next blog, I'll take on the topic of application management - including application compatibility and automating application installation - as well as touch on hardware inventory and compatibility.

Thanks and stay tuned,

Jeremy Chapman

Windows 7 Deployment

Migrating from Windows XP to Windows 7 - Guidance for IT pros

Stephen L Rose — Tue, 03 Nov 2009 17:30:00 GMT

Every day this week long-time Springboard technical contributor and Windows deployment insider, Jeremy Chapman, will post a blog about how to think about Windows 7 deployment projects. We debated on making this a whitepaper or a feature article, but to keep things less formal, we went with a multimedia blog series. This series won't just cover steps to publish images in your Windows Deployment Services environments, instead it goes much broader into the major steps of deployment all-up; from figuring out what applications and hardware you have to migrating files, managing applications, building images, incorporating drivers and automating stuff end-to-end. Jeremy has been a veteran member of the Microsoft Deployment Toolkit team and while he won't be posting the classic "1500 pages" of how-to content, he will stay on his quest for the elusive and often escalated-for "one-page paper" to migrate enterprise customers from Windows XP to Windows 7. Let's see if he can do it!

Part 1 is already up and parts 2-5 are coming each day this week:

Subscribe to the RSS feed or check back for the rest this week. If you are coming to TechEd Europe next week, Jeremy will be delivering multiple sessions on Windows deployment and application compatibility. Please let us know what you think about these blogs, the longer multimedia format and whether you would like to see other topics covered.

As always, thanks for reading and I hope to see some of you next week at TechEd!

Stephen Rose

Part 1 – Migrating from Windows XP to Windows 7

Stephen L Rose — Tue, 03 Nov 2009 08:30:00 GMT

This is the first blog in a series of blogs explaining how to migrate from Windows XP to Windows 7. As the enterprise operating system deployment guy, I often get requests for a "one-page" article on performing desktop deployment or migrating Windows XP PCs to Windows 7. Although I have seen full length books printed on the head of a pen, without using either really, really small font or a really large page, I don't think it is possible to explain the entire set of desktop migration tasks when moving from one operating system version to another within one page. If you are upgrading one PC from Windows Vista or performing a clean installation on your personal computer (coming from any recent version of Windows), there is one-page guidance available here for doing that, but it probably won't satisfy you if you want to perform these tasks more than about five times.

Let's start by stating a few assumptions:

You are an IT professional and looking to move multiple PCs or users from Windows XP or Windows Vista to Windows 7.
The computers you are transitioning to Windows 7 have user data, settings and applications that somehow - either partially or completely - need to be migrated to Windows 7.
You don't want to manually transfer user files either via file copy or use manually-operated consumer tools (i.e. Windows Easy Transfer) from the legacy PC to Windows 7.
You would prefer to have applications either be part of the customized operating system you install or automate application installation as part of the all-up deployment process.
In the best case, you would prefer that the entire process is as automated as possible.
You have some previous experience with operating system installation, deployment or system imaging.

You might be thinking, what about the common process of hard drive cloning or sector-based imaging to just duplicate a reference install?

The good news is that with advances in system imaging, you don't necessarily need to spend hours saving user data off an old computer, cloning a hard drive of a reference computer and then taking the time restoring the data you saved in the first step. While the hard drive cloning process is probably the most common practice out there now to install a customized operating system, it has several disadvantages, including:

the overall time required per system (when including user data migration),
eventual proliferation of hard drive images based on different hardware types,
image sizes and storage space consumed,
hard drive cloning software may have a cost,
unnecessary time spent to rebuild and maintain each of many images in an ongoing way, and
per user customization of installed applications and license activation is often a manual process.

There are a few options you have when coming from Windows XP and much of it depends on the size and complexity of your environment. We highlight four primary options for migrating from Windows XP to Windows 7 (or Windows Vista) in the "Choosing a Deployment Strategy" article on Microsoft TechNet. In fact, that article will probably go into more detail than I can in a couple of blog posts and it does a great job in pointing to tools and resources.

I'm using quite a few terms interchangeably in the text above and will be throughout this series. When I use the terms like "migrate from Windows XP" or "operating system deployment" or "transition from Windows XP", I am talking about the major steps we cover in any operating system deployment:

collecting existing user data and settings if they exist,
installing the operating system,
installing drivers and applications,
activating the operating system,
joining a domain if necessary,
restoring user data and settings, and
ideally providing the flexibility to customize what applications we are installing by user role andapply language preference, locale, time zone, etc. based on user needs

I usually refer to this collective process as "deployment" and there are a few other terms we'll define before concluding this series introduction. Subsequent blogs will refer to installation scenarios, so let's define the main ones:

Refresh Computer. This is when a user has a PC with files, settings and applications and we will be installing the new operating system to that existing computer and assume the same user keeps that computer. In this case, we try to keep user files and settings locally on that computer to save time, storage and network bandwidth. Some refer to this as an "in-place wipe and load" (without actually wiping the user's data) or loosely as "upgrading" a PC.
Replace Computer. This is when the user is getting a new computer or a computer is re-assigned from another user and the user data and settings need to move off the old computer through some method and onto the new computer. This scenario tends to take the most time compared to Refresh Computer and New Computer. Some refer to this as "side-by-side" migration, but it isn't necessary for the PCs to be physically near each other or otherwise connected in this scenario.
New Computer. This is when there is no requirement to migrate pre-existing user data or settings. New Computer is used for a new hire, a secondary PC or if an old computer was lost or damaged and user data was not previously backed-up. Some refer to this as "bare metal" deployment, but in most cases there is some OEM pre-installed operating system we will be replacing,

Now we have listed the assumptions for following the series, listed a few reasons why you may want to look at your existing deployment process if it involves hard drive cloning, roughly defined the all-up operating system deployment process and defined the primary installation scenarios. I think I've gone over a page in length, but this provides the backdrop for the upcoming blog posts. In the next blog, I'll describe the options and recommendations for user data and settings migration when moving from Windows XP to Windows 7.

Thanks and stay tuned,

Jeremy Chapman

Windows 7 Deployment

Configuring Default User Settings – Full Update for Windows 7

Stephen L Rose — Fri, 30 Oct 2009 18:27:00 GMT

This post was provided by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region. This post (and any updates) can also be found on the Deployment Guys blog here.

Anyone who had been doing operating system deployments long enough has had to deal with configuring default settings for users that log on to the computer after the image is deployed. Some examples of these are folder settings, desktop wallpaper, and screen saver options. Most of these will be initial settings for user preferences that users will be able to change (unlike policies which are enforced). This is done so that users will have a consistent, known experience when logging on to any client computer for the first time.

This can be done in a number of ways. Below are the methods I have seen or used with what I feel are pros and cons of each.

Implementing Default User Settings by modifying the Default User Profile

There are three main methods that have been used to configure the Default User profile. Only one method (B) is now officially supported and I recommend that you use this method.

A. Manual or scripted copy of a configured profile over the Default User profile (unsupported)

The traditional solution for this (developed during the Windows NT Workstation days) was to configure the Administrator account (or another designated account) with the settings, then copy the Administrator (or designated account) user profile over the Default User profile. This was previously documented in numerous Knowledge Base articles (which have now been deleted). A tool called CopyProfile was even created to script this process during unattended installations of Windows XP.

However, there are problems with using this procedure. It is very old procedure from NT4, when the shell was much simpler. The shell is more complicated for Windows 2000 and higher. This process will copy settings that should not be copied to the default user profile. It may seem to work but you will find subtle problems. Windows XP and later have made those subtle problems more visible.

Also, the Default User profile contains some single run actions that occur when the user logs in for the first time, which then setup that user by running those custom actions. If you overwrite the Default User profile, those single run actions do not take place.

The manual profile copy process can cause issues such as:

Their list of most frequently run programs is not cleared
Whether the user has been introduced to the Start menu (will be set to TRUE for the source account, but should be FALSE for new users). Windows Explorer does some special things the first time you log on to introduce you to the Start menu and other new features.
Whether the user is an administrator (and should therefore see the Administrative Tools, etc).
The personalized name for "My Documents" will be incorrect. All users documents folders will be called "Administrator's Documents". This is documented in the Knowledge Base article "The Desktop.ini File Does Not Work Correctly When You Create a Custom Default Profile" (http://support.microsoft.com/?id=321281).
The default download directory for IE will be set to the Administrator's Desktop folder.
The default Save and Open locations for some application with point to the Administrator's documents folder.
Windows 7 Libraries are broken.

Because of these issues, this process is no longer supported in Windows XP and all later operating systems. Unfortunately, the ability to copy a profile over the Default User profile was not blocked in Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008. This allowed many administrators to continue using the process and putting their Windows installations into an unsupported state. To prevent this, Windows 7 and Windows Server 2008 R2 now block this scenario by having the Control Panel System applet gray out the option to overwrite the Default User profile.

At this time the only supported way to configure the the Default User profile using a copy of a configured profile is to use the next method described here, the automated profile copy associated with using Sysprep.

B. Automated profile copy with Sysprep (supported)

First introduced in Windows XP Service Pack 2 (http://support.microsoft.com/?id=887816), Minisetup was modified so that it will copy customizations from the local administrator account to the default user profile. All subsequent versions of Windows will also do this with the proper entries in the answer file. This process was designed to avoid the problems with method A and is already automated.

I won't dwell on how the automated profile copy is used since it is documented in several Knowledge Base articles:

How to customize the default local user profile when you prepare an image of Windows Vista, Windows Server 2008, Windows XP, or Windows Server 2003
http://support.microsoft.com/?id=959753

How to customize default user profiles in Windows 7
http://support.microsoft.com/?id=973289

However this process does have a drawback. It does not propagate all settings to Default User and there is no known documentation as to what will and will not be propagated. It also can be difficult to determine if a setting did not carry over to a new user because it was considered inappropriate (i.e. not copied to Default User by design) or is being reset by Minisetup/Specialize or first logon processes.

One final important point to remember is the difference in behavior between Windows XP/Windows Server 2003 and Windows Vista and higher with respect to when the answer file setting must be present for the automated profile copy to occur. On Windows XP and Windows Server 2003, if you want to change the behavior of the automated profile copy, the UpdateServerProfileDirectory entry must be present in Sysprep.inf when Sysprep is run. This is because the profile copy happens when Sysprep is run on Windows XP and Windows Server 2003. The exact opposite is true for Windows Vista and higher. The CopyProfile setting must be set to True in the final answer file that is present when the OS restarts after Sysprep (Specialize phase) or the answer file used when Setup is used to deploy the custom image. This setting does not necessarily have to be present in the answer file used during the image build when Sysprep is run (Generalize phase). This is because the profile copy for Windows Vista and higher happens only during the Specialize phase. So if you are using a deployment tool like ConfigMgr or MDT that may modify/replace the Unattend.xml, make sure that CopyProfile is configured in the answer file used for deployment.

C. Targeted changes to the Default User Registry hive and profile folders

I used to use this method in the before the automated profile copy existed. I can be useful when only a small number of targeted changes are required. It can be described as follows:

1. Identify the needed Registry changes. Then use a tool like Reg.exe or KiXtart to load the Default User hive into a temporary location into the Registry, write only the needed settings, and then unload the hive. The Knowledge Base article "How to run a logon script one time when a new user logs on" (http://support.microsoft.com/?id=284193) shows how to do this manually. This can be scripted for an unattended installation using Reg.exe as shown in this example (these lines may wrap due to page width):

:: ***** Configure Default User
:: *** Load Default User hive
reg load "hku\Test" "%USERPROFILE%\..\Default User\NTUSER.DAT"
:: *** Disable Desktop Cleanup
reg add "hku\Test\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\CleanupWiz" /v NoRun /t REG_DWORD /d 1 /f
:: *** Unload Default User hive
reg unload "hku\Test"

2. Copy only needed files or shortcuts to the Default User profile folder.

This has the advantage that all changes to Default User are known and predictable. However, this requires that all changes be reduced to "scriptable" items (i.e. Registry or file system changes, no manual configuration).

To get this method to work properly on various service pack versions of Windows XP or Windows Server 2003 you have to disable the automated profile copy. In some cases you have to either install the hotfix from this KB article: http://support.microsoft.com/?kbid=887816 or set UpdateServerProfileDirectory=0 in Sysprep.inf. Which service packs versions have the automated profile copy enabled by default are documented in KB959753. In Windows Vista and higher the automated profile copy is disabled by default. You would then do the Default User hive registry edits before Sysprep runs.

This method can also be used to make changes to the Default User profile for machines that are already deployed in production.

You should exercise caution using this method. Try to keep all changes limited to only the individual Registry or file system changes needed for a particular desired result (e.g., a Windows or application setting). Do not do wholesale export and import of Registry keys or folder trees. This can potentially lead to the same problems as a manual profile copy. You can use a tool like Sysinternals Process Monitor to identify the individual changes.

Implementing Default User Settings by Using Scripts or Group Policy

The following methods are not for configuring the Default user Profile directly. However, they can be used to achieve the same effect (configuring settings the first time a new user logs on). And they have the added advantage of potentially being centrally managed.

D. Local logon script in the RunOnce Registry key

This is documented in "How to run a logon script one time when a new user logs on" (http://support.microsoft.com/?id=284193). This manual process can be scripted with reg.exe.

There are several advantages to using a script in the default user RunOnce key. It completely avoids Sysprep, CopyProfile, Minisetup/Specialize, or first logon processes effects. Also, if after deployment the default initial user settings need to changed, only the script file needs to be updated (instead of having to script a load/unload of the default user hive and fixing multiple settings). Finally, it is easy to "reset" a user's setting to the defaults because the script can be kept up to date and present on every box through software distribution or Computer Startup Scripts. This method also requires that all changes be reduced to "scriptable" items.

E. Local or Domain GPO logon script

A Group Policy logon script can be used to set "default settings" once by having the script set a flag after it first runs (perhaps an HKCU Registry entry) that it will look for and exit if found on subsequent runs. A Domain logon script has the added benefit of being centrally managed. This method also has the same advantages as method D. This method also requires that all changes be reduced to "scriptable" items.

F. Group Policy Preferences

Group Policy preferences first shipped as part of the Group Policy Management Console (GPMC) in Windows Server 2008. GP preferences consist of more than 20 Group Policy extensions that expand the range of configurable settings within a Group Policy object (GPO). Many of these extensions can configure settings that are commonly configured as default settings in a desktop image. Unlike policies, GP preferences can be changed by the user in most cases. Also, GP preferences can be configured to "apply once and do not reapply". This allows them to behave exactly like initial default settings configured in an image but has the benefit of being centrally managed and updated.

GP preferences cover many of the areas where default settings are usually configured such as:

Environment Variables
Files
Folders
INI File Settings
Registry
Shortcuts
ODBC Data Sources
Folder Options
Internet Settings
Local Users and Groups
Network Options
Power Options
Regional Options
Scheduled Tasks
Start Menu

The main disadvantages GP preferences are that it requires either Windows Server 2008, Windows Server 2008 R2, the Remote Server Administration Tools (RSAT) update for Windows Vista with Service Pack 1 or higher, or the RSAT update for Windows 7 to manage them and client-side extensions (CSEs) have to be installed for Windows Vista RTM, Windows XP with Service Pack 2, and Windows Server 2003 with Service Pack 1 or higher. For those still managing Windows 2000 images, you will have to use one of the previous methods mentioned since GP preferences will not work on Windows 2000.

I believe that GP preferences will likely be the best way to manage this going forward. Simply create GPOs using GP preferences, target them as needed, install the CSEs into the image(s) as needed, and you no longer need to worry about configuring these settings in the client image(s).

For information about Group Policy preferences see the following web resources:

Group Policy Preferences Overview

http://www.microsoft.com/downloads/details.aspx?FamilyID=42e30e3f-6f01-4610-9d6e-f6e0fb7a0790

Group Policy Preferences Frequently Asked Questions (FAQ)

http://technet.microsoft.com/en-us/windowsserver/grouppolicy/cc817590.aspx

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was provided by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region. This post (and any updates) can also be found on the Deployment Guys blog here.

I have written several posts on this topic before. However, changes were made to Windows 7 and Windows Server 2008 R2 that warrant a full revisit of this topic.

Now Available: Security Baselines for Windows 7 and Internet Explorer 8

Stephen L Rose — Thu, 29 Oct 2009 15:19:00 GMT

Now that Windows 7 is available, are you looking for some security baseline recommendations from the experts? Then here’s another timely release from the Microsoft Solution Accelerators team! Today, new security baselines for Windows® 7 and Windows® Internet Explorer® 8 are available for download.

Over the past few months, the Solution Accelerators team collaborated with Microsoft security experts, multiple government agencies worldwide, and a large community of IT security professionals to develop and test these new security baselines.All of these baselines are free for you to use.

In case you are not familiar with all of the security baselines available for Microsoft products, they ship as part of the Security Compliance Management Toolkit (SCMT) Series. The SCMT helps you to plan, deploy, and monitor security baselines for Windows® operating systems, Internet Explorer, and 2007 Microsoft® Office applications. It contains background information about compliance, and planning advice about how to automate security compliance. It also refers you to other tools and guidance that you can use to establish and deploy a security baseline, and then monitor and maintain compliance with your established configuration.

Where do you start?

At a high level, security compliance consists of four basic steps:

Plan how to meet security baseline requirements.
Deploy security baseline configurations.
Monitor security baseline configurations.
Remediate security baseline configurations.

The tools, guidance, and recommendations in the SCMT help you through each step of this process and give you the support to make key decisions about security baseline settings for your specific environment.

Here’s what you get:

Security guide – The toolkits include new and updated security guides for Windows 7, Windows Vista, Windows XP, Windows Server 2008, Windows Server 2003 SP2, Microsoft Office 2007 SP1, and Internet Explorer 8. The guidance provides you with best practices and automated tools to help you plan and deploy your security baselines.
Attack Surface Reference workbook – A resource that lists the changes introduced as server roles are installed on computers running Windows Server 2003 and Windows Server 2008.
Security Baseline Settings workbook – A resource that lists all of the prescribed settings for each of the preconfigured security baselines that the guides recommend.
Security Baseline XML – XML files that allow you to consume the data defined in the security baseline settings workbooks.
GPOAccelerator tool – A tool that you can use to create all of the Group Policy objects (GPOs) you need to deploy your chosen security configuration. This release also supports creating security configurations on computers not joined to a domain.
Baseline Compliance Management Overview – The overview discusses best practices on how to monitor security baselines for Windows operating systems, Office applications, and Internet Explorer 8.
DCM Configuration Pack User Guide – A step-by-step prescriptive user guide about how to use Configurations Packs with the DCM feature in Configuration Manager 2007 R2.
DCM Configuration Packs – Configuration Packs that provide prescriptive security information, which you can use to check the compliance of systems in your environment.

What should you do next?

Learn more about the Security Compliance Management Toolkit Series.
Download the Security Compliance Management Toolkit Series.
Find other Windows 7 Solution Accelerators here: Windows Desktop Solution Accelerators.
The Solution Accelerators team is developing a new tool called the Security Compliance Manager. It will help you manage your security and compliance process for the most widely used Microsoft technologies. Join the Beta review program and provide your feedback on the features you want most.
Get all the step by step guides, whitepapers, how to’s and screen casts on deploying and managing Windows 7 in your environment from the Springboard Series on TechNet.

Windows 7 Early Adopter Panel at the Gartner Symposium

Stephen L Rose — Wed, 28 Oct 2009 16:02:00 GMT

This post was written by Devrim Iyigun, a Senior Product Manager here in Redmond.

I had a chance to attend Gartner Symposium/ITxpo 2009 last week in Orlando, Florida. For those of you who are at the early stages of deploying Windows 7, looking for some insider information and did not have the opportunity to attend the conference, I have a great resource I would love to share with you.

Gartner Symposium/ITxpo 2009 is one of industry’s largest and most important annual gathering of CIOs and their senior IT leaders. This year’s event focused on how business technology can help customers return to growth by balancing cost optimization and risk mitigation. Microsoft was helping customers to understand how they can realize the benefits of Windows 7. With the general availability date for Windows 7 being October 22nd, this year’s event was quite special for the Microsoft team.

One of the Microsoft –sponsored sessions that took place is Windows 7 Early Adopter Customer Panel. In this highly visible discussion, featured Gartner Research VP & Distinguished Analyst Michael Silver facilitated the panel around Windows 7 planning, deployment and customer experience with Windows 7 Early Adopter Customers: ADP, BMW, Energizer and Pella.

The panel includes discussions about topics of importance for enterprises considering the move to Windows 7 such as application compatibility and deployment goals. ADP, BMW, Energizer and Pella share their perspective on business drivers to adopt Windows 7 and the benefits they expect to achieve with deploying Windows 7. These companies also share their deployment experience and recommendations for companies new to Windows 7 deployment.

This is your chance to get valuable insider information from Microsoft Customer industry leads. Please click here for a replay of this webcast.

For more enterprise company case studies, information on Windows 7 cost savings or our webcast series just visit our Windows Enterprise site.

For all of your Windows 7 IT pro information, visit the Springboard Series on TechNet. The destination for Windows desktop IT professionals to Discover & Explore, Pilot & Deploy and Manage Windows 7.

The “Get On The Bus Tour” Kicks Off Today In Milan

Stephen L Rose — Mon, 26 Oct 2009 15:44:00 GMT

Beginning today, 26 October, the Springboard/Microsoft Learning “Get On The Bus” tour will kick off an 11-city European road show that will begin in Milan and end at Tech-Ed Europe in Berlin on 9 November. At each tour stop, you’ll get an exclusive preview of Microsoft Windows 7, Microsoft Windows Server 2008 R2, Microsoft Desktop Optimization Pack (MDOP), Med-V, App-V, and Microsoft Exchange Server 2010. The Career Express tour spotlights new training and certification opportunities that will sharpen your skills on next year’s hottest technologies.

Join us at a stop near you for technical training, professional networking, hands-on experiences, and real world guidance from industry experts.

We even have a web page showing you exactly where the bus is right now.

We have some great Microsoft and community experts presenting on all the topics. I will even be on the tour doing the Windows 7 sessions starting in Amsterdam Nov 2nd. So if you can’t make it to TechEd EMEA this will be one of your best opportunities to meet the experts and see the new technologies from Microsoft live and in person.

For more information on the bus tour visit The Bus Tour or follow the Twitter feed here