@Sebastian-Roth Thanks Sabastian.

@typotony That’s Great to hear!
Glad you got it working and that it was as easy as intended.

Is your AD configured as SSL only connections? This could be part of the problem but I’m just grabbing at straws with this thought.

@george1421 I tried entering a hostname after the prefix was appended, for example I entered “TestVM” thinking the full registered hostname would be “NCIT-TestVM”, but the device was registered as “TestVM”.

@george1421 Thanks Guyz !!

@plegrand Correct

@george
the “Programs” folder is not part of winPE, it stays back on the CDrom iso on the Y: drive. If you boot the ISO thru a console - you get to keep the Y: drive. If you boot the ISO thru PXE, control is turned over to Hiren winPE process and you lose access to the Y: drive.
To make the Y: drive available from a PXE boot: I edit Hiren’s boot process inside the boot.wim file and map the Y: drive to a network share after winpe initialize but before Hiren process initializes. You must copy folder ‘Program’,‘CustomDrivers’, and HBCD_PE.ini to the network share.

@rizingknight72 You ahve to create an image definition and assign it to the host.

Zero touch just means that the image you’re using doesn’t require the machine to be touched after imaging.

Please review the FOG Documents as this is one of the first things discussed when dealing with FOG.

@brent I don’t recommend this solution.

But I did test something similar many years ago: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog

There is also this method: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Another choice is to create an iscsi target and connect the fog server to that iscsi target to the /images directory on the fog server.

But FOG Project only supports using a linux computer with the FOG Storage node configured loaded as valid.

@jmeyer said in How to Use FOG to PXE Boot MultiBoot 2k10 Unofficial:

chain memdisk iso raw

Just adding a bit of a caveat here.

memdisk is a BIOS boot loader only. There is currently not an equivalent function for UEFI based systems.

The iso image you boot from must be less than 2GB in size (remember 32bit address space) AND the booting computer must have at least 2 times the memory of the 2GB iso to function. So in the case of a 2GB ISO image, your computer needs to have 4GB of RAM.

@MasterOfUs Now that I have had a good sleep I figured that proposing to use SSH is just raising the hurdle once more but not solving the concern. Why? Because some kind of secret (probably SSH key) needs to be included in the FOS inits to authenticate when connecting. Even if this is done properly (random generated key pair) we can not prevent an attacker from loading the FOS init manually and extracting the secret, right?

So making it secure would mean the user needs to enter a connect passphrase manually on each deploy/capture.

@TraverseTheFOG First I suggest you check the free disk space on your FOG server. Connect via SSH and run: df -h

Copy the full output here or take a screenshot and post that here in the forums.

@rodluz Para MAC

@thedark5776 I can read your post in 2 ways. I answered previously in the most common way you ask. If I did not answer your question correctly then clarify if your original disk contains 2 partitions (like C and D) but you only want to deploy the C partition to the target computer).

@thedark5776 Licensing is out of scope in regards to FOG. But you will need to have 1 license for every target computer you deploy an image to. This is not a FOG requirement (because its open source) but your operating system you send to the target computer.

You did not mention the operating system you deploy to the target computer, but if you use MS Windows then you will need an enterprise activation license. The windows OEM license does not support imaging cloning. This is a microsoft EULA issue.

@sebastian-roth Perfect.
I’ll look at getting a test version up and running and see how it goes.
My work has made internet more clunky to get proxies working so I’ll have to test that as well.

@sebastian-roth I figured out how to simplify it using patch yesterday. I will look into the link that you posted.

As you said, probably not something to be merged into the official FOS kernel. I’m guessing that I would not be the only one using FOG that would find this helpful so (unless there is a better way) I’m going to fork the FOS repo and make my changes there. Like I said before, I will write up what I did and try to streamline it as much as possible for anyone to reproduce.

fwiw, there is a script that updates FOG’s IP.
https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

this will re-write your DHCP config on your fog server too. Should be perfect for this use case.