@Tom-Elliott I’m pretty sure the global value just always being used would work and just never a static directory.
I had set the global directory originally. I don’t think that I would be able to create or deploy snapins in the gui properly otherwise.

I switched to GRUB_FIRST_FOUND_WINDOWS exit type and it seems to be working now.
However normal EXIT still caused a PXE chainloading failed error.
Is this a bug others are getting or is this a configuration issue?

After updating to just before 6285 the booting to memtest instead of harddisk after the countdown problem has returned.

The issue seems intermittent and not on all devices though.
I tried changing from SANBOOT to EXIT but that made it so chainloading failed on hosts that were working.
Switched it back and still having the issue. Still testing though.

Additionally are these settings supposed to be persistent in the gui after saving? because they’re not…

I’m still troubleshooting as it doesn’t happen on every host. But upgrading to the latest trunk (6285) and rebooting to make sure any and all related services got restarted didn’t do the trick and nor did editing the EXIT method.

My boot.php in the browser of a registered host looks like this

#!ipxe
set fog-ip 192.168.100.117
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.100.117/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.quickimage Quick Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local || goto MENU
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=192.168.100.117/fog/ conosoleblank=0 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=192.168.100.117/fog/ conosoleblank=0 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.quickimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.sysinfo
kernel loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=192.168.100.117/fog/ conosoleblank=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://192.168.100.117/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Thoughts?
Thanks,
-JJ

What if you forget the automation part of my feature request and focus on the persistent part. As I’m utilizing groups more and more I would really like it if I didn’t have to manually select snapins and printers everytime. It is convenient to be able to add the same things but I’d like to have a static template type of thing. Every host in this group needs these snapins type of thing. Maybe I’ll just make it a plugin at some point if I ever get any extra time

@Tom-Elliott That is a good point, well maybe at least we could make it so you don’t have to have a member in the group for settings to save?
While setting up the infrastructure before adding existing computers from active directory, not being able to save the settings for each group before getting hosts in fog is a bit of a hindrance.

@Tom-Elliott said:

Groups are not intended to automate the processes, but rather update hosts in an all inclusive setup.

Well I just want to automate updating hosts in an all inclusive setup. It’s just an idea really. As it is it feels a little clunky. Maybe there’s an intermediate. Like when you add hosts to a group you have a prompt that asks if you want to update them with the group settings and that just runs an update all for each group setting and deploys snapins for the new members?
I’m just lazy…err I mean, driven by efficiency, and don’t want to miss something when putting hosts into a group with all the settings I want for them.

@Wayne-Workman So you wouldn’t want the ability to move a host into a group and then know it is configured as it should be with one click?
I see your point in where it could cause problems, so perhaps it needs an off switch. I just really like automating things.

So I am currently deploying the FOG client through the GPO to add all existing active directory computers to fog. Which is working pretty well. However when I get the pending hosts pop up in the gui, the select all check box doesn’t work. A minor inconvenience really, but a bug none the less.

So currently, and correct me if I’m wrong, when you set up a group, unless you have members in it it doesn’t save any settings. And if you have some hosts in it the settings are saved in the group settings, but you have to hit updated on everything for it apply to hosts in the group. This is already a very powerful tool and an excellent feature, I just think that it could be enhanced a little.
Instead of having to manually update whenever you add a new host to a group, make it so adding a host to a group automatically adds, removes, and or deploys corresponding snapins, printers, active directory settings, and everything else except for the image (which maybe there could be an option or prompt for). Also make it so settings can be saved to a group without any members in it.

This way as you move computers around or as you are making your initial FOG setup, the group functionality automatically automates group membership. It already kind of does this when you image a computer in a group, but I would like to see it happen whenever you add a computer to a group.

Another crazy cool but probably too complicated feature possibility is to make the active directory connection 2 way. So that if a host is added to fog and already in an active directory OU that is linked to an exisiting group, it is automatically added to the corresponding group. But that one might be more work than it’s worth.

I have been working a lot with FOG printer management on Windows 10 x64 hosts on the latest trunk and I have not had this problem at all.

@anthonyglamis said:

2/4/2016 5:23 PM LocalPrinter --> IP = IP_192.168.1.250

Sorry for any repeated information that others said. I saw some posts after I started writing this and didn’t feel like taking out pieces.

The first problem I see is right here.
The printer ip shouldn’t have IP_ in front of it. It should just be the ip address plain and simple
Also the Printer INF File path should be the path to the share that the client uses to access the file. All these fields are passed to the service and run on the computer, so they need to be how the host computer gets to them, not how fog gets to them. i.e. /opt/fog won’t work. \\192.168.1.243\printerdrivers\printer.inf might do the trick

Try testing with an inf file on a local computer with a local path in fog. i.e.

• Put the inf in C:\printer.inf on the client computer
• set the inf file path in fog to C:\printer.inf

That would just see if the service is working for you.
With network shares, I find that it only works with the fog service if it’s already mounted. I.E. A network share mapped through active directory gpo. This is something I hope to improve in the future.

An alternative method is a snapin with a script. Checkout the template script I posted here
https://forums.fogproject.org/topic/6540/adding-custom-printer-configuration

