@george1421 You weren’t kidding about the 10 minutes, that was easy! There was another article on DNSMASQ that I had looked at before putting up this post, which looked mega complicated. Likely it was intended to do more than just PXE stuff. I haven’t deployed anything, but I registered a computer successfully after booting to PXE, so now I just have to migrate from laptop to server. w00t!

@Sebastian-Roth I followed your instructions, and after restarting the service, the FOG log says:

Checking Product Key Activation: #1234567890123456789012345#

No extra spaces anywhere, and also no dashes. (Obviously the 123…345 above is just 25 characters of filler.) For reference, when I performed machine inventory at the first PXE boot, I assigned the Product Key, but did not type in dashes. When viewing the key in the GUI, it has dashes, though they disappear if I click in the field. If I try typing dashes, they appear and disappear.

Perhaps the best/easiest way to manage this is to allow the user to input with or without dashes, and then store the key stripped of dashes, so that when it’s run against the length checker, it matches 25. Let me know what you think, and if you have any additional tests you’d like me to perform.

@Sebastian-Roth Finally got a chance this morning to try the modified DLL, and it worked to activate the computer.

Thanks for the insight! I copied one of my build images to a test-copy, then made two changes. I then ran sysprep /generalize /reboot /unattend and allowed the VM to sysprep and reboot to see what happens. I didn’t capture it to run it through FOG, but I imagine the results will be mirrored once I do.

1. I noticed that your unattend file didn’t contain a reference to SetupComplete. Therefore, I edited unattend.xml to remove the <Component> block that contained <AutoLogon> and <LogonCommands> (within which was contained the reference to SetupComplete.cmd).

2. I moved unattend.xml to the Panther directory at your suggestion. When I ran sysprep, I tested it without defining a file, and sure enough, it picked it up with no problem.

After allowing sysprep to do its job, I logged in as the local admin (since I didn’t have FOG to join the domain for me), and no command windows popped up to try running SetupComplete as the local user. SetupComplete didn’t appear in the Startup tab of Task Manager. FOGService was set to Automatic and was Running. In other words, the things that weren’t supposed to be happening no longer were, and the things that were supposed to happen WERE!

By the way, slightly on the topic, I know the wiki suggests restarting the computer with a command in SetupComplete after enabling the FOG Client, but Microsoft’s documentation suggests this is a bad idea:

Warning You cannot reboot the system and resume running SetupComplete.cmd. You should not reboot the system by adding a command such as shutdown -r. This will put the system in a bad state.

My SetupComplete file contains two lines:

sc config FOGService start= auto
net start FOGService

It seems to still restart if needed, so maybe the shutdown line can be removed?

Thanks to @fry_p, @george1421, and @Sebastian-Roth for your contributions in helping me figure out this strange issue!

Sorry for the generic title. Didn’t know the best way to succinctly describe the issue. I’m on FOG Server version 1.5.7, and have been using it for a while now. For a lot of that time, it’s been working really well! (Been a minute since I’ve been in the forums, eh?)

Last couple weeks, maybe Corona is affecting FOG too … I have two primary images, and the company has two domains. I am using the persistentgroups plugin so that when I add a computer to group1 or group2, it automatically assigns the appropriate image + AD details. Group1 has always worked really well, and I build most computers using it. I have had the quick registration set to add computers to group1 and deploy.

This week, I had several computers I needed to deploy from group2, so I set it in quick registration, but once the computers are registered I see tasks to deploy images and join AD based on group1 instead. Also, if I cancel the task, correct the group on the website, and initiate a new deploy task, it will work properly.

Something else, which I’m not sure if it’s FOG related or not: within the last two weeks, computers deployed under group2 are getting domain trust issues (The trust relationship between this workstation and the primary domain failed). Generally that means the computer isn’t listed in AD, though at least once I saw that it was. I’m going to do some more testing around that to see what the situation is.

One final note regarding that group plugin mentioned above: I notice that when assigning an existing computer to a new group, it seems to wipe out Product Key information. The Product Key field is blank in the groups, so is the plugin set to overwrite every field, or only fields that aren’t empty? If it’s every field, how difficult would it be to modify the plugin so that empty fields in the group don’t overwrite fields on the host?

So following the link in list item #1, I ran into some issues. I created the fog.patch.man.reg file as directed, copying the quoted text into the file and chmod’ing it to 755. Your step 4 mentions editing fog.postinit, which is a file I don’t have. I wondered if you were missing a step that indicated to run the patch script, so I ran it with # ./fog.patch.man.reg and got the following output:

