@wayne-workma Thank you very much for your help, your first question helped me. I never moved the client machine over to the switch, I just ran the FOG Server alone on the switch, once I moved to client over to the switch, the FOG Management was to run and work properly.

If anyone else needs this:

I cheated but it worked for my needs
My personal notes =

Imagelog cleanup
Downloaded MySQL Workbench to complete tasks

See records to be deleted.
SELECT * FROM fog.imagingLog where ilImageName NOT LIKE ‘%<latest image name>%’;

Delete Records (Rerun command until effected rows =0) - due to safety feature in Workbench
DELETE FROM fog.imagingLog where ilImageName NOT LIKE ‘<latest image name>’ LIMIT 1000;

@george1421
Hi George,
I advanced on the problem and i am very confused…
I identify problem is just after post download scripts.
I say that because in my multiple tests if i shutdown computer just after sed, cancel fog tasks and boot on Windows 10 1803 the name is correct !

See screenshot of step where i ientify problem occurs :
In tests where windows computer name is correct i shutdown computer just before this screen.

text alternatif

As i saw rubric “Changing hostname” i search in my web FOG Settings :
-FOG Client - Hostname Changer was enabled : Now DISABLED
-General Settings / Change Hostname early was enabled : Now DISABLED

After disable this two settings it’s ok …
2 months to identify this !
Problem solved.

Very thanks for your helps and guidance to post download scripts.
I was convinced that it was coming from Windows/Sysprep.

Don’t know why that did not bother Windows 10 1709.

Thanks again 🙂

Thanks Tom

@george1421 ok thanks for the information

@tom-elliott
Thanks Tom

There are a couple of issues that have come up since 1.5.4 has been released that have been fixed in 1.5.5 (still unreleased at this time).

Roll your FOS kernel back to 4.15.2 to get past the mbr/gpt issue. Make sure you download both the 32 and 64 bit PC kernels (not ARM). Edit the www.conf file to update/include these settings, then reboot your FOG server. pm.max_children = 35 pm.max_requests = 2000 php_admin_value[memory_limit] = 256

If you are having issues with multicasting then we will need to have you switch to the 1.5.5 working branch to get that update.

@junkhacker That’s probably the best path to follow actually. There’s no rush for us to purchase everything at once. Worst case we have enough nodes now to get us by if we do need more. Thanks again for the help!

@dholland said in "Copy" image to repository:

I have my fog server at one site, and a fog repository at the other site.

Lets makes sure our terms are the same.

You have a FOG Server at your HQ and a FOG Storage node at the remote location? If this is the case if both the FOG Server (master node) and the Storage node are in the same storage group then replication happens automatically.

In addition at your remote location you will configure the dhcp scope to pxe boot from the IP address of your FOG Storage node.

The last bit of magic you need is to install the Location plugin. Then allocate each server to a plugin location. Finally when you register target computers you will need to assign that target computer to a Location. That way the target computer knows where to pull its image from.

During the pxe boot process the target system will need to make a http lookup call to your FOG Server at HQ but all file transfer will happen with the local storage node.

@george1421 @Wayne-Workman
thanks guys, originally the idea was more so that i could have a stable image with an IP for the fog server that could interface with a machine deployed now, to a server used in the future. But yes, ultimately I’m trying for a seperate box/vm to run fog for those reasons at each site. I’m just coming into a situation though and there is already excessive amounts of dedicated boxes that run pseudo important tasks, but maybe consolidating those will give me some hardware to run fog on anyways. more of a project is all.

thanks though!

@vascomorais Seems like your question has mostly been answered, but I wanted to pipe in on your comment ‘I can ask the forum’. YES! These forums are amazing. There are numerous people(Including senior developers) that will respond quickly and intelligently and assist you with problems you have with the system. I can’t say enough good about this community.

Hope FOG works for you, it’s been a lifesaver for me and my organization!

Philip

@jpaul As a test place a dumb (unmanaged) switch between one of the troubled target computers and the building switch and try it again.

