Piloting Windows 7: Part 4: Installation Options and Collecting Feedback

  • Article

 

This is the fourth and final installment of this series from Jeremy Chapman

After user targeting and planning is complete, you can start your Proof of Concept testing and begin building Windows 7 images. There are many ways to build Windows 7 images or standard builds and depending on the tools you have in place, you may want to test a couple of options. For organizations with System Center Configuration Manager 2007, you can use that to create standard Windows builds with complete automation of OS, applications, drivers, data and profile migration, etc. If you won’t have Configuration Manager available for the pilot, you can download the Microsoft Deployment Toolkit (MDT) to create standard builds with similar automation capabilities to Configuration Manager. The main difference is that with Configuration Manager, you do not need to initiate the installation at the target PC, with MDT, you do need to initiate it. Both of these solutions use the Windows Automated Installation Kit components at their core to create and service images, migrate user state and activate Windows. They also use Windows Deployment Services in Windows Server 2008 R2 for network-based deployments or they can use media (USB flash and DVD) to install builds at target computers. My simple recommendation is to use Configuration Manager if you have it, if not use MDT.

Is Configuration Manager or MDT Overkill for a Pilot?

You might be thinking that Configuration Manager or MDT is too much to learn compared to a straight thick image (Windows plus all of your applications and drivers) and standing up Windows Deployment Services. I have seen this and heard this before. The problem is that habits start early on and if you invest a lot of time into a thick image and refining the straight Windows Deployment Services, Preboot eXecution Environment (PXE) and any additional scripting work, you’ll probably end up either with multiple images to manage and may not be taking advantage of the improvements in Windows 7 for imaging and deployment made since Windows XP – namely Hardware Abstraction Layer (HAL) independence, multi-language support, offline image servicing and better in-box driver coverage or you may reinvent the wheel and create your own version of a deployment task sequence engine like the one shared by Configuration Manager and MDT in-box.

There are other advantages to using a task-sequence-based deployment that Configuration Manager or MDT can provide – especially when it comes to things like computer naming, the ability to install applications based on user needs, integration with the user state migration tool processes to migrate user data, domain joining, ability to enable Bitlocker, custom locale and keyboard settings per user, language definition per user and so on. The flexibility that these tools provide can improve the thoroughness of the pilot testing – since you can test more configurations – and any work you do to make your applications install silently via a task sequence and not baked into a thick image can be re-used with ongoing software distribution in the future. I’ve seen many people get MDT up and running in a day or less, so if you fought with Business Desktop Deployment 2.0 and its scripting back with your Windows XP deployment in 2004/2005, I’d encourage you to look at MDT now re-evaluate it – even at the pilot stage.

The last area I want to hit on here is activation. For Windows 7, there are two primary ways to activate Volume License versions of Windows. Multiple Activation Keys (MAK) or Key Management Service (KMS) are used once the client comes up and is either connected to the Internet (MAK) or connected to the domain (KMS). KMS runs on a server in your environment and will automatically activate clients for you. With KMS, you own the activation process and traffic; the PCs do not hit a Microsoft activation service on the Internet. With MAK, it is similar to retail activation and the PC hits a Microsoft server to activate over the Internet. To use KMS, you need 25 clients to hit the service, so typically you start with MAK for the first 25 PCs, then you convert their activation type to use KMS after you cross the 25 threshold (virtual machines can also be used against this threshold now). KMS is the recommended way to activate Volume License clients because you do not need to worry about managing keys in your imaging or unattended build process and your infrastructure manages the activation. You can find more information about Volume Activation on Microsoft TechNet.

Rolling Out Desktops and Collecting Feedback

Once you have your strategy in place for delivering desktops (hopefully it doesn’t involve sneakers and a case of DVDs – aka manual installation work), then you can start rolling out desktops. In Proof of Concept, you are typically targeting the lab and IT department staff first. Once you’ve worked in their feedback and feel confident about letting your custom builds loose into the wild, you can begin with Phase 2 and rolling out to end users. If you take away anything from this series, remember to start small and grow your pilot user count based on your confidence level, support activities, user demand and any other indicator of pilot capacity.

