@nexx34 said in PXE Booting ESXI 6.7u2:

Is it ever planned to make pxe booting “easier”?

Any suggestions are welcome. 🙂

We work a lot with scripts, we don’t use msi and exe, all our snapins are developed as scripts, usually powershell for windows and bash scripting for linux, we use sometimes php, python, perl… called from bash a so on.

Check the potential of the scripting for the 2 first points.
And as alternative to deploy software you can work with snapins+chocolatey

On the third point, we use fog snapins to start/stop services, deploy clients etc…

Currently we are using a reversed vnc server deployed/configured/started/stopped/removed as an unattended snapin, where we have firewalls, As GUI we use a Guacamole Gateway with a vnc-proxy, on the other side where we have not firewalls we are using Dameware and RDP to remote control. The services can be controlled with scripted snapins but the clients/servers/proxyes… must be provided as external services.

I only want to add, that with a deep knowledge of the targets, and with a good knowledge about scripting, and if you add a custom/complete toolset around FOG, you can get a pretty and usefull system admin/management environment.

@Sebastian-Roth said in MFA or logging for brute force attempts:

ust to clarify, what George meant was not actually AD logging done by FOG but using the LDAP plugin

Yes thank you for clarifying. I WAS talking about AD event driven logging. Since they are concerned about brute force attacks, I assume that there is already in place some kind of reporting against AD password hacking. Then from FOG’s standpoint there is nothing to monitor since everything is hitting AD.

@Sebastian-Roth @george1421 Thank you both. I understand that FOG was not really created for this large of a project, however, I’m interested to see how to handles it and what, if anything, will break along the way. I will keep everyone updated with my experiences and issues so that hopefully somebody else can avoid my mistakes in the future!

With the amount of stores we have, I think it may be better to use each FOG server independently to avoid overloading any single part of the system. This will make managing the project more difficult but in the end I think it will be better suited for this client. Each store has a maximum of 7 computers so that should be much more within the programs capabilities. For our corporate office and some of the larger daughter sites, (upwards of 300 computers per site) I will be performing local upgrades.

If I had more time to play around with a central FOG node I might try to make it work, but with Windows 10 support ending at the close of this year, I need to have all 1200+ computer upgraded by then as to not give our compliance department a stroke.

Again, thank you both for the prompt response and for supporting an opensource program.

@george1421 thanks for the reply!

After following your instructions I noticed that there is no “Installing Patch” text on the new server that is not behaving.
Also, /bin/fog.man.reg exists on both servers.

So I decided to follow the rest of your instructions on the old server that behaves as it should just to see what kind of results I should be getting. The results from following your post on the OLD server were as follows:

After getting to the command prompt I keyed in fog and hit Ctrl+C once i saw “* Running post init scripts … Installing Patch”. However, when I was returned to the command prompt and keyed in set |grep postinitpath nothing was returned and I was returned to the command prompt. I did grep for other words/variables that appear after keying in set by itself, just to make sure everything was functional, and set |grep type returned type=down as expected.

As for the NEW server, “Installing Patch” did not appear at all, just “* Running post init scripts … Done” . I did press Ctrl+C after this to see what set |grep postinitpath would return and it too output nothing and returned me to the command prompt. Keying in set |grep type for testing purposes returned type=down.

I also executed the fog command multiple times so that i could stopping the procedure at different debug steps to check set |grep postinitpath on both the OLD and NEW server and it never returned the location of the fog.man.reg.cust file.

Please let me know what you think.

@george1421 Worked flawlessly! Thank you and @Sebastian-Roth so much for the help!

@george1421 you are a wizard.

thats fixed!

now onto my next thing. heres to hoping that once i can grab a HDD big enough for my images that can support these ginormously underused HDD’s in these labs…that all is good 🙂

Yes you can.

Duplicate post: https://forums.fogproject.org/topic/13510/has-any-one-installed-fog-on-a-raspberry-pi

@Sebastian-Roth sorry it took so long, but I finally was able to create a separate thread in bug reports. https://forums.fogproject.org/topic/13486/fog-1-5-6-pushbullet-plugin-not-functioning

We are in the midst of reassembling classroom tech after the custodians did their cleaning so that is what caused the delay.

@Sebastian-Roth will do.
Thank you

@lucycle We’ll follow this one here for now: https://forums.fogproject.org/topic/13125/fog-postinit-not-executing-fog-reg-man-fix

@Quazz
You had the same. https://forums.fogproject.org/topic/7324/small-text-display-bug-image-capture
I should have seach before asking…

VirtualBox_vm1_28_06_2019_15_34_37.png

