Ok so this may have been fixed in subsequent versions but on 3783 at least, if you have an image that is too large, it takes too long to distribute out to other nodes and, after 10 minutes, it wipes the “old” version of the image (IE the unfinished and still in progress transfer of the image) and simply restarts the process.
Unless theres a way to change this from settings, this probably isn’t intended 
So, I thought things should be all happy and fine with the new client update, but it appears not. Newly imaged machines end up in a reboot loop; each time they log on, I check the log and I can see the following:
07/07/2015 14:24 Client-Info Version: 0.9.0
07/07/2015 14:24 HostnameChanger Running...
07/07/2015 14:24 Middleware::Communication URL: http://fog.cst.beds.ac.uk/fog/service/servicemodule-active.php?moduleid=hostnamechanger&mac=78:24:AF:39:02:A6|00:50:56:C0:00:01|00:50:56:C0:00:08||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService=1
07/07/2015 14:24 Middleware::Communication Response: Success
07/07/2015 14:24 Middleware::Communication URL: http://fog.cst.beds.ac.uk/fog/service/hostname.php?moduleid=hostnamechanger&mac=78:24:AF:39:02:A6|00:50:56:C0:00:01|00:50:56:C0:00:08||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService=1
07/07/2015 14:24 Middleware::Communication Response: Success
07/07/2015 14:24 HostnameChanger Checking Hostname
07/07/2015 14:24 HostnameChanger Renaming host to CSTC112-2465469
07/07/2015 14:24 HostnameChanger Unregistering computer
07/07/2015 14:24 HostnameChanger Removing host from active directory
07/07/2015 14:24 HostnameChanger Success, code = 0
07/07/2015 14:24 Power Creating shutdown command in 60 seconds
07/07/2015 14:24 Bus {
"channel": "Power",
"data": "{\r\n \"action\": \"request\",\r\n \"period\": 60,\r\n \"options\": 2,\r\n \"command\": \"/r /c \\\"Host joined to active directory, restart needed\\\" /t 30\",\r\n \"message\": \"This computer needs to perform maintance.\"\r\n}"
}
07/07/2015 14:24 Bus Emmiting message on channel: Power
07/07/2015 14:24 HostnameChanger Updating registry
07/07/2015 14:24 RegistryHandler ERROR: Could not set SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerNameComputerName
07/07/2015 14:24 RegistryHandler ERROR: Cannot create a stable subkey under a volatile parent key.
07/07/2015 14:24 Power Power task already in-progress
07/07/2015 14:24 HostnameChanger Registering host with active directory
07/07/2015 14:24 Bus Emmiting message on channel: Power
07/07/2015 14:24 Bus Emmiting message on channel: Power
07/07/2015 14:24 Power Delayed power action by 10 minutes
07/07/2015 14:24 Bus {
"channel": "Notification",
"data": "{\r\n \"title\": \"Shutdown Delayed\",\r\n \"message\": \"Shutdown has been delayed for 10 minutes\",\r\n \"duration\": 10\r\n}"
}
07/07/2015 14:24 Bus Emmiting message on channel: Notification
07/07/2015 14:24 Bus Emmiting message on channel: Notification```
Anyhow - the point is, that the machine name doesn’t actually change. Is that anything to do with ERROR: Could not set SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerNameComputerName ? and why would that happen?
@Wayne-Workman said:
For your environment (using an unmodifiable / limited DHCP), you’d use ProxyDHCP (dnsmasq).
And,
I’ve been working really hard on documentation in the WiKi and ANY help would be greatly appreciated.
Get in touch with me via messaging and we can collaborate together? I also have a To-Do list for the WiKi that I really should share with everyone… But I don’t want just anyone posting on it… Maybe I can just turn my To-Do list into a WiKi page…
I’d love to do a few articles or write some things up but not everyone has access
Just to clarify, if the client is installed and then upgraded (or rather,the installer is) on the server, do (or can) they automatically upgrade to the new version?
Note: all hosts are using the legacy client
As started here, I have noticed two bugs here: the first is that “approving” a pending mac address simply makes it disappear from the list of pending macs (still present as of 3587).
The second is potentially more devastating. I could be wrong in my assumptions here but I think its pretty sound. What seems to happen is, is that MAC addresses are now being associated with a host even if they are only pending.
This is a huge problem if you use virtual adapters. In my situation, virtual mac addresses get generated as part of the VMWare Workstation installation, which ends up being installed on ~500 PCs in our labs (IE 500 pcs will have the same two virtual mac addresses). This hasn’t ever been a problem and previously (1.2 and below), these cloned virtual addresses became “Pending” addresses. Simply ignoring their existence is fine and does nothing.
Now, however, only one host has those mac addresses as “Pending”. But all other hosts who aren’t registered on FOG, or who have a problem initially retreiving their physical mac address (happens with some hardware configurations it seems), will check in thinking that they are that one host (because they have the same virtual address, which is still a mac address, and its associated with a host already. Despite being pending)
If I remove those two virtual macs from being associated with that single host, another host will then associate itself with the virtual addresses next time it checks in to FOG. All the other machines that associated themselves with that single host will rename themselves to that host, which then means they’re unable to logon to the domain here.
For now, I’ve created a single host called “BROKEN” and turned all services off and given it these two virtual macs explicitly. But this is still a bad situation to be in.
The final issue is that the MAC address filter in the settings doesn’t seem to be listened to. Hosts can still exist and be registered and pending macs will still enter the list even if they start with the same string as listed in the FOG registration settings.
So this comes down to three bugs in one:
If anyone has any questions or feedback, or corrections, please post
Cheers guys!
Actually - even if the MACs are pending, they are still used even if unapproved. This is a huge problem with VMWare adapter addresses.
For example: if a host has a pending mac address of 00:50:9c:00:08 and then another host notices it has that same mac address, it will associate itself with that host, adding its own mac address to that host and renaming itself, if hostname changer is enabled.
Last week was spend unbrokening many broken PCs
Are you using an ip or a hostname? Maybe the FOG client isn’t using the right IP?
Ok so I’m on SVN 3563 now and have the pending mac list visible - it seems that even with deleting the host completely, it now exists again. Same problem ensues still - old FOG client seems to be renaming existing PCs that were not actually registered on FOG, but likely all had the same two virtual macs that are pending.
Does anybody at all have any idea or input for this?
What happens if you go to “Services” and then restart the FOG service there?
Also - are you using SSDs :)?
I noticed the same thing. Is there any link or something to describe how pending/multiple macs are now handled?
@Dragnous said:
HP 215 G1
Is it possible to disable IPv6 PXE booting in bios?
I remember on DQ87PG/Viglen 800s boards, we had to change about 150 PCs to booting from UEFI PXE to legacy OPROM. Landesk and FOG both had problems with this - so maybe its a similar kind of thing.
SVN 3540
Newly registered hosts since upgrading have a mismatched inventory format to old hosts.
Similarly, adding a host yourself manually by giving a hostname and a MAC address doesn’t actually add that host to FOG it seems - IE the client still shows as being unregistered.
Screenshot is of a report with hosts pre and post SVN update
Ok interesting; what seems to have happened is that - after upgrading to SVN - hosts that were not registered on FOG are being affected by this.
It seems as though one host has associated itself with the 00:50:56:C0:00 (virtual adapter) addresses used by basically every other PC. I have no idea why this computer in particular has the addresses pending, but before, multiple hosts could have these same pending addresses.
Now, the few hosts that happened to have the FOG client - but were not registered with their own primary MAC address on FOG - seem to have put their own primary MAC address as a pending address in FOG against that single unrelated host. It looks like what could be happening is that they see the virtual adapter addresses and because they also have this on the machine, they are now thinking that they - too- should be called CSTC107-084132.
The upshot is that we have 10 PCs with domain trust issues and are unable to logon at all - where once they were fine. My question now is, is how have pending MAC addresses been changed and will there be any different controls for how people can approve or reject MACs - or perhaps set some sort of exclusions (so that virtual mac addresses don’t get added, for example).
As the title. For the last two days I’ve had some people contact me about AD security trust issues when trying to logon - only on a couple of PCs though.
I’ve just realised today that those PCs have had their names changed to one of the PCs built about 2 weeks ago for general use.
I’m used to seeing two pending macs for VMWare virtual adapters, but I’ve now checked out the FOG page for that hostname and found it has 10 entries!
The weird thing is that about half of them seem to be mac addresses for hardware I haven’t seen used anywhere in our labs, whereas others belong to machines we have around the labs (and it seems from the latest backup 3 days ago that they weren’t a part of our FOG system for whatever reason).
Whatever the reason behind this, has anyone got any idea why this might happen? (FYI: SVN 3533)
I was sure you could target a partition to image to somewhere (like SDB1 or SDA2 or whatever) but I might be wrong
Ah ok! Maybe this is default behaviour now? Tom will probably weigh in soon.
I’ll upgrade to SVN later and see what happens myself.
I take back my post about the last update being over a year ago 