I would like to be able to image a machine with a golden image such that an unattended install would be launched from HIREN boot USB.
So far, I am able to create a Windows 10 x64 Enterprise 20H2 OneTouch.iso using MDT and ADK , and deploy that .iso to a VMware VM.
I know that I still need to (1) de-bloat Windows, (2) run sysprep and (3) capture the image. But I am confused about the following:
How I would get that image into the HIREN USB?
There are so many things to keep track of: driver from different Mfgs, the de-bloat scripts, the results images etc . . . What would be the best way to do this? Would GitHub/GitLab work for all of this?
There are so many de-bloat scripts out there, where can I get the most up to date to use as a base and then how would I keep track of changes and stuff? Git?
If you use something other than HIREN, can you say what? I see that MDT has an “add tools” feature. Would that work for adding things like 7z to the Windows PE environment?
To further clarify, this is something that I am trying to learn for work to get some clarity, knowledge, know-how and piece of mind.
My work place has a lot of information hiding and there are different version of images etc . . . in different places. The techs and admins do not share information about the setup so I can’t even troubleshoot things properly because I don’t have the full picture. Is there good reason to be so covert about setups, workflows, organizational structures etc, how SCCM and USB drives get setup? I mean we are talking a level or ridiculous where the version of the OS on the USB drive does not match that of the version in SCCM and no one says exactly which version is being used (you have to install for that) . Anyway, enough of my rant.
All suggestions are welcome. Can anyone please set things straight for me, or somewhat straight?
Hello, I have no experience with using HIREN so I can’t say if my method is an improvement over yours.
First my personal advice would be to speak to your management about wanting to standardize image deployment. Then develop a proof of concept, and present it for approval. My previous employer had the same issue every Tech would create their own image for their specific area. An audit of the images found there was some “free” version of windows and software on many of the companies’ machines. Which lead a coworker of mine to develop a standardize system with a fully documented deployment process.
When I joined my current employer, I implemented a similar system. My current environment is a local college lab environment, roughly about 15 labs with 20-30 machines per lab. We have to update our windows 10 every year to the latest version. Additionally, our instructors need specific software depending on the courses that will be taught in each lab, which changes year to year. So, for our case it is easier to deploy a new update image every year.
I have domain admin rights and access to create VMs. I created a CentOS server and installed Free Open-source Ghost aka FOG (https://fogproject.org/). FOG supports PXE network booting, so we deploy our images over the network. FOG can have multiple images stored that can be deployed to machines. You can also boot to live images. We use this feature when we have to perform some data recovery, we can boot into partedmagic on the affected machine. It also supports BIOS or UEFI boot options, which require access to the DHCP server of the network.
FOG is a very powerful and could probably address all my deployment needs, but I just haven’t dedicated the time to mastering it.
As for bloat, drivers and software I personally deploy a bare bones Windows 10 image, with as much bloat as possible removed. I then use PDQ (https://www.pdq.com/pdq-deploy/) and chocolately (https://chocolatey.org/) to install drivers and software post base installation.
My workflow is:
Create a new gold image for our labs and sysprep the image.
Capture the image with the FOG server.
Deploy the image to the lab machines.
Check that deployments installed with no errors (usually a walk-through of the labs).
Deploy script with PDQ that will install drivers.
Deploy script with PDQ that calls chocolately to install specific software packages.
You could automate this more with the paid version of PDQ, but for my small environment this is more than enough.
thanks so much for the advice and workflow tips. I have never tried FOG.
I have had this conversation; it went no where. Management, in my opinion, wants this to continue for “inside politics” reason.
I started this and am working with a Windows 10 20H2 Enterprise x64 image in a VM. So that is a good start. My problem is that I don’t really have anything like a lab at work, so I do all this at home. I am sure that I will eventually get a good image but in order to get people onboard, I have to have something like HIREN because the administrators and management are split between PXE boot and USB sticks. My take is that I use whatever works but it needs to be unified and consistent accross the organization. I can see the argument for having USB sticks because as a field tech I have had to deal with situations where PXE would not work or there was no network or etc . . . because reasons . . . As you can see there are lost of issues.
I am responsible for 2,500 machines on one site alone. So my situation is a bit different. Not in the sense of harder because of the machine numbers but in the sense of not having a unified solution is terrible.
Unfortunately I have no control over this aspect:(
This is great. I will definitely check out FOG, chocolatey and pdq but would have to come up with an all MS alternative because admins are highly averse to Linux because . . . Linux bad and Windows better . . . grinds my gears but that is what the reason is . . .
When you do you golden image do you try it in a VM first and then deploy it to reference bare metal or do you just do everything in a VM. I was astounded when I was told that non of the images used are actually tested on bare metal . . . I cannot reason my way through this one. How can you just trust that all drivers and software will work?
I have had this conversation; it went no where. Management, in my opinion, wants this to continue for “inside politics” reason.
ooof. That is always a bummer. If they haven’t given guidance on deployments procedures then you are probably alright with continuing your development.
My take is that I use whatever works but it needs to be unified and consistent accross the organization. I can see the argument for having USB sticks because as a field tech I have had to deal with situations where PXE would not work or there was no network or etc . . . because reasons . . . As you can see there are lost of issues.
I absolutely agree, a unified method is best. There should be guidelines and procedures in place on how to address the deployment of systems both on and off the network. I personally don’t like the physical USB as it adds more avenues for potential harm, such as loss or damage to the media. However, that being said I agree with you, use whatever works.
This is great. I will definitely check out FOG, chocolatey and pdq but would have to come up with an all MS alternative because admins are highly averse to Linux because . . . Linux bad and Windows better . . . grinds my gears but that is what the reason is . . .
IT professionals that are not fans of Linux?! But the internet runs on Linux! … I can’t wrap my head around that. But they would be glad to know that FOG, PDQ and Chocolatey are all supported on M$ Windows/Server.
When you do you golden image do you try it in a VM first and then deploy it to reference bare metal or do you just do everything in a VM. I was astounded when I was told that non of the images used are actually tested on bare metal . . . I cannot reason my way through this one. How can you just trust that all drivers and software will work?
Yes! we absolutely do bare metal testing before finalizing we begin deploying the image to our labs. We create the golden image as a VM then deploy it to test systems with the same hardware configuration in our labs. From there we run the scripts to install the drivers and software to ensure there are no issues with the process. If we encounter any compatibility issues or unforeseen problems we usually iron them out at this stage. Our whole testing process usually runs about a week from all of our hardware configurations.
Some people like to YOLO their deployments. Personally, I am not a big fan of that.
. Anyway, enough of my rant.