Another way of testing the printer install is to test the actual command that the fog service uses to add a printer. It uses a special function for adding a port, but if you don’t already have the port created you can create it with this command in the command line.
Cscript %WINDIR%\System32\Printing_Admin_Scripts\en-US\Prnport.vbs -a -r portname -h ipAddress -o raw -n 9100
Then test adding the printer with this command in an administrator command prompt. Which is the way that fog adds it. This will help you confirm your settings further. I took out the /q parameter that goes after /if (install printer from file) so that any error messages won’t be supressed when you test
RUNDLL32 printui.dll,PrintUIEntry /if /b "Printer Name" /f "INF File Path" /r "PortName" /m "Model name from inf file"

If that command adds the printer, then your printer settings are all correct as they are, if it fails, then you should get an error message with more explanation.

Some other caveats I’ve found are that you sometimes need more than just the inf next to the inf. I.e. the .cab, .cat. dlls and stuff that it links to sometimes need to be in the same directory. So if you download a driver package and then unzip it, just use the full extracted folder in your share. You can do some testing and see which is actually neccesarry, cause sometimes just the inf is needed, other times (like with the hp universal print driver) you need the whole folder to get it to install proper.

Personally I currently make a printer script with the template I posted in the above referenced forum post and then add that information to fog. I deploy the script as a snapin to install the printer when the fog service fails to add the printer the FOG printer management successfully removes and keeps the printers that are allowed after it’s installed with that script.
It is surely possible to get the FOG printer management to work as it is in most situations. But I find it easier to have a failsafe for when it has trouble accessing a network share or when it doesn’t like the inf file or something like that.

Also one other little caveat. I noticed that the inf in this one is oem… That’s usually the “published” or “installed” inf file once the printer driver is added to windows and gets appended to or its own happy inf file created in C:\Windows\INF
Sometimes that one works fine, but sometimes that one will contain other printer information and confuse a computer that it wasn’t made on. I usually stick with the inf that the driver comes with that you download off the manufactuer’s website. But that’s just my two cents.

@Arrowhead-IT I did just try vmxnet3 again after we had done some dhcp configuration fixes over the weekend. It worked on the first try, I guess my problem was elsewhere. I haven’t tried unsetting the experimental options yet.

@MRCUR I’ve heard that, but I couldn’t get the vmxnet adapter to boot to pxe. E1000 was the only one that worked ever for me. If you’re saying you have gotten it to work, then maybe I should try it again.

If you wanted to try the esxi route
I found this info on unRaid NFS
http://lime-technology.com/wiki/index.php/FAQ#How_do_I_configure_NFS_mounts.3F

Then in vcenter for esxi add a datastore with the network file system option
give esxi the unraid servers nfs address
tell it where to mount it on esxi
and give the datastore a name, like images

Then on your fog vm, shutdown, edit settings, and then add a new virtual disk from that data store.
Then mount that as /images in your /etc/fstab. You might have to format it before you can mount it with mkfs ext4 or something of that sort.

If that overview isn’t helpful and you want to try this method, I’ll test it out a little and document the process more thoroughly when I get a chance.

@Wayne-Workman Well yeah, I don’t want to hold up 1.3, hence the plugin/module idea.

@Wayne-Workman well, it happens on physical machines too. Maybe CentOS is just better than ubuntu for hosting fog?

@Wayne-Workman But that involves waiting for functionality I could use now…

@Sebastian-Roth Yeah, our dhcp does have some serious issues actually. We’re working on narrowing it down. Sometimes computers get ips from the ip phone scope, even when they have an ip reservation. Pretty sure it has to do with some incompatible firmware on one old hp switch we’re phasing out. I was just hoping to have found something that just worked around other issues.

And sadly, after trying to boot a different vm a few minutes ago, same esxi server and same type of virtual network adapter E1000 as the other, it took a few tries again to get an address in the initial pxe boot.

Thanks for the input though, just more confirmation that our network needs an overhaul.
I just want to hit reset of the whole data center infrastructure and start again. But that’s not actually a good idea, I know that, people need to do their jobs or something silly like that.

There are a few different options that oughta work, just off the top of my head, haven’t tested these yet but probably will eventually.

• You can have a seperate linux server set up as a storage node with the fog installer in storage node mode and link to it in the gui with the fog storage management settings.

• It would require a little research, but you could utilize esxi’s datastores and clusters and map a NAS there. And then link it to the vm through esxi mounting it like a local drive. Then choose to mount that drive to /images with /etc/fstab, mount it elsewhere and point to it in the fog settings and /etc/exports, or mount else where and make /images a symlink to the mount point

• There are some other options too, but I think the most important thing to consider is that where-ever you choose to put it, you want it to be an nfs share. I imagine it’s possible to get other types to work, but nfs is what fog uses natively and for good reason. Most NAS’s have some setting in their gui to enable nfs settings.

• Ability to add local printers on nul: port with no ip address (.i.e. Send to OneNote, PDF Printers, etc)
• Ability to add usb printers or at least set them as allowed so FOG doesn’t delete them if they aren’t in the printer list and FOG is set to remove all extra printers