Best practices for computer lab deployment?
We're evaluating a K1000 and K2000. What I've been testing is using the K2000 for OS scripted installs only (currently Windows 7 64bit) including naming the machine (we've got some adapted postinstallation tasks to grab the hostname from a file based on MAC address), then letting the K1000 install software based on smart labels and also doing updates (replacing our WSUS server in the process). With this setup, I'm envisioning only needing a few scripted install types on the K2000 (win 7 32/64 bit, Max OSX).
What I'm shooting for is having a technician go to the K2000, select a Lab of computers (via a k1000 smart label), tell it to image the computers, go home, and return in the morning to a lab that is completely ready to go for students (OS installed, fully up to date, expected software installed).
Is this something other people are doing already?
Is there some best practices on this anywhere?
Is there anything that we need to do on the K1000 prior to kicking off a lab for reimaging? My concern is that if the computers already exist in the K1000 and it thinks the computers already have the software installed that it may not install the software. I don't think this is the case, but I've been running into some issues in my testing.
Answers (2)
if you are installing the k1000 client during the k2000 post deployment it creates a new kuid and the k1000 will treat it as a new machine. you need to use smart labels and force updates so it checks for the deployments.
Comments:
-
In K2000 3.5 we automatically copy the KUID up to the K2000 and you can then use a new default task Apply KUID before installing the KACE Agent to preserve that machine's record in the K1000. - andrew_lubchansky 11 years ago
-
Does keeping the KUID gain you anything? I couldn't really find any information on why that would be an important thing to keep across image deployments - tmashos 11 years ago
-
Creating a new KUID would create an entirely new record within the K1000 without removing the old record, thereby having two records for the same piece of hardware. This would orphan the old record as well as take up an additional license. - andrew_lubchansky 11 years ago
-
I've not noticed that be an issue with my testing. Since the machine names are the same, it seems to be taking the same slot without duplicating records. I haven't checked if the KUID is the same though (I'm not doing anything special to keep it across installs) - tmashos 11 years ago
-
Well all things being equal it should generate the same KUID. But say that you swapped out a HDD or a new Mobo. A new KUID could be created even though the computer is the same asset.
In the end, its really not a big deal to run the Apply KUID task that is built in and just be sure that it uses the same KUID. - andrew_lubchansky 11 years ago
There are many ways to accomplish what you are looking to do. I worked in education for a long time with a few years with the K2000. Here are my thoughts:
Scripted Installs (Windows only btw, no Mac) + K1000 can be a powerful combination. The basics of what you describe are correct. One method is to utilize Breadcrumbs to kick off the K1 post K2 deployment. Take a look at these sites. There's a ton of knowledge here.
K1000 KKE's: https://support.software.dell.com/k1000-systems-management-appliance/kb?k=KKE
More on the point about your question, about kicking off a lab deployment to refresh overnight, really depends on your environment. If you have Network Boot setup as your first boot device in the lab, you can use Boot Actions witin your K2 to automate kicking off a deployment.
Another possibility is to use System Imaging. The WIM Imaging built into K2000 3.5 is extremely fast and might be able to deploy faster than a Scripted Install+Managed Install combination. Can always use Managed Installs/Patching on the K1 with System Images too. System Images work great for Computer Labs because of the CopyProfile function within Sysprep, allowing you to tailor a User Experience for your students.
Just a few thoughts.
