@easp said in Quick Registration makes windows not genuine: I am new to using FOG, and I’ve recently installed 1.4.4. Which tutorial did you follow that made you install FOG 1.4.4? This version is years old and we don’t recommend using older versions. As you get used to work with FOG I highly recommend you upgrade your FOG server to the latest version (1.5.5 as of now) before you got it all perfectly setup…

@Greg-Plamondon My fault, sorry for this. I just pushed a fix to the dev-branch. Please pull the latest changes any try again.

@AndrewC said in Dev branch fails install: Changing or removing completely the password field from .fogsettings does not appear to affect this at all. Just a quick info on that. The installer not only looks for an existing password in .fogsettings but also in .../fog/lib/fog/config.class.php. This has been in the code for some time but had a smaller issue because of the password being defined in the PHP file over multiple lines. Which working on the password stuff I also fixed this. Please let us know if you think we should only ever read an existing password from .fogsettings?!

I appreciate the help. Luckily just trying the non re-sizable option worked 90% of the time. However, the issue with what appears to be a successful capture and deploy, but complete failure to boot after the deploy is still happening. I’m going to keep playing with that but I think the other issue might be unrelated. I think I’ll repost with more details and let this close out. Thanks for the help.

@Fernando-Gietz @george1421 Oh, well now I just feel dumb. That’s on me. Sorry guys. And thank you

@Sebastian-Roth said in Clear Primary User and Other Tag Fields: actually clear those fields for ALL your hosts! If you don’t have a backup, there is no way back after running tho Perfect, exactly what I needed. Thank you!

Hi! Thanks for your recommendations. Finally I’ve solved the issue with ``` reboot=pci Thanks!!

@george1421 Yeah it looks like by adding this to the xml file cscript /B C:\windows\system32_slmgr.vbs /ato resolved it on my machines. Thanks for the help.

@Redbob Great stuff we figured this out so quickly. Hope you can dig up what was actually causing the issue for this particular IP address. Could you check PCAP of 172.24.12.65? It’s here: new PCAP, just to understand it What exactly are we looking for this time? For this client IP I see the TFTP transfer (default.ipxe) and next is a HTTP POST request (/fog/service/ipxe/boot.php) and a HTTP GET request (/fog/service/ipxe/bg.png) which seems fine from my point of view. The only thing I wonder is one last FIN,PSH,ACK in the TCP session but that is quite common as many clients simply drop the connection without closing it nicely.

@Sebastian-Roth said in HP DC7800 network boot: Yes -> https://fogproject.org/binaries1.5.2.zip -> This is why you are one of the FOG Project Digital GODS. @mclapper68 Depending on your deployment volume. You could download and extract the zip file. Save the init.xz as init152.xz and move it to /var/www/html/fog/service/ipxe on the fog server. Then finally update the init field for this host to init152.xz and for the kernel do the same, rename bzImage from the zip to bzImage152 and move to the same location then update the kernel field for this host to bzImage152. (sorry for the disjointed post I was thinking linearly here). That workaround will allow you to continue to use fog as it was deigned for the new kit, and still support his older stuff without fear of an update breaking your older systems.

@Sebastian-Roth Yeah, I just added an edit section to my previous post. This thread popped up with no responses after 19 hours. I didn’t understand how I missed this for 19 hours that’s why my response was a bit random, I was starting at the beginning. Very strange.

Thanks that worked!

@URfog Oh wow, didn’t expect that! Thanks heaps for letting us know! Great that you figured this out.

@Fernando-Gietz Hi. No, I’m only using your plugins, the site one and the accesscontrol. I said, this is not a problem really, because if I add the user again, it is working. Thx again.

@george1421 said in Moving FOG's /images files off the root partition 2017 edition: touch /opt/fog/snapin.chk Tutorial worked like a charm! The is some minor errors as follows: The following line needs bind bind 0 0 added /opt/fog/snapins /opt/fogdisk/snapins bind bind 0 0 and the Snapin test file needs to be in the right directory! touch /opt/fog/snapins/snapin.chk

SOLVED Thanks guys, once the certificates were copied to the fog2 server, AD join started working Yay :)

@Reagan said: Are these commands something I need to run every time I upgrade the FOG server? Well that’s a good question. No, from my point of view, if you don’t recreate the certificates (extra installer parameters - shouldn’t use if you don’t know exactly what you do anyway) or move to use your own custom certificates (from an official or internal certificate authority), there is no need to rerun the build script. By the way, I opened an issue to include the build process to the installer, so this manual run won’t be needed anymore. This will be part of the next official release.

@Sebastian-Roth yes, the esxi host has a NIC on each network. I am attempting to get the network to allow access to an single IP in the management for each lab so I can just use the 066 DHCP option to point to the interface that works for TFTP which I believe is the way the guys that are doing similar setups are making it work.

Super that did work… thanks guys