WIN10 Multicast Imaging Issues
-
I just made the switch over to WIN10 in our district. I just got finished making my sysprepped images for WIN10.
I followed: https://forums.fogproject.org/topic/9877/windows-10-pro-oem-sysprep-imaging
I was able to successfully push my image to a lab full of computers. Everything looked to be going so well. I tried pushing my image to another lab full of identical computers (minus SSD drives) and received the following message on boot up…
I tried pressing Enter or F8 and it fails with this same message…
I tried re-doing my image on one of the lab computers with the SSD drive and that failed with the same message. I can push this just fine via Unicast but it will not Multicast.
Any suggestions here?
Let me know which log files to upload and I will gladly post them. Thanks!
-
I remoted into Joe’s system and looked about for a bit.
What I found was there was/is 3 versions of php and php-fpm installed and all were trying to run at the same time.
I stopped, php-fpm v5, php-fpm v7.0, and left php-fpm 7.2 running.
I could not find a handy copy of the official fog configuration for the www.conf file so I hand edited the distro’s version setting max processes to 50, start, min to 5 and spares to 6. I also set php max memory size to 256M.
After that I asked Joe to multicast deploy an image. He reported that he deployed to 24 systems. I watched the process status screen and the number of active php-fpm processes never went above 6 workers (where 50 is the max). Joe stated that all 24 machines deployed to completion.
So at this point I’m pretty sure the issue with this system was having multiple versions of php installed as the root cause. I’m not ready to rule out a www.conf file setting that is not right, but I’m happy with what I saw from the performance of php-fpm service in this multicast deployment.
-
That error code appears to be caused by a problem with the MBR…
This image was sysprepped.
Thanks!
-
@george1421 Any ideas here?
Thanks!!
-
Yeah, your windows install is botched.
-
Ok so what do we know?
- You have a single win10 image you created in audit mode
- You can deploy this to HDD drives OK
- You can deploy this image to SSD drives and it fails
- Unicast imaging works to SSD drives??
- Multicast imaging fails to SSD drives?
The point I’m trying to get to is a truth table. Understanding what works and what fails. I can’t seem to pick out the facts from what you have posted.
I can say I don’t have any experience with setting systems up in audit mode. I use MDT to create my golden images so I don’t have to deal with audit mode or rearming anything.
Of course you disable bitlocker before you captured, right?
-
I do have a single WIN10 image created in Audit Mode and re-armed prior to pulling an image.
I can deploy this image to HDD drives OK with Multicast.
I cannot deploy this image to SSD drives with Multicast.
I can deploy this image to SSD drives with Unicast.I have since tried to create a new image specific to the SSD drive machines. This has also blue screened during Multicast only.
Please forgive me as Windows 10 is a new environment for me. I primarily have worked in Win 7 and Unix/Linux. I am not familiar with Bitlocker but I can say nothing is encrypted on our drives.
I am also unfamiliar with MDT. After Googling that I see what it is. Is that easier to use than fooling with Sysprep? Does it provide the same thing?
Thanks!
-
@joe-gill said in WIN10 Multicast Imaging Issues:
I am also unfamiliar with MDT. After Googling that I see what it is. Is that easier to use than fooling with Sysprep? Does it provide the same thing?
You still use sysprep, but MDT allows you to create a win10 deployable image right form DVD image to ready for cloning. It is one of the only ways to get a repeatable golden image. But it does take time to setup to go completely light-touch method (i.e. you start imaging, walk away, and then come back some time later and the image is baked, ready for cloning).
So you are imaging to ssd drives, are these sata ssd, nvme or somthing else? Are the ssd and hdd in the same model of computer? Do you have the required drivers installed in the image for the ssd drive computers? Do the ssd drive computers have sufficient space to hold the image? There are many things to go wrong here, not necessarily related to FOG
-
@george1421
Thanks for explaining MDT. I will have to look into it. I’d love to only have one golden image for everything.So I think I figured one of my issues out… The SATA Operation in BIOS/UEFI was set to AHCI on some and ATA on others (two separate labs). The ATA image will not work on the AHCI image. That makes since now.
To answer your questions - The model computers are identical. They are SATA SSD’s. The drivers are correctly installed on the master image.
Now, I have since taken an image on the AHCI clone and it still does not multitask to the problem lab.
-
@george1421
I am re-running my AHCI image on some of the problem machines to verify that it does indeed fail on multicast. It should be done in about 10 minutes or so. I’ll post back when I find anything. -
@george1421
Well I’m taking off for the weekend. This can wait until next week. The results from re-imaging was not successful. It still fails via multicast but does succeed via unicast.I’ll touch base with FOG on Monday.
Thanks!
-
@george1421
I wanted to report in on my findings… I tested things again and I can indeed push images via Unicast with my current image. I am currently pushing a lab of computers now. Unfortunately this isn’t very efficient.So I have set up a Windows Server 2016 with MDT and ADK installed on it. I am in the process of creating a golden image with that… I’m hoping by mid-week I will have a new image to use.
Let me know if you’d like to see any log files or if you want to remote in.
Thanks!
-
@joe-gill So just multicasting is not working as you need it? (sorry too many threads).
-
That is correct.
-
@joe-gill OK between imaging I want you to test something for me.
Lets disable php-fpm (you’re on FOG 1.5.4 right?) If so, lets check to see if its php-fpm causing the problem.
From the /etc directory search for the php-fpm handler with
grep -R -e ":9000
That should locate the correct configuration file. It should be in /etc/httpd or /etc/apache2 depending on your configuration. I suspectLook for lines that look like this
#SetHandler application/x-httpd-php SetHandler "proxy:fcgi://127.0.0.1:9000"Change the location of the hash tag to this
SetHandler application/x-httpd-php #SetHandler "proxy:fcgi://127.0.0.1:9000"Save and exit your editor.
Now restart apache to reload the updated configuration
systemctl restart httpdfor RHEL based systems
systemctl restart apache2for Debian based systemsI’m also suggesting that you create the info.php page as described here so we can test to see when php-fpm is running with apache: https://forums.fogproject.org/topic/12030/fog-using-a-huge-amount-of-memory-and-failing/11
-
-
@joe-gill Well then its pretty clear that php-fpm isn’t causing the multicasting issue. (nuts). Nothing of any value shows up in the multicasting logs when things go sideways?
-
@george1421
I can post any logs, if you’d like. Multicast does complete. The image just does not function. I was out sick the last couple days. I’m back at it today. I’m hoping to get my new image done here this week. We’ll see. -
The multicast logs look normal.
-
@joe-gill So is imaging working correctly now with apache-php? If so I want to break it to find out what is going sideways.
-
@george1421
Multicast fails on both Apache-PHP and FPM.
