Clone Deploy the V Way

  1. 2 weeks ago
    Edited 2 weeks ago by vbourke

    With how customizable CloneDeploy is, there's many, many ways to setup one's imaging environment. At my company, we use CloneDeploy for reimaging machines for new hires or for redeployment, which makes us need a rather dynamic deployment method. It took me a few months to learn the ins and outs, but we finally got a stable setup that works quite well.

    At the base of the imaging system, we have a syspreped Windows image with all the necessary changes done to the built-in administrator account, things like internet settings, basic internet addons, and really anything that doesn't get updated or need to get updated. To make sure it's as stable as possible, we have one image per device model so the drivers are never changed. These images are updated every month the same time patches are done by using a secondary non-syspreped image. The unattend.xml file then uses the copy profile switch to transfer these things to the profile being built.

    Next, we have a large list of programs in the resources folder on our clonedeploy server. Each program has it's own folder, where inside that folder there are two folders, one named Scripts and another with the name of the program again. In the scripts folder there are batch files and any scripts, license keys, or anything else that might be required for silent deployment. When deployed with the "Folder Contents" setting, we end up with a folder in the root of the C drive named Installers, with folders inside that for each program and a "master" folder named Scripts with all the silent install items. There's also one other Scripts folder that goes into the root of C with various scripts relating to prepping a new machine, like the one to fire off batch scripts, setup the start menu, and install any programs that don't play well with being installed during sysprep. When deploying, we select which programs we want installed based on the profile the computer is attached to.

    The first thing that is done when the image is deployed is the machine goes into Audit mode and runs a batch script from C:\Scripts that runs ALL of the batch files in C:\Installers\Scripts. The point of this is to upgrade any of the programs or add any new programs in, all we have to do is configure or update it in the resources folder on the clonedeploy server. Depending on the profile and how many programs are selected this can take 5-30min.

    Once this is done, the image gets generalized to make sure that any hardware differences between device types (not models, those are the same) is taken care of, then specialized and the device is attached to the domain and the user profile is added. To make this more seamless the OU(s) it's placed in when joined are determined based on custom attributes added to the computer in CloneDeploy when the computer is added to the appropriate group and the profile is added to a custom field after that, utilizing the Sysprep Tags feature on CloneDeploy.

    This whole process is entirely automated takes 30-60min, based on how many programs are being installed. After the device is joined and everything is configured, the OOBE screen is skipped to end up at the login screen. We then have the user login, and the final preparations begin. Any sensitive files like the unattend.xml and most of the installers and scripts are removed, the taskband and start menu are adjusted, default programs are changed, and the wifi is setup. There's a few small things that need to be changed simply because it's hard if not impossible to automate them on Windows, but for now our system is 95% complete.

    I'm sure there's some optimizations we could make, so if there's any feedback I'd appreciate it! If you have any questions about our setup or how to setup, don't hesitate to ask.

  2. clonedeploy

    Jul 28 Administrator

    Thanks for sharing. It's seems like you are using a lot of features the others may not be. It's exciting to hear about your workflow.

  3. No problem! As far as the hardware configuration goes, we have the server attached to a bench switch so we can image in the security of a locked room with two bonded nics, and the other two bonded nics are attached to the internal network. Some bridging and blocking of port 66 on the internal side ensures that the ProxyDHCP server that points to the bench switch doesn't propagate to our internal network, but that the computers that are imaged can still reach our internal resources. I must say that bonded nics are a must if you plan on imaging more than 2 machines at a time.

    I have a sudo Munki server setup, but I haven't messed with it yet since MacOS Sierra isn't fully supported yet. That and setting up SMTP are things I'm working on in the near future.


or Sign Up to reply!