@george1421 Can confirm, had to switch to ProxyDHCP after the ISP upgraded the modem that has a buggy DHCP implementation (turning off DHCP makes it not give out IPs but the DHCP server is still running so it just NACKs all the IPs lol)

@mikmatcr OK since I still have the development system setup I just spun up a Gen2 vm client. MDT is currently building the golden image. I did see that they changed the disk controller to SCSI. It will take about 1hr for MDT to finish the build. I’ll get some bench mark numbers after that.

@geardog said in Resize failure?:

A cold boot with fast-start disabled allowed a good capture.

Just for another option:

Let sysprep power off the computer after its run Run the following command from a command prompt shutdown -s -t 0

Both of those commands will ensure that the system is properly powered off and ready for image capture.

@krejci You are going to have a difficult time finding a server that meets your requirements, especially with a 31cm depth. Maybe a 37cm depth, but 31 will be really difficult unless you have a custom system. One issue is that 31cm is close to the ATX style motherboard in size. Also to get >10TiB drives you need 3.5" drives since 2.5" drives are not at the 10TiB capacity yet.

I did find this chassis with a 40cm depth, but it is a build your own server. Its not an already complete server, just the chassis: https://www.newegg.com/p/N82E16811219052

In theory you should be able to get FOG running on a synology nas since the nas OS (DSM) is based on linux. I have not tried to do this, but DSM has most of the components needed. You may need to add additional RAM to the rackstation to support both DSM and FOG. Again, I can’t say for 100% sure it will work, only it should work with some hard work. I can say I have turned a synology nas into a FOG Storage Node (not the main server) before, and it works. I have a tutorial here: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@Fernando-Gietz
Well, you may not intend to support such at the moment, but it does work in 1.5.6 provided the groups are specified in the web interface as a comma separated list, which may cause its own problems for some group names. It actually doesn’t look like much more needs to be done to flesh out that first enhancement beyond the UI elements and input validation. 🙂

I would suggest taking a look at the sequence of events for the bindings and searches, or at least making sure that the permissions contexts in which those searches occur are consistent. I think the quick and dirty fix I put in at line 547 won’t mess up anything, but I don’t have a lot of experience with either php and ldap.

And for posterity (read: when I forget what I did), diff against ldap.class.php released with 1.5.6 for the changes to address the issues for this thread:

547a548 > $bind = @$this->bind($bindDN, $bindPass); 616,617c617,618 < '(&(|(name=%s))(%s=%s))', < implode(')(name=', (array)$adminGroups), --- > '(&(|(cn=%s))(%s=%s))', > implode(')(cn=', (array)$adminGroups), 640,641c641,642 < '(&(|(name=%s))(%s=%s))', < implode(')(name=', (array)$userGroups), --- > '(&(|(cn=%s))(%s=%s))', > implode(')(cn=', (array)$userGroups),

Well this will get a little complicated to explain, but lets try.

Traditional pxe booting requires dhcp options 66 and 67 to be set with the proper information namely the next-server and boot-file settings. In a normal environment that is all that is needed to pxe boot a device.

Now enter a network function called ProxyDHCP. A proxy dhcp server can be configured to override what is set in dhcp options 66 and 67. FOG can use a ProxyDHCP server in cases where the main dhcp server can’t be modified such as in a managed service. For the FOG/linux world you would install DNSMASQ which can be configured as a proxy dhcp server. ProxyDHCP servers work over broadcast messages. So if you have a ProxyDHCP server on one subnet it will not hear or respond to pxe boot requests on a different subnet unless you have the ProxyDHCP server configured in the dhcp-helper/dhcp-relay service on your subnet router.

SCCM / WDS has a built in ProxyDHCP server. So that is why your dhcp options are being over written with the SCCM boot loader. If you want to block / stop this there is a netboot service on your SCCM server that you need to stop.

If you want proof this is happening you can use wireshark on a computer on the same subnet as the pxe booting computer that connects to sccm instead of fog. If you use the capture string of port 67 or port 68 or port 4011 then capture the pxe booting process.

When you look in wireshark you will see

Discover sent by the client. (2) Offers one from your dhcp server and one from sccm Request from the client ACK from the dhcp server You probably won’t see this unless you run wireshark on your sccm server, but he client will talk to the proxydhcp server over udp port 4011 to get the pxe boot information.

@Sebastian-Roth said in Connecting FOG to Virtual Machine:

What host OS do you have VirtualBox installed on?

Windows 10

@Quazz said in Connecting FOG to Virtual Machine:

the PIIX3 one works fine though.

I changed my chipset to PIIX3 and it works! Thank you guys for the long headache relief!

@Sebastian-Roth

It looks like these files fixed the issue. 🙂