@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. 🙂

@cmurray139 Just to add a bit more information. default.ipxe -> http://x.x.x.x/fog/service/ipxe/boot.php

But I guess you will run into another issue as the FOS Linux system is another environment that you’d need to use the fake MAC address…

Nevertheless it’s an interesting idea. Please give it a try and see how far you get. Let us know what you find out and if we can help you with anything.

@Quazz Thanks for the help. I really appreciate.

Thank you all for your responses. Thye have been very useful.
I’ve been able to do it using a real machine. It was indeed a Virtualbox problem.

The only time you will impact current systems in production is if your current environment relies on dhcp next-server (option 66) or boot-file (option 67) or uses ProxyDHCP (udp port 4011) to communicate configuration files to your booting devices (such as a voip phone needing to find the pbx system to get its configuration file). If a booting device never attempts to get booting information from dhcp then there is no impact.

Having FOG and either Microsoft’s WDS or SCCM on the same network will cause conflicts.

@george1421 I forgot to mention that in my notes. I will fix that. Changing fetch=tftp://${fog-ip}/gparted/filesystem.squashfs to fetch=tftp://<fog_server_ip>/gparted/filesystem.squashfs worked just fine and booted properly.

@LindsayS said in AD Join:

it would auto-encrypt the password

Have you used the old legacy client before? With the new fog-client we don’t do the password encryption anymore.

@Miodog Please let us know if we can improve the Multicast address thing within FOG even more. We are open for any kind of suggestion on this.

@Alois Please try the following commands:

sudo su - apt-get install php7.2-mysql phpenmod mysqli systemctl restart apache2 systemctl restart php7.2-fpm

@JB2019 please paste the contents of your install log. it should be located, from the base directory of the install files, in /bin/error_logs/foginstall.log

Another solution is to have a fog snapin schedule a PDQ Deploy package or packages. That snapin would run at the end of the deployment process to trigger PDQ Deploy to push out what ever is in the package group. You would also setup PDQ Deploy for on demand application pushes. This method will require the paid for version of PDQ Deploy but the paid for version is well worth the price because of the additional features you get over the free version.

@processor said:

Hi Sebastien, I just did the test again and put the new ini files create the FTP error and put back the original 1.5.5 ini file correct it.

So are you saying that using the 1.5.6 inits is causing the FTP issue but using the 1.5.5 inits you don’t get the FTP error but the UUID issue?!??!

Well we changed the FTP username from fog to fogproject from 1.5.5 to 1.5.6 but that is not hardcoded in the inits and shouldn’t cause this issue I think. You might still try updating to 1.5.6 to see if that fixes the problem.

@Sebastian-Roth Thank you very much. It worked. Now everything is ok.

@Pi0tR Nice find! It’s interesting it states “Invalid TCP packet for current connection state” as this is the first packet (only SYN flag) of a TCP three way handshake and therefore surely the connection does not exist yet.