Windows Sysprep Breaking
-
@agray said in Windows Sysprep Breaking:
FOG is on it’s own network with not net access. Completely off our network since our network is 100% static.
Not a problem either on an isolated network or on your business network. The FOG server does need internet access to install fog, but after that it doesn’t. I know some people that have the isolated imaging network will install a second interface in their fog server and connect that to their business network. That way they can manage FOG from the business network, yet deploy only to the imaging network.
Setup PC on our network -> Set to DHCP and hook up to switch connected to FOG and capture
This is one way to do it. Its not a problem. The only issue is when you deploy your image, you can’t/shouldn’t boot the system into windows while its connected to the imaging network if the target computer needs to connect to AD. In your setup you will when you create the deploy task, tell FOG to power off the target computer after image deployment. That way you can move the target computer to the business network before its powered on.
-
When you say register, do you mean activate? If that is the case, I typically don’t activate it while building the golden image. You really have 3 days to play with the image before it starts to complain about activation. We activate it post image deploy in the setupcomplete.cmd batch file.
fog, the first time it sees a machine, it asks you to register the machine, either full or quick.
This is one way to do it. Its not a problem. The only issue is when you deploy your image, you can’t/shouldn’t boot the system into windows while its connected to the imaging network if the target computer needs to connect to AD. In your setup you will when you create the deploy task, tell FOG to power off the target computer after image deployment. That way you can move the target computer to the business network before its powered on.
Not sure, if for what ever reason, I’m imaging different and it’s working. we boot UEFI>tell fog to quick register it>Select capture (on fog machine)>boot into “onboard NIC” and it captures or deploys the image we select on the fog machine
-
@agray If you want fog to manage the computers after deployment you would normally install the fog client and then register the target computer with FOG. But in your case the FOG Server will never see the target computer once it has been deployed. In this case you don’t need/want the fog client on the target computer and you don’t “need” to register the target computer with FOG. Once you have the golden image captured, you can deploy subsequent target computers right from the iPXE menu. There is a deploy image option. If you use this menu you don’t need to register the computer. This is kind of like a load and go menu. The only system that needs to be registered is the golden image computer so it can be captured.
-
@george1421 How do i capture without register with FOG?
-
@agray said in Windows Sysprep Breaking:
How do i capture without register with FOG?
You can’t. You have to register your golden image computer with FOG to be able to capture it. You can deploy without registering with FOG right from the iPXE menu.
-
@george1421 Should i register before sysprep or during the sysprep boot? Or does it even matter?
-
@agray I would register the FOG server before you get into syspreping the device. In my case I have a VM that always build the reference image on, so it has been registered in FOG from day one.
-
After testing with the FOG client on my reference/golden image I found my issue which may help. I would task my client PC to be added to AD when the Auto Delayed service starts. Well, when a computer is being restored with the Windows 10 image it will start the services. Since it is starting the services it is trying to join the domain while the system is being sysprepped. This caused Windows to come up with an error to install or boot and various other errors. After the service was stopped in the reference/golden image then restoring had no issues. I manually have to enable the service and start it as well. The big issue turned into a okay fix.
-
Sorry I’ve been on medical leave so I haven’t had time to work on this, but, unfortunately, it is not solved.
I have made my own unattend.xml file, i am following this guide (https://forums.fogproject.org/topic/9877/windows-10-pro-oem-sysprep-imaging/11) almost exact. Using it’s batch file and operations but not using a setupcomplete.cmd
I personally think it’s something i’m doing in the audit mode. I’m not connecting to our Domain but I am setting a static IP for just installation process, then change it back to dynamic for sysprep and capture.
The software I am attempting to install is the following: VNC, Java, .Net, Silverlight, VLC, Firefox, Chrome, Cute pdf, Munis, Laserfiche, Office 365 (not activated), Sophos Endpoint, Comm Portal -
@agray Antivirus products sometimes cause trouble when installed before sysprep I believe.
For example: Bitdefender has a page about it
-
@Quazz said in Windows Sysprep Breaking:
@agray Antivirus products sometimes cause trouble when installed before sysprep I believe.
For example: Bitdefender has a page about it
Symantec is the same, there even is a program that you have to run in order to reset everything for sysprep to work.
@agray I cant seem to find your response into what the log files say. Did you check them? Or have I just not seen it and its in the thread somewhere?
-
I have to provide a wet blanket moment here as a moderator.
The Windows OEM EULA doesn’t allow for system cloning with OEM media. You can only deploy images directly from OEM media. You are not allowed to create a golden image with OEM media and then clone that image to multiple computers. If you want to do that legally you must use volume licensing media. The cost of volume licensing media is not that great. If you have 100 computers with Win10 Pro OEM on it you only need one Windows 10 Pro VL license. This is allowed by the EULA. You MAY NOT have 100 Win10 Pro OEM computers and upgrade them to Win10 Enterprise this way. In this case you need 100 Win10 Enterprise licenses. As long as you are redeploying Win10 Pro OEM with Win10 Pro VLK then you only need one volume license. Most SMBs will purchase 1 Win10 Pro VLK and 4 other client or RDS licenses to get to the minimum of 5 points to get into the MS Volume Licensing program.
In regards to preinstalled software. I would avoid installing any software that depends on a unique system id (GUID). I would avoid installing those softwares in your golden image. Because each cloned system will have the same software GUID. Enterprise AV is a big one that relies on a unique system GUID that should be installed post image deployment.
-
@george1421 My Windows 10 UBS is from the media creation tool but inside my unattend.xml, it has our volume license product key. Do I need to use the iso from the volume license?
-
@Taspharel I don’t have access to the logs. The sysprep goes through properly until I boot it back up; then it provides an error and will not boot at all.
-
@agray said in Windows Sysprep Breaking:
Do I need to use the iso from the volume license?
I would say yes, start with your VLK media. The setupcomplete.cmd will run as expected as well as a few other things that MS has blocked from running if you use the OEM media kit. And if it was me with MS coming out with 2 releases per year… I would create my reference image with MDT (microsoft deployment toolkit) to avoid that whole audit mode mess. Just have MDT create your golden image on a VM using the lite touch approach. You will probably spend a better part of one work week setting up MDT and perfecting your image. But on the back end, when a new version of win10 is released you just import the media and copy over your task sequences to a new task sequence and deploy. Using the lite touch approach all of your applications and custom settings can be auto installed into your Golden image. I can go from having a new version ISO to start to deploy a new golden image in about 20 minutes. That golden image will be ready to be captured by FOG without any human interactions after the task sequence has completed.
-
This post is deleted! -
@george1421 I looked into MDT and it looks a lot easier and simplifies FOG. There is a problems I am seeing and would like to know how you work around them.
- How does Fog interact with the WIM files?
-
@agray said in Windows Sysprep Breaking:
How does Fog interact with the WIM files?
It doesn’t. WIM files are windows only.
Maybe I did not explain the concept for MDT well enough. The idea is to use MDT to build your golden image in a virtual machine. MDT will take the WIM file and deploy it to a virtual machine. You can configure MDT to also install any current windows updates as well as any global applications you want into your golden image. In my case I use vSphere, and part of setting up MDT is that MDT will create a iso boot disk that connects the target computers to the MDT server (which can be run on a windows desktop OS) to run the install task sequences. When the MDT creation process is done you will have a computer ready for sysprep. At this point MDT’s job is done it has created your golden image. Now you sysprep the golden image and capture with FOG for deployment.
You could use MDT for low volume image deployments (< 5 a week). The differences between MDT/WDS/SCCM and FOG is that the former use file level cloning where FOG/Ghost/Clonezilla use disk block level cloning. Both methods have their advantages and disadvantages. The advantage of FOG and disk block level cloning is SPEED. FOG can deploy a disk over a 1 GbE network at a rate of 6GB/m or about 4 minutes for a 25GB fat image. With MDT/SCCM it will take about 1hr to fully deploy a windows image.
Each application has its roles in this set.
- MDT creates a repeatable and verifiable golden image the same way every time.
- FOG captures and deploys images very fast every time.
-
@george1421 What George says, about OEM.
Also try something simpler first. Instead of creating a gold-leafed banana sundae, just put a single scoop of ice cream into a bowl first, then add things one at a time with each attempt … though I’d blame the AV straight up. ESET Endpoint AV pulls the same with its self-defense setting which must be disabled prior to sysprep. If you check the sysprep log it will show you where the error occurs and I’d bet dollars to donuts that it’s the AV.
-
@george1421 So MDT is basically adding more steps to take out the time of windows updates?
MDT would make basically be my physical machine would be easier to restart every time it fails?
I have yet to try and capture a VM using FOG so I may have some issues with that, I don’t think the process would be much different, right?