If this works, then you need to get with your networking admins to check the network switches to ensure that (if) spanning tree is enabled, you are using one of the fast stp protocols (RSTP, MSTP, fast-STP, or what ever your switch port manufacturer calls it).

@skydraw35 said in Host Registration:

I put the background and it work in Legacy/Bios for me !
I have a last question, when i up/receive my image, can i put the uefi ?

Not sure I follow you here. From the sounds of it registration works for you when BIOS/Legacy booted?

Are you asking if you register it via BIOS can you then deploy/capture images in UEFI mode?

I would think so, as long as you set the host machine to boot UEFI and the iPXE menu loads up. I dont think the registration of the machine is tied to BIOS/UEFI mode at all. Images and PXE booting are however, so you couldnt for example (at least not easily) capture a UEFI image and then deploy on a machine BIOS booted for example.

With the change you made to DHCP, you should test and see if UEFI now works too for registration.

Disable Bitlocker was no alternative. That’s the result of my tests today.

At first I tried to only unlock the bitlocked drive, but this will not withstand a reboot. So my unlocked image gets locked again when I reboot.

When I disable BL that means I have to remove the BL encryption, so that the dd in funcs.sh ( dd if=$part bs=512 count=1 2>&1 | grep -i ‘-FVE-FS-’ ) is not able to find the BL-signature.
But that would mean I have to deploy truly clean images and encrypt EVERY deployed image afterwards. This is a no-go. It costs time in encryption and (even worse) it creates one dedicated key for every new deployed computer.
We need to use one remotely stored key for all deployed computers. That makes best sense in our use-case an I cannot change that decission. TPM will not work for us and would no make sense either as we need to have that mentioned key. Windows update will not hesitate us here … its an embedded W7 for dedicated systems.

Finally I patched funcs.sh (uncommented that bitlocker check) and made a new init.xz of it.

So my remaining question here:

How I have to use the setupcomplete.cmd correctly in terms of:

receive the new hostname . Here my first attempt was to wait some time as I observed that snappins take about some minutes until they get delivered … Will that naming take same time? set a static IP which depends from hostname ( I already have prepared a batch file for that …)

Will that all have to go into setupcomplete.cmd?
How and when will that get executed?

Regards

@quinniedid which is what I guessed. 🙂

From a security standpoint I dont see using NFS for imaging as an issue. As mentioned you can set it to allow only from a specific IP range. That should be enough to prevent issues (if a adversary is already on that subnet you have bigger issues). Especially if you dont have sensitive data in the share and if your FOG server is behind a firewall.

Samba would have the ability to allow only connecting from approved users or groups, the problem with that is passing the credentials to connect.

In Clonezilla I used to capture and deploy via SSH, which I really liked, but havent had any issues with how FOG handles it via NFS.

Your first warning, as it seems you have figured out, is I think kind of a basic way NFS works. Client machines have to be able to see/query the server for the share to use it. The second warning is just an extension of that, whats the point in knowing the share is on the server if you cant mount and use it.

Its a windows-service executable (exe) which I have to call with arg /install to install it.
Normaly I would install this by hand in the mother-image I deploy to all clients. But the development of that service delays, so I have to postpone that installation.
Before the install-call of the executable I have to remove the write-lock of the partition, means I have to call another system-executable in advance. After a successful installation I want to reboot.
The SW is an cmake based development. I have no cmake configs which created a Visual Studio deployment project (msi - even if an msi would be good for doing this … I have my doubts) so I have to create this afterwards in the Visual Studio. That is not a good attempt at all, no other co-worker will accept that sh***. So I am looking for an easy-going way … maybe WiX will get it. I have to read the docs, but if anybody has some better suggestions, please tell me.

@jla This is fixed in FOG 1.5.3. Because 1.5.3 was released days ago, and this post from 30 days ago says it was fixed in working-branch: https://forums.fogproject.org/topic/11875/snapin-upload-limit-of-8mb-is-too-small So my advice to you is update to 1.5.3 and see how it goes.

@wayne-workman Ok cool, I will look into it, Thank you.