Deploying Win7 using OSD at Microsoft Webcast Q & A – Part III
As we mentioned, we recently gave a talk as part of the Microsoft IT Showcase series that focused on what we have built for Microsoft clients with OSD. A great number of questions were asked during this presentation and due to time constraints we were unable to answer them. We promised to share them in a upcoming blog. This is the final of a 3-part series where we asked the question and answered it. Part I and Part II are available as well on our blog.
Q: How many applications did you approve for Windows 7?
A: We reviewed most, if not all, of our currently packaged applications and determined that none were packaged in such a way that there issues with User Account Control (UAC) or OS targeting. Thus, though we reviewed 15 number of applications required for Microsoft IT users, we had none that failed to work properly on Windows 7.
Q: Is Microsoft IT using XP Mode or App-V for the applications that aren’t Windows 7 compliant?
A: We are currently not using XP Mode for our user base at Microsoft. This is specific, though, to our environment of users who are managed using ConfigMgr and doesn’t represent all of MS IT. We do offer users a virtual application, Adobe Reader, for 32-bit clients but we don’t require they use the application. For compatibility purposes, App-V isn’t the right application to use but instead users should use Microsoft Enterprise Desktop Virtualization (MED-V) as this is designed to solve OS compatibility issues. App-V is designed to solve application compatibility issues. We currently are testing MED-V and will look to deploy later this year.
Q: Did Microsoft IT package up all the applications used as part of the OSD process?
A: We “packaged” all the ConfigMgr packages but the actual software packaging process (such as building of the MSI, etc.) came from several different sources. In short, we packaged some but not all of the actual packages used in the OSD process.
Q: Are users responsible for reloading any application not delivered during the installation process?
A: Yes, this is correct. We will restore application-specific data using USMTv4 but we don’t guarantee to lay back down the application.
Q: If we have WinRE partitions, how are those migrated to Windows 7 using OSD?
A: For WinRE-enabled clients, this fell into a bucket that we couldn’t support at Microsoft because it was considered a dual-boot scenario. If this was the case and we detected it via our OSD Setup Wizard, we exit and advise the user that we detected two operating systems on either the same volume/partition or another partition (this is rather trivial using bdeedit like functionality) and would exit. For these scenarios, the user would have to select to format completely their volumes (option in our wizard) or they would need to remove the WinRE (Windows Recovery) partition\volume and then go through the wizard process again. This is not the most graceful of scenarios but, unfortunately, some of the underlying technologies (WinPE) have difficulty in dual-boot scenarios so we didn’t tackle this problem at Microsoft. Sorry!
Q: Why is Microsoft IT running bare metal user experience and asking them for a user Id/password? Why not ask for a userid and try to provision based off of Active Directory (AD) information?
A: We are sure we completely understand the question but we will give it our best shot. The question, we believe, ask why during the WinPE bare-metal experience do we ask for the domain username and password in the OSD Setup Wizard. The reason this occurs is due to the fact that machine objects in Active Directory are owned by the end-user who created them originally. Thus, if the user during a bare-metal experience selects a computer name that already exists in the Active Directory OU then we need to validate they own that object. If they do not, we either error out and ask them to select a new name or depending on the configuration of the wizard we will generate a name for them and continue own. For those interested, we modify the configuration in osdConf.xml that is provided for the wizard.
Q: Does ConfigMgr 2007 SP2 handle packages that are advertised to allow user interaction and work with OSD?
A: We don’t allow packages to be used that are not hard-coded to silent so, unfortunately, we can’t really speak to it with a great deal of certainty. At this time, we would speculate it would be no problem at all though we haven’t had this experience at Microsoft or elsewhere thus leading us to have to give you our best guess. You might can find someone on the ConfigMgr forums who has done it this way and can give you concrete advice.
Q: Of the 120 machines, what % do you support with ConfigMgr driver packages?
A: We have the luxury of having a hardware team at Microsoft who owns the relationship with our various OEMs and this team provided a setup tool to our team that provision drivers on a per-model basis. This tool was a step in our task sequence thus mitigating the requirement that we have multiple driver package payloads to support in ConfigMgr 2007. This is possible to do though would get very, very non-trivial fast and offer a lot of possible scenarios that could easily break. Depending on the number of models at play here, we would probably recommend you keep your driver packages low (like we did) if you have a high number of skus and have a special step that provisions (either a script or a EXE, or something) specific drivers on a per-model basis.
Q: Could the machine that Microsoft IT do not load ConfigMgr driver packages for get their driver support through an internal company WU/MU?
A: Yes, absolutely possible and how we are actually doing it at Microsoft. The key to our Microsoft Driver Sync Tool is to ensure that WSUS 3.0 SP1 or SP2 has the correct drivers for the hardware we have in our enterprise. This is a crucial step and Windows Server Update Services (WSUS) represents the WU/MU service but at the enterprise level allowing for some key management necessary for many enterprises.
Q: Will a customer be able to host an Internal MU for driver installations for break\fix later on?
A: This is actually called Windows Server Update Services (WSUS) and it is the only method to bring something in-house that works with Windows Update (WU) & Microsoft Update (MU). We aren’t currently aware of this infrastructure WSUS –> WU/MU changing in the near-term thus the reason we built our Driver Update Sync tool. As for the OSD process, we have a script (we will share later via a blog) that we run as the final step in our task sequence that grabs all critical, important, and optional security patches and drivers from WU/MU so that our clients have the necessary updates installed or available. We are currently investigating further ways to make this more robust (a future post) but for now this is our method for ensuring that working drivers exist upon completion of the installation of Windows 7.
Q: Our current experience with SMSTS.log is it doesn’t contain all the entries from a new computer nor are the messages in the history of the SMSTS.log. Can you explain a bit about this?
A: Yes, they roll over after so many entries. This is why we copy our logs off to various directories throughout the imaging process. This not only captures the logs before they roll over, but it also makes it nice as they are organized in directories with the name of each phase from which the logs were generated (Install OS, Setup Windows etc.). This is done by running cmd /c xcopy /E /C /I /Y %_SMSTSLogPath% %OSDStateStorePath%\Logs\StateCapture for example where %_SMSTSLogPath% is location where logs are always kept.
Q: How do you make the SMSTS.log grow as large as needed?
A: We believe this can be set through HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\TaskSequence. There are entries like LogLevel, LogMaxHistory, LogMaxSize. This would require that the boot image is changed and the OS during that portion of the install. So you could either A) mount the boot and install image and then load the boot image registry hive and make the change B) Make the registry change on the fly by doing a reg import or add.
Thanks,
-Chris
