Your tech staff wants to be able to swap-out existing desktop computers with the least amount of administrative overhead. Basically, they want to be able to walk up with a new computer, unplug the old one, plug in the new one, turn it on and walk away. The stuff on the existing computer should magically end up on the new computer (sans all the usual personal crap that shouldn't be stored on a local computer in the first place).
What are these "stuff"? Applications, default/initial configuration settings, printer mappings, Outlook profile settings, etc.
The Tools at Hand
Active Directory (Windows Server 2012), Group Policy, System Center Configuration Manager (2007, but that's for another discussion), SCCM OSD+MDT+ADK+Coffee, SQL Server 2012, ASP (yes, the sticky, smelly old classic kind), Packaged Software (already loaded into SCCM), a tablet running Windows 8.1 and a bluetooth barcode scanner. Also, a van, a hand-truck, appropriate weather-oriented clothing, hydration substances and a fully-loaded firearm (okay, not for all situations).
Options
Options are good. This is just one option. One that I am fortunate to be working with actually.
If the computer is mapped into the appropriate collections within Configuration Manager, and managed and monitored via logical memberships and dispositional relationships (Active Directory Security Groups, Active Directory Organizational Unit location), you're in what NFL fans would call "the Red Zone".
The Binding Adhesives:
- Assuming that the existing computer finds its way into a functional or organizational related Collection within SCCM, you have a means for aiming things at it by function and/or organization (sector, department, division, business unit, etc.)
- Assuming that the existing computer has things configured via Group Policy, it is likely grouped under a logical OU environment.
- Assuming it is targeted via either query-based Collections (handy), or direct-membership Collections (a little more work but still handy) you have another means for aiming things at it in a logical manner.
- Assuming, and this is a reach for some environments, but very common in others: you have barcode labels on assets that are relational to their AD account names, oooh. You are in very good position to throw a touchdown now.
The Process Walk-Through
- Technician arrives at customer location with new computer, already imaged with a generic, standard "load" (Windows, Office, base applications, etc.) and joined to AD in a generic OU. It also has a functional SCCM client agent.
- The technician gets the existing barcode and the new barcode values. Enters them into a web form (from the computer itself or from a third device, such as a tablet or phone). Hit "submit". Swap-out the hardware, reconnect, power up the new stuff and run off with the old stuff.
In the background:
- The data is queued (in a relational database, such as SQL Server) for the "old" and "new" computer names. Since both already exist in AD and in Configuration Manager...
- A scheduled, or triggered, task invokes a script that queries the database for pending items (those which have not been swapped out yet)
- Step 1 is fetching the "old" computer information:
- AD OU
- AD Security Groups
- AD account description property (if desired)
- AD account location property (if desired)
- SCCM direct-membership Collections
- Step 2 is taking action:
- Move "new" computer into correct OU
- Add "new" computer to same AD groups
- Add "new" computer to same SCCM direct-membership Collections
- Update AD account properties (description, location, etc. if desired)
- Disable "old" computer AD account
- Remove "old' computer from AD security groups
- Move "old" computer AD account to special OU (for GPO management aspects)
- Update asset inventory tracking database (operational status, if relevant, etc.)
- Force a restart of the "new" computer (to force GPO updates, SCCM client policy polling and discovery updates)
- Step 3 - mopping up
- No process model is without exceptions: manual installations, special device installation, white-glove stuff, etc.
Suiting Up
All of this is not only possible, it's not that difficult with the right planning and testing. I'm currently using ASP on IIS from an internal Windows Server 2012 box. The queue is managed in SQL Server 2012. The script process uses VBscript, but will soon be ported to PowerShell. The interfaces are COM, WMI, SWBEM, ADO and LDAP/ADSI. All are very common building blocks in Windows environments.
When was the last time you played with a Lego kit or one of those car/ship/aircraft model kits?
Repeat after me: "It often comes with headaches, but I usually love what I do for a living."
:)
No comments:
Post a Comment