@jacky94 Thank you for sharing!!

Driver injection is always been an issue, especially hardware that is hidden behind other hardware. Some times it take 3 passes to get all of the hardware identified and the drivers loaded.

@astrugatch You’ve probably read through this?! Fairly easy to setup. Though if you really only need UEFI then you can go ipxe.efi “single handed” and you should be all fine.

@sebastian-roth, sure!

alt text

@joe-schmitt said in Service Fog Client:

when client installs, it sets the service to auto on boot, but does not start.

I guess what needs to be turned into a feature request is a msi install command line switch to alter this behavior. This switch would install and set the service to disabled. Or alter the process to require a command line switch to set the service to auto and the default would be disabled. Either way would work. Probably the command line switch to disable the service would cause the least amount of pain for already installed environments.

Most of the time the fog client is being installed before the system is sysprepped, which is causing us the most problems. So if the client installs but doesn’t start until the FOG Admins wants it to, that would eliminate that source of imaging pain. Also if we can keep the fog client from starting during reference image development, we can keep the fog client from tattooing to the defined FOG server until after OOBE is run (I’m not sure if there is a benefit there).

On the back end to turn the auto start service back on we could have a command line option for the fog client to start the client and enable the service that can be called from the setupcomplete.cmd file. Something like “c:\program files\fog\fogclient.exe /autostart” (I just made up the path and file name just as an example)

@george1421

yes!

@pecata This still, too me, would seem to indicate one of the systems in the session has a bad hard drive, though it’s trying to write the data to that block.

Of course I don’t know exactly.

I assure you, this isn’t something FOG is causing. There’s something in your environment causing this to occur.

@redbob With the access control plugin. Enable the plugin system inside FOG Configuration -> FOG Settings, then install the access control plugin. There’s some threads here in the forums on how to use it.

Right now your only option is to image on an isolated network away from your production network. I suspect that WDS is using proxydhcp which will override your setting in dhcp options 66 and 67. There is no way around this AFAIK.

It would be interesting to see what WDS is actually doing this tutorial tells you how to do this with the fog server: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Or you can use wireshark with the capture filters of port 67 or port 68 or port 69 or port 4011

If you want us (or me) to look at it upload the pcap to a google drive and either post the link here or IM me the link and I’ll review it. It would be interesting to know exactly what WDS is doing here. But in the end, having an isolated (but routable) imaging network is probably your only solution. You just need a network where you can limit the broadcast domain to only that subnet.

@quazz You’re right. Must have been a bad spot or something. One thing we all know Windows does is to add a minimum of two partitions on a clean install. Mine had 3 (ms system reserved, empty) partition. Did lots of research, found I don’t need three, just setup GPT with single partition, did base install, and now FOG imaging upload works.

Thanks for pointing me in the right direction.

@x23piracy said in [Windows (Powershell) / Username=Computername]

@Tywyn like @Avaryan said why not use unattend.xml to create local users?

Having a Powershell-script, that does more, for example, set ip-addresses, active office/windows, sets the correct time, etc.

AND: I have no idea how to use unattend.xml 🙂

@rabus The client communicates with the server over http for command and control functions and then NFS and FTP during imaging .

The client uses http and tftp during pxe booting process.

I feel there are some undisclosed meaning in your questions. If you were clearer with what you need, we may be able to provide a better quality answer for you.

@Joe-Schmitt wrote the slack plugin.

@george1421
That is gold. Thank you.

@joseska Sorry for the late reply! The fog-client detects the system language and uses that to display the messages. No configuration needed except for setting the system language to Spanish in your case.

@george1421 said in FOG MENU FILE:

@breit The boot.php script builds the iPXE menu on the fly based on what the client is asking, the state of knowledge about the clinet, and what the client is. There is no static file that can be changed. If you want to change the iPXE menu you can

Work within the frame work the developers have provided with the iPXE menu configuration in the FOG Settings. Write your own plugin to alter and hook into the boot menu creation. Hack the php code to make the boot.php page create things the way you want.

Each has its drawback and advantages, but beyond step 1 you add quite a bit of complexity to your task.

Thanks for the Info and all your help!

@freak
checkin and obtain taskid

http://FOGSERVER/fog/service/snapins.checkin.php?mac=MACADDRESS

then to update status:
http://FOGSERVER/fog/service/snapins.file.php?mac=MACADDRESS&taskid=TASKID&stateid=STATEID

@Foglalt Thanks for the thumbs up! You are welcome and I am sure we can figure out what’s wrong in case this is still happening with 1.4.4! Please keep us posted.

@thiagotw Hey I’m glad we were able to get it worked out. And I have to say, your graphic is way cooler than my avatar!! Maybe someday I will get that good with graphics to update my avatar. 🙂

Ah well … turns out i’m just simply blind 😛

I changed the path in the commands to my local folder structure but missed one spot … since it booted pretty far I thought everything must be written correctly, turns out: No.

Thanks for the help.

Yes there is a kernel parameter for that its the vga parameter.

vga=792 This should be 1024x768x24

ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980