The catch with that would be to properly identify them to rebuild monthly. That would be a really unhappy end-user when the desktop team deploys one of these “warm” spares, forgets to tell you about it and the rebuild cycle rolls around.
It’s a great idea, but you should have some serious SLAs in place for when that happens. Especially if loss of user data happens. Mike From: <[email protected]> on behalf of "Schwan, Phil" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, April 8, 2016 at 5:28 PM To: "[email protected]" <[email protected]> Subject: [MDT-OSD] RE: Hot/Warm spare computers? My recommendation would be to keep a handful of warm spares similar to what Andreas described, only I would take it a step further and simply reimage them on a monthly basis via a scheduled Task Sequence that runs at the appropriate point in your monthly patch release cycle to ensure it’s getting the current month’s patches. The paradigm of imaging a machine and leaving it offline on a shelf for six months is one that needs to be broken out of as soon as you can. -Phil From: [email protected] [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Friday, April 8, 2016 3:33 PM To: [email protected] Subject: [MDT-OSD] Hot/Warm spare computers? I am looking for some ideas about this scenario. Our desktop support staff frequently installs computers using OSD/ MDT and then sit the computers on a shelf – sometimes for several months-- before putting them into service. This is mostly because they want to be able to quickly drop a new computer in place if an existing computer fails. If a computer in a critical area, they want to swap out the computer quickly so that critical use is not down for the day. This cause me stress because those machines are in AD and in SCCM but are not active. So they show up on my reports of machines that are AD joined but haven’t checked in in a while (are they lost or stolen or just sitting on a shelf?) They haven’t patched in a while (are they on a shelf or is SCCM agent broken?) It is really difficult to tell the difference between a computer that is off and a computer that is broken. At least the Off machines respond to a WOL typically. Machines sitting on a shelf do not…. Id like to have a task sequence that prepares the computer with the OS and applications and brings it to current patch level, but then is able to put the computer into a “dormant mode.” Dormant mode might mean deleting the computer from AD, preparing the computer to resume the TS on next power on, and then powering off. Then when the computer turns on, the TS should resume. Maybe I’d have a task step to rejoin AD and go through some finalization process – maybe run an install update task to get caught back up etc and then the machine is ready to go. This would get the machines ready faster and would not cause me so much trouble with idle machines on shelves. Is there a name for this already? Good blogs about it? ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
