"Pending/additional" mac addresses combining with other hosts
-
We have been using FOG for a bit now, and what find is that with some machines, once we image them they don’t create hosts of their own but combine into existing hosts that already show up on the FOG Web UI. They show up as either “Pending Macs” or “Additional Macs” but either way it makes the machine not able to be found. The only real way to find where they are is by creating a new host and punching in the mac address manually and it will show you what other existing host the mac has been added to.
Is there a way to fix this globally and then prevent it from happening? I am not even sure the cause. If I delete the host with all the pending macs will the real hosts show up in the console? Very confused at the moment.
-
You probably have a feature enabled that essentially creates and associates a random mac address on reboots.
See the article here:
https://it.nmu.edu/docs/disable-random-hardware-address-windows-10 -
I will certainly turn this off in my image, but the mac address that shows up on another machine, is a real mac address of a machine that I just imaged. So let’s say I image a computer named “PC1” using the manual keyboard based method of FOG. Then after I go log into the console, I can’t find it under “pending” or anywhere else. That is because it’s real primary mac address is listed under “PC7” or some other host on the FOG console under “pending macs”.
-
@rogalskij said in "Pending/additional" mac addresses combining with other hosts:
So let’s say I image a computer named “PC1” using the manual keyboard based method of FOG.
I am not sure I understand what you mean by the “manual keyboard based method”?! Please explain.
Do you register the hosts you want to image beforehand or not?
Did you disable early hostname change (FOG Configuration -> FOG Settings -> General Settings -> CHANGE HOSTNAME EARLY). By default it is enabled.
You might want to ignore the rest from here downwards. It’s just me thinking out loud trying to find why this might happen.
The list of pending MACs we see in the picture above stems from the fog-client software reporting these to the FOG server I would think. Do you have the fog-client istalled in your image? Now question is, why does the fog-client think that this particular host is “owning” all these additional MACs?
FOG still uses the MAC address as central key to decide weather a host is registered or not. So when a host is being imaged without registration and it starts up with fog-client installed the FOG server cannot find it’s MAC address to be registered and therefore will create a host object matching the hostname.
If - for some reason - the hostname is still the one from the initial image all the MACs will be added as pending to this particular host.
@Tom-Elliott @george1421 Do we have reports about early hostname change not working in Windows 10?
-
@rogalskij Any news on this? I still cannot replicate the issue as described.
-
Sorry I didn’t respond until now. We are still having the issue. For these machines, the majority we DON’T register beforehand. These are usually imaged by our desktop team at the PC using a manual “netboot” on the machine itself and then imaging it. Then we end up with hosts in the “Pending Hosts” section or in this case they never show up there because they show up under some other previously imaged machine as shown in the image I posted. We rename the PC manually after it get’s imaged in this case.
Currently we have the default setting of “Change hostname early” set, should we disable this?
I do have the FOG client installed in my image as I thought this was the desired behavior to “capture” an image
If we need to rename the PC BEFORE imaging, how would we go about this but still utilize the manual imaging process right at the PC itself? (My desktop team prefers to image this way even when the original image on the machine is functioning correctly).
-
@rogalskij said in "Pending/additional" mac addresses combining with other hosts:
For these machines, the majority we DON’T register beforehand.
Ok, that explains part of what you see. The host is being deployed without an object in the database. It deploys, then early host rename is asked to rename it but skips that part because it does not have the information for unregistered hosts. So you end up with all MACs being registered to that single host that is registered and has the name of your initial master image (not the image name bit the hostname in Windows).
So I am wondering what you process looks like from start to end. Where is the step where you actually give each of the deployed machines their own hostname? Either hosts are registered in the FOG DB and named through this or you need to use other ways like OOBE to do the naming.
-
The process is as follows for a new machine never having been imaged. Desktop support tech sets all the necessary BIOS settings to get it to PXE boot. Then said technician PXE boots the machine, images it without registering it, and waits for it to reboot. After it reboots, the technician logs in locally and renames it while at the same time joining it to our Active Directory Domain.
Then I log into the console sometime later and I notice that yet another mac address has been crammed into a machine in the console.
-
@rogalskij While I can understand that your techs want to get it imaged as fast as possible I would still suggest they take on small hurdle at the beginning and save a lot of time later on.
See if you can tell them to PXE boot and choose “Perform Full Host Registration and Inventory” instead of direct deploy. This will ask for the hostname to be used within FOG (and als set in Windows!) as well as image ID and even set all the information for automatic AD joining. At the end of registration you can tell it to schedule a deploy so it does one reboot and deploys without any further interaction.
If you set things up correctly your techs would take maybe 2-3 minutes for the full registration but after that they can walk away and it does the deploy, rename, join domain (fog-client) without any further action required.
Beside that you won’t have additional MAC flooding that single host…