Last active 4 months ago
Oh we do pretty much the same then. We have two images, one that is sysprepped but captured before the machine boots, and another that is not sysprepped for easy updating. All the cleaning and desktop personalizations are scripted for after the first login. Really the only thing that is left is small things like activating AV, signing the user into the Office products for convenience, and clearing the TPM for BitLocker if the machine is reused.
If you don't do scripted installs of software, are all the icons available on the start menu and desktop? I'd rather do that if it works since installing some of the software can be a pain.
On a side note, for really large pieces of software like Visual Studio 2017 Offline Installer, we use a rather powerful server to compress it down from about 30gb of thousands of tiny files to a single 22gb zip file that is decompressed client side. Makes deployments much faster.
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.
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.
I see what you're saying, I see that now. I guess that solves both problems then, thanks.
Before I start here's a little backstory:
We have several MacBook (donglebook) Pros that need to be imaged, but they don't have Ethernet ports, so we were going to try using a USB-C to Ethernet adapter. Unfortunately the dongles have a fixed MAC address, so CloneDeploy thinks we are just deploying the same machine over and over again. So, we were looking to use the wifi netboot and point the server towards the internal network rather than the test bench switch we have setup.
That being said, we need to increase the compression so I'm not moving huge amounts of data over the corporate wifi. I noticed that there is a decompression setting for Multicast, but what about Unicast? Does decompression happen client or server side for Unicast?
I just deployed another machine that had a Toshiba type SSD and completely different ending on the model number, and all appears well. I'll continue to keep an eye on it, but it looks like it's been solved.
Alright, I don't have any machines to deploy right now, but when the next batch comes in I'll give a quick update. Thank you for your help.
Looks like that did it! Coincidental that the SSD in my machine had the exact phrase you were parsing for. Since we get different machines with different models, will this change how they are imaged or break things if a different SSD model is used?
Oh yeah, I see that now. Why would it do that for just partition 2 though? For partition 1 and 3 it's reading the correct byte size.
I have not. A previous incarnation of the clonedeploy server had some changes, but I have since rolled back to a previous checkpoint and everything should be fresh. I just deleted the computer, group, and profile and rebuilt them but to no avail.