./fog.patch.man.reg: line 12: /usr/share/fog/lib/funcs.sh: No such file or directory
Testing path for our fixed file at fog.reg.man.fix
./fog.patch.man.reg: line 15: debugPause: command not found
Failed to find file [fog.reg.man.fix] sorry. Copy Failed
./fog.patch.man.reg: line 26: debugPause: command not found

I am thinking that my issue is possibly advice in this forum thread, which suggests that it’s safe to delete the contents of /images/dev/. The thread is from 2016, so perhaps dev gained more purpose than a temporary dumping ground for in-progress captures? I arrived at that thread some time ago, for the same reason as the OP - I was running out of disk space and found out it was because of occasionally-failing captures. Deleted the contents of the folder and everything was good again.

Following the link to list item #2, “Using scripts” was a non-starter. I have /opt/fog, but don’t have utils within that directory. Instead, I have log, service, and snapins. I ran find -iname *image* and didn’t find FOGMountBootImage.sh in the results.

I followed the instructions in the “By Hand” section for Version 1.0.0 and up. I had trouble running mount -o loop init{,_32} initmountdir as CentOS didn’t like that command, so I made the assumption that it was trying to mount two directories within initmountdir (init & init_32). I ran that command as such:

mount -o loop init initmountdir/init
mount -o loop init_32 initmountdir/init_32

I then navigated to initmountdir/init{,_32}/bin and changed each fog.man.reg to the file I had created. It sort of worked after I packed everything up, in that things did change, but the registration didn’t act as expected. I entered a hostname as requested, left image ID blank and hit Enter, then it went to a blank line. I waited, but eventually hit Enter again, which then asked if I wanted to associate with groups. After that, when I hit Enter, it dropped to a new blank line, but didn’t continue the form. I possibly have a malformed file (I had a few errors along the way, fixed based on my knowledge of what was wrong). If you’d like, I can attach it. Any thoughts on some of the other issues above?

Also, I was wondering, how would I create a new menu entry, so that my tests show up as a separate item from the primary full registration?

I was reading up at this forum post and the wiki article it linked. I put together a fog.man.reg file using this link provided by @george1421, but I got confused from there. I know the forum post and linked comments mention that the wiki is outdated in some areas, and I think it was suggesting I wouldn’t have to do some of the extra steps that were previously required.

It suggests putting the file into /bin, but there isn’t already an existing file there - is that normal? The wiki also mentions the /tftboot/fog/ directory (and sub-directories) a few times, which I don’t have this one on my FOG server. Should I create it, or am I misunderstanding something?

I seem to remember reading that I have to add the custom entry to the list of the PXE items, but I can’t seem to find how to do that, which I think is the last step I’m missing.

Hey George,

No worries on the delays. Work’s been busy for me too, but today is slow finally.

I realize I messed up how I explained things. I was creating a template host with the same exact name as the group. After not being able to get it working, I tried your example name of TemplHost01 for both a new group and new host. I set the details on the host, added it to the group, and still nothing.

So I just tried again today, and the functionality is working as expected. Curious … I wonder it just needed a little more time. I’ll play with it a bit more and see if everything seems to be good.

Yeah, it definitely seems to be working better now, including with groups/host-templates that I name. I’m not sure what was happening the other day.

One thing which seems like a bug: if I’m in a group and I navigate to Membership to then search for and add additional hosts, it only adds one at a time even if I click the checkbox for multiple.

EDIT: I think I might have figured it out. I’ll get back to this post later, but it seems I glossed over George’s first sentence (which wasn’t quoted in the quote below), which mentioned a plugin to give exactly the usage I need. Once I understood what I was reading, I found his post titled Basic Persistent groups and I will try to follow his instructions to get this working. I’ll let you all know how it goes.

EDIT 2: So I activated the persistent groups plugin, created a host called LOBmulticast, set its image association and AD details, then created a group with the same name of LOBmulticast. The group doesn’t have any of the host’s settings still. Setting them in the host and saving it doesn’t work either. Am I supposed to follow a specific pattern with the name or whatnot?

- - - - -

I’m not sure if I have had the wrong idea about the purpose and use of groups, but I’ve tried using them a couple times with varying levels of success. For example, my company has two different images (and AD domains) used for two separate lines of business.

I tried creating groups named LOB1group and LOB2group, setting image association and Active Directory info, then when registering new hosts associating them with one group or another and skipping questions about image name and whether or not I want to join the domain, but it ends up leaving those bits blank.

Today, I came across a post @george1421 made in Custom Full Host Registration Menu in which he said:

You create a template host and link it with a group. Then when you add a new host to that group, the template host settings get copied to the new host.

This morning, I created 4 new hosts, each with random MAC addresses. “LOB1template” and “test[1-4].” In LOB1template, I set its image association and AD details and then joined it to LOB1group. I noticed the group now had the proper image association, but still didn’t have any AD details filled in. I went ahead and filled those in and saved the group. After that, I added test[1-4]. The group lost its AD details and none of the hosts had image association OR AD details populated in their respective pages. Yesterday, however, I was able to add a bunch of hosts to the group, then apply settings to the group, which populated on the hosts. That doesn’t really seem to make sense though - having to set the group details AFTER adding hosts, since then it’s less automated.

Another question about the template host idea; when I go to perform a multicast, wouldn’t it never start, because it would be waiting on LOB1template to join the multicast, which wouldn’t happen since it’s not real?

Thanks. Perhaps those are less errors, and more just warnings? Is LDAP login possible with the current build? If so, I’ll open a new post requesting help with that.

They do occasionally have different or old BIOS versions, which I update after Windows is finished loading. But they all have the same settings.

I was trying to track down what was going wrong with my LDAP setup, when it was recommended here to check the Apache error log. Navigating there, I found line after line comlpaining about “proxy_fcgi:error - The Timeout specified has expired … etc.”

[Wed Aug 07 12:21:02.678201 2019] [proxy_fcgi:error] [pid 26153] (70007)The timeout specified has expired: [client 172.17.207.117:64205] AH01075: Error dispatching request to :, referer: http://172.17.207.144/fog/management/index.php?node=task&sub=active

Research on that lead me here to check the www-error.log. Opening that file, I get several lines complaining about an illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296. It also complains about lines 1080, 1081, and 1100 of file /var/www/html/fog/lib/fog/fogcontroller.class.php (mainly about array_diff() and count()), but that’s where my eyes started glossing over. Thoughts on how I can get the errors to stop flowing, so I can better figure out what I need to do to get LDAP rolling?

[05-Aug-2019 12:57:34 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[05-Aug-2019 12:58:38 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[05-Aug-2019 15:15:31 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:27:18 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:27:58 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:28:36 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:24:35 America/New_York] PHP Fatal error: Uncaught Error: Call to a member function isValid() on null in /var/www/html/fog/lib/fog/host.class.php:305

Stack trace:

#0 /var/www/html/fog/lib/fog/fogbase.class.php(1814): Host->save()

#1 /var/www/html/fog/lib/client/fogclient.class.php(179): FOGBase->sendData(‘{“error”:"{\"co…’)

#2 /var/www/html/fog/service/register.php(32): FOGClient->__construct(true, false, true, false, true)

#3 {main}

thrown in /var/www/html/fog/lib/fog/host.class.php on line 305

[07-Aug-2019 10:55:14 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 11:01:38 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:07:46 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:10:49 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:11:02 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:28:04 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 16:20:10 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:07:58 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:08:04 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:08:11 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[09-Aug-2019 09:34:55 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[09-Aug-2019 16:14:57 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

Of course. The model I’ve primarily seen issues with is the Lenovo Thinkcentre M93p. It does seem to be somewhat inconsistent in terms of one working fine while several others experience the described issue. I just tried on a Thinkpad T450 and it worked just fine, though I had one that experienced the issue before.

I have developed UEFI-based Windows images, so I set the computers either to UEFI-only or UEFI-first. I have been preferring the latter in case there’s any weird things we might want to do with Legacy support, but I’m wondering if that may have some negative effect. Your broaching of this subject has me thinking, and I think the next batch of M93p’s I build, I’ll set them to UEFI-only to see if that has any different reaction.

This issue isn’t a terrible, terrible thing for my workflow, but it does disrupt it to a small degree. The issue could technically be fixed if I change the “Error” boot sequence to put the drive before the network. What happens is i switch away on the KVM, the computer detects that a keyboard isn’t connected, and it boots to the network. Long term, I like the idea of keeping this setting, as it will help with future automation plans.

@Sebastian-Roth It’s been a hot minute, but I finally had some time to test this today. I went through the entire list of Host Exit Types from SANBOOT through EXIT and none of them worked for the desktops. Different options reacted differently (one of them put it into a boot loop), but none of them allowed the computer to proceed to Windows upon allowing the PXE menu to auto-select “Boot from hard drive.”

Any other options or things I can try?