Image Build–Manual or Build & Capture?
WHY Series #2
Late last week I got the following email via my contact form. It seemed like the ideal topic for the next post in the series. (Thanks Matt for the message!)
I have a question for your WHY series. I was debating with a co-worker yesterday why you would use the "Build and Capture" task sequence for OSD instead of capturing a system that you already have or have built with another method. I have a few ideas on advantages and disadvantages, but I would like to hear your opinion.
I am going to make a couple of assumptions based on what I read in the question. I interpret “a system that you already have” to mean an existing physical machine that would be captured to create an image. This might not be what the reader intended, but it should be addressed in this post regardless. Best practice is to create a hardware independent image on a virtual machine. (Need to address reasons why for that one in a future post.) I also see the phrase “built with another method”…which I interpret to be essentially a manually built image (as opposed to one using a B&C task sequence).
At the core, those are your options for image creation…automated with a Build & Capture task sequence or build it manually. A slight variation is to use the “Pause task sequence” step in an MDT task sequence to perform a step that can’t be automated…essentially automate all of it except for this one step.
Factors Impacting the Image Creation Process
When looking at the question of whether to manually build the image or use a Build and Capture task sequence, there are several key components that should be considered:
- Image updates. Don’t consider an image to be “golden”…think of it as “current”. This can be a key distinction. Gold implies that it will never change. Current deals with the reality that an image is going to need to be updated. (Let’s not even get into the Thick/Thin/Hybrid image scenario…that’s a discussion for another day…perhaps another “WHY” post.) With that said, unless you are the most hardcore of “thin image” proponents, your image will at least have the OS and updates. Which means that within a month of image creation (Patch Tuesday), the image will be missing necessary updates. How often do you update it? Remember, anything that isn’t in your image has to be installed after the image is laid down…which adds time. I know of a very major company (if you live in the US, you have their products in your home) that had not updated their XP image in several years. The post image update process took a couple of hours to deploy somewhere around 200 updates that were not included in the image. Application updates/upgrades are also part of this equation. Basic gist is that images MUST be updated…ideally on a regular basis.
- If applications are included in the image, are the applications packaged and able to be installed silently? If so, then that process can be automated. If not, then it has to be a manual step. Same goes for image tweaks.
- Ideally you would like to use the same processes for managing apps and updates that go in your image that you use for managing the existing systems in your environment. You already have a “Patch Tuesday” process. Use the same process when building the image. You already have a process for pushing out application upgrades/updates. Use the same process in your image build.
- In the end, you MUST have consistent repeatable results. You need a process that produces a reliable image every single time.
- Lastly, you are busy. I’ve never met an IT person who had too much time on their hands. You need this process to take as little time out of your day/week as possible.
With those factors in mind…lets run them through the grid of our methods for image creation and see how things shake out.
Build and Capture Image Creation Process:
If your core applications that will go in the image can be installed silently…and if you are using either WSUS or SCCM for deploying updates, then this is the ideal situation. Your B&C task sequence could be as simple as “Click Next” and come back later to see your shiny new WIM file. Once you’ve got it working (which I won’t deny could be challenging) it couldn’t be any easier. Once it is going, you will never look back. I know of at least one company that has a recurring Task Sequence deployment to a virtual machine…to create a new image the day after Patch Tuesday each month. Completely automated. Score!
Because the task sequence is automated, there is very little time involved. Just click next and check on it later. Because all of the tasks are automated, there isn’t any room for admin error. Because it is automated, you are more likely to update your image on a regular basis. The process IS standardized and repeatable. Oh…and if a step does have to be performed manually, use an MDT task sequence with the “Pause” step to automate as much as possible…and only do the non-automatable tasks manually.
Manual Image Creation:
Manual is…well…manual. You install the OS from DVD/ISO. You install each app. You apply all the updates. You run Sysprep. You capture the image. All manually. Hopefully you are following a checklist. Hopefully you don’t forget a step. Good luck with that.
The manual image creation process is characterized by the following:
- Slow. All those manual steps take time.
- Time consuming. Because it is slow, realistically, you will not update the image as often as you should.
- Open for admin error (i.e. forgetting a step or installing a component slightly differently upon image rebuild)
- Not standardized/repeatable
Overall…friends don’t let friends use a manual image creation process. You might wish it on your enemies though! ;-) However…see my conclusion below for one instance where you might use an existing image.
Conclusion:
If you’ve followed my blog for long or have seen my presentations at MMS or TechEd, then you should have known I was going to land on the side of using the Build and Capture Task Sequence before you even started this article. In my opinion (that I think I’ve adequately backed up with solid logic), using a B&C task sequence to create your image is the only way to go. It just makes sense from a time/automation/repeatability/manageability standpoint.
The ONLY exception that I see to this is if you are migrating from an old technology (i.e. Ghost) to SCCM, AND you are migrating from XP to Windows 7 / Windows 8. In that instance…would I recommend going through the process of recreating all of your Windows XP images…that you are going to be getting rid of soon anyway? No. In that instance I would say go ahead and capture that existing image (or if it is already a WIM file…see if you can deploy it as-is). Don’t spend the time recreating the image that you are going to be dumping (since XP EOL is coming up very soon!).
Would love your comments and feedback. Keep the ideas for future posts coming!
Until next time…keep asking the right questions.
Computer Group Membership Change Without Rebooting
I was working with a client this week where we had a need to create a special Group Policy Object for a pilot scenario. This GPO needed to be filtered to only apply if the computer was a member of an AD Security Group. We could add the machines into the group, but we needed to not be forced to reboot all of the machines in order for the group membership to be effective. After doing a bit of searching I found out how to do this…use the “klist” command. This is native to Windows 7 and Windows 8…and to Server 2008 and later. It is not included in Vista…and I’m not sure about Windows XP (but you should be looking at getting off of XP anyway!). The command to trigger this is:
klist –li 0x3e7 purge
Klist with the purge switch forces the computer to refresh the Kerberos tokens…which also effectively recognizes the group membership changes. The “0x3e7” is the part of the logon id that identifies the computer account (Local System).
Windows 7 Customizations
Over the last few years as a consultant I’ve had numerous engagements where clients wanted to customize the look/feel/settings in Windows 7. Different clients had different requirements around which customizations, whether it was permanent or a preference, etc. Below is a list of several customizations that I have helped clients perform. Many of these are found at various locations in forums, blog posts and Microsoft documentation. My goal is to gather these into one location so that it is easier for some of the more common (and for that matter some of the more obscure) customizations to be found. These are in no particular order. I will update this list from time to time. If you have any favorite customizations that you’d like to pass on, email me on my contact form and I’ll add them in. This post is REALLY long, so click the “Read More” link if you want to see the customizations.
Bluetooth Mouse Losing Connection–Fixed
For the last few years I have been using the Microsoft Wireless Notebook Presenter Mouse 8000 and absolutely love it. I got it as a gratuity for participating in a focus group. I love that it is responsive and gives me the ability to control PowerPoint or media controls while giving a presentation to a client.
My one frustration with it has been that it would randomly lose connection to the computer when using my laptop’s internal Bluetooth adapter instead of the included USB Bluetooth dongle. I don’t want to keep up with the USB dongle…I want to use the internal Bluetooth. But I also want the mouse to always work. I had done internet searches on a couple of occasions to no avail…until recently.
A couple of months ago I did another search and came across an article where someone had been having the same issue and had a potential fix to the issue…she nailed it. The issue is that the computer is turning off Bluetooth to save power. The fix is really simple.
Open up Device Manager, then open up Bluetooth Radios.
Double click your Bluetooth adapter to view properties, then switch to the Power Management tab. Uncheck the box for “Allow the computer to turn off this device to save power”.
After unchecking that box, I have not had an issue with the mouse losing connection in over two months. Problem solved. Big time thanks to Sheryl Canter for posting the fix in the article linked to above.
Speaking at MNSCUG.ORG
Don’t know why I didn’t think to post this earlier, but I am speaking at the Minnesota System Center User Group (MNSCUG.ORG) this week. I will be talking about Operating System Deployment with ConfigMgr, and addressing some of the particular gotchas to look out for with Windows 7 deployments.
If you are in the Twin Cities, come check out the user group. We’d love to have you.
The meeting is tomorrow (11/18) at the Microsoft office in Bloomington. Food and beverages arrive at 4:30, and the meeting starts at 5:00. We should end around 7:30 or so. There will be some nice door prizes including two copies of the MMS 2009 post conference DVDs…but to be eligible for the door prizes (and to help us plan for food) you must register at the link below. Hope to see you there!
Windows XP Downgrade Licensing
Recently while helping out with a Windows 7 event at a training center here in the Twin Cities, I got into a discussion with one of the attendees who was planning the move from XP to Windows 7 for his company. In particular he was expressing concern about the loss of support for Windows XP, and one of his main concerns was related to his perception that the end of support for XP also meant that he would no longer be able to legally install Windows XP.
That prompted me to ask some questions and do some research into whether he was right or not. Does the end of support mean that he would not be able to install XP via his enterprise deployment system? In my research, it appears that he may have confused the lack of ability to purchase Windows XP with the unrelated issue of can he legally install it. He did not take into account OS Downgrade Rights.
In layman’s terms “downgrade rights” is the ability to purchase a newer operating system license, and then downgrade that license to allow you to install an earlier OS. For example, you can purchase Vista or Windows 7 and then use the downgrade rights to install Windows XP…even though the license you purchased is for the newer OS.
BTW…let me make one thing clear now before I am misunderstood in this post…I am not advocating staying on Windows XP. I made the move to Windows 7 at the Release Candidate stage. It was rock solid then, and the RTM is equally rock solid. For that matter…I ran Vista on my production laptop starting at Beta 2…and was very happy with it. This post is not telling anyone to stick with XP…it is simply intended to clarify the licensing issues of what you can do if you have a business need for some systems to stay on XP. (i.e. you have older machines that may not be capable of running Vista/Win7 that will stay in use for a while longer…and you still need the ability to image them as needed.) So…with all that said…
Downgrade rights can be broken out into two categories based on whether you have a Volume License agreement with Microsoft or not. If you have a VL agreement (Enterprise Agreement or a Select Agreement with Software Assurance on Windows), your downgrade rights are practically limitless. The quote from the Downgrade Rights Volume Licensing Brief (this refers to Vista, but my assumption is that Windows 7 Enterprise would also fall under this…although it should be noted that this is my assumption…not anything I have seen officially in writing from Microsoft):
If I have Windows Vista Enterprise, what can I downgrade to?
Downgrade rights in the Volume Licensing programs provide customers with the right to downgrade to any prior version of the same product. Windows Vista Enterprise is a new type of product and does not have a prior version. However, customers licensed for use of Windows Vista Enterprise are licensed for Windows Vista Business, and it can be downgraded to the Windows XP Professional, Windows 2000 Professional, Windows NT® 4.0, Windows NT 3.51, Windows 98, or Windows 95 operating system.
If you don’t have a Volume License agreement and your desktop OS license is from the OEM, you fall under the Downgrade Rights for OEM customers. This is a different section of that document that provides a limited time frame for how long your the OEM Downgrade Rights last. Essentially, the OEM Downgrade rights are for 18 months after the General Availability of Windows 7 or the release of a Windows 7 Service Pack…whichever is earlier. GA was October 22, 2009, which would make the cutoff April 22, 2011 unless a SP is released earlier than that. From the brief linked above:
Can I downgrade my OEM version of Windows 7 Professional to Windows XP Professional?
For a limited time of 18 months after the general availability of Windows 7 or the release of a Windows 7 Service Pack, whichever is earlier, the OEM license of Windows 7 Professional and Windows 7 Ultimate will include downgrade rights to Windows XP Professional. After that period the OEM license will enable downgrade rights to Windows Vista Business.
Okay…so that covers downgrade from Windows 7 to XP. The other question for companies who have a desire to continue to roll out XP would be related to Windows Vista. Vista will continue to have downgrade rights to XP…so when will Microsoft stop selling Vista…because technically you could still purchase Vista and downgrade to XP after the 18 month cutoff mentioned above…if they are still selling Vista at that point.
So…hopefully that makes the downgrade rights issue a bit clearer than mud.
Modena Tools (OSD Tools and Driver Sync)
I got an email from a friend a while back tipping me off to some OSD tools in development by Microsoft that I hadn’t heard about. The codename of the project is Modena. It is currently in beta and can be found on the Connect site.
So…what is Modena? From the Cravings of OSD blog…
Modena is a “collection” of tools aimed at simplifying your deployment tasks when using Configuration Manager 2007 Service Pack 2. … Modena, with OSD Tools and Driver Sync, includes the blueprint we use at Microsoft to deploy Windows 7. We provide our end-user experience, exported task sequence, pre-flight scripts, and our driver sync tool to simplify management of drivers in your enterprise.
I have not been able to install them in my demo environment to test them out yet (hope to do so this week), but from what I could read about so far…I’m pretty excited about what I saw. It appears to be a pretty comprehensive “Front End” to the OSD process along with a tool to simplify the driver management component of your OS deployment. Being that those two components are where a lot of companies tend to have the most issues in the OSD process…this is a welcome addition to the OSD toolbox.
You can read more about what is included in Modena in a fairly expansive blog post on the “Cravings” blog.
Free OSD and Windows 7 Seminar
At the end of this month I will be leading a free half day technical seminar on Operating System Deployment at New Horizons in Edina MN. I will be doing a version of the Operating System Deployment session that I delivered at MMS and TechEd this year along with talking about Windows 7 deployment. The Windows 7 component will be relaying the experience that I have gained in deploying Windows 7 internally at Virteva using ConfigMgr.
The seminar will be on September 30 from 9:00-11:30am Central Time. It will be offered for both in classroom as well as remote attendees, so you can attend even if you can’t make it to Edina that day. If you would like to attend, you can register at the New Horizons site. When you sign up, there will be a question asking “How did you hear about us?” at the bottom of the registration form. Please answer “Other” and put “verbalprocessor.com” in the “Other” field.
I look forward to seeing you there!
Windows 7 – Problem Steps Recorder
Today I have been downloading and listening to various MMS sessions that I missed while at the event. Normally I have my schedule double booked (or even some time slots triple or quad booked). Combine that with the fatigue that sets in after the second day…there are a lot of really valuable sessions that I’m simply unable to make it to during the week.
One of the sessions I missed at MMS but listened to this morning was “SC15 – Windows Client: Roadmap and Introduction to Windows 7 for Enterprise Customers” by Jeremy Chapman. During his session he performed a demo of a Windows 7 feature called the “Problem Steps Recorder”. What this program allows you (or one of your users) to do is record what happened in the event of a “problem” on their system. You start the PSR, then recreate the problem that you were experiencing. It essentially takes screenshots as you are going through the process and spits out a zip file that has an MHTML file in it complete with screenshots and detailed steps of what the user was doing at each step along the way.
This will prove to be very useful. Back when I worked the help desk I can’t tell you the number of times (and honestly don’t want to remember the number of times) that I tried to get a user to accurately describe what they were doing when a problem came up. Sometimes it was a legit problem…sometimes it was a PEBKAC issue. This feature would have saved me huge amounts of time in figuring out what was actually happening.
The presenter mentioned that this app can be launched either manually by the user or…and I like this…you can build it into the application so that it launches automatically when the app fails and ask the user to recreate the problem.
Subscribe
Recent Comments
-
The Realm of the Verbal Processor 