WIN10 Multicast Imaging Issues
-
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. -
@joe-gill mind installing working branch to see if it helps with mulyicast? I’d also recommend trying the rendezvous option for mulyicast. This can be setup in fog settings. Set the address to the ip of your fog server, then as a failsafe restart the multicast manager service and then the clients.
-
@tom-elliott
Thanks! Will do! I’ll report back. I will try a few labs today and see what happens. -
So… I tasked 5 machines for a test batch. Multicast worked on those 5 just fine. The image seems to be running fine. The task session was extremely fast. They were finished in less than 8 minutes.
I tasked 30 more… and the interface locks up. I cannot get to the interface now at all.
My server is running Debian 9.4. It ran fine using Apache. Now that we are back to FPM, the interface is locking up tight.
Thanks guys! I’ll be around today until noon MST than again tomorrow 7 - 3 MST.
-
I restarted PHP-FPM and the interface came back up.