Generally speaking, no news is good news when piloting. Sometimes you need to work to collect feedback and other times it will come to you very quickly, especially if something isn’t working and is impacting multiple users. Be prepared to hear about things like applications not working correctly, the Web browser not rendering pages like it used to, printers not being configured, hardware not getting recognized or working and people not finding the old functions they used to have in the old – often customized – operating system. If you are coming from an environment where users had full administrative privilege, then expect some questions around User Account Control prompts or other configuration management features. Much of the feedback you’ll receive will be in response to Windows working by design, but others will require work or workarounds.

Architectural changes like going from 32-bit to 64-bit will impact older 16 bit applications (they won’t install or run) and non-standard devices with unsigned drivers (they won’t work). Moving users from administrative account privileges to standard user account privileges will have another set of challenges, if uses are accustomed to administering their machine. The payoff in the long run will be worth it, but expect to get some helpdesk calls even if you use due diligence to inform users of the change.

To handle communications to and from users, there are several tactics that can be used. In most cases, you will want to implement an Intranet portal to allow users to submit feedback and also have helpdesk staff trained for telephone calls or instant message-based support. In addition, proactive meetings and open forums with pilot users are recommended to get as much feedback as possible on all areas of the pilot, its processes and the software being tested.

There are many tactics to get people involved and the ones I have seen work both within Microsoft and at other companies are:

  • Having an executive sponsor. This is vital to a good pilot, as the executive sponsor can help with areas of budget and organizational challenges, plus let’s face it, sometimes users tune out to emails coming from the IT department whereas they may react more quickly to emails coming from an executive sponsor.
  • Identifying Pilot Group Leaders. These are people with a true pulse on how others are feeling about the pilot, the process itself and the software they are testing for you. Group leaders interact with pilot users on a regular working basis and hear the good and bad aspects – often getting information not sent to the helpdesk. As an information aggregator, they also reduce can help the communication traffic required to each pilot users
  • Staying up-to-date with how people communicate. With so many communication channels available, you’ll want to stay up-to-date with communications to and from users. This might mean using social networking portals, email, in-person meetings, group calls, videos, etc. It usually isn’t enough to bury a pilot group RSS feed into your standard email client configuration or build an Intranet portal – users still may not consume the information.
  • Communicating and requesting feedback often. This might seem counter-intuitive if you want to minimize helpdesk activities (especially for those outsourcing the helpdesk), but if you open up other less expensive channels, you can prompt pilot users for frequent feedback and ultimately collect more data to prepare for the production deployment.

These are just a few tactics to get users involved and there are many more. Other tactics like user recognition for the most bugs filed, group morale events and pilot program branded swag have been used with high degrees of success as well. If you are in a constant state of piloting something like I was, these tactics can be applied to anything you are piloting – not just a Windows pilot.

Analyzing User Feedback

There are both reactive and proactive phases to handling user feedback. As feedback comes in, you will want to perform initial triage of the feedback. Remember the severity levels I defined in Part 2[j1] of this series? These severity levels will help indicate how quickly you need to respond and how critical a fix is. Also, you will find patterns for feedback and duplication of feedback. It is important to keep a count of the duplicate issues or trouble tickets to gauge how many people are impacted. Based on severity and number of users impacted, you can decide how you go about addressing issues – or if you address them at all. Some issues will be technology-related, others will be based on lack of user training and others will be cultural in nature. Despite the nature of the issues, all of these categories are addressable before the production deployment.

Before we defined severity levels in Part 2, we also defined areas to validate the technology and associated processes, then we talked about quality gates to proceed from phase-to-phase. Part of your analysis will be checking whether validation and quality goals were met, if not, you may need to continue the pilot and push out your schedules a bit to ensure that you have enough information and quality to proceed into the production deployment.

Finally, there are business aspects to measure. Will the technology meet business objectives? Have we identified ways to minimize user disruption? Do we have a plan to train users sufficiently and proactively manage the issues we know will come up in the production deployment? All of these should be answered and your executive sponsors will be keen on knowing the work already performed, current status and what is planned to correct any outstanding issues. The pilot is only complete when you have enough information to proceed with a go/no-go decision and that are confident in your abilities to deliver the new technology to a broader set of users.

This was the final part in the Windows 7 Pilot series. Thanks for reading and please comment on additional content you’d like to see covered.

Happy piloting,

Jeremy Chapman