Everything is working for me now! hooray for the new inits!

Future readers, please see: https://forums.fogproject.org/topic/6435/multicast-start-button-please

@Tom-Elliott said:

There is a time limit and the number of hosts to start.

I set ours to 5 minutes.
The setting is located here in FOG Trunk (pre FOG 1.3.0):
FOG Configuration -> FOG Settings -> Multicast Settings -> FOG_MULTICAST_MAXWAIT

0_1452188799247_upload-efe48a0b-9fdc-486f-a53f-9de0129aaf71

@Jbob It’s compatible with Windows 8.1

@hugothebas This article applies to 1.2.0 and below: https://wiki.fogproject.org/wiki/index.php?title=Advanced_Boot_Menu_Configuration_options

@Wayne-Workman It will replicate to the other nodes.

@Wayne-Workman Good catch! I had exactly this in mind when I said that we had issues with empty disks with fogpartinfo. The new method (using lsblk) should work on empty disks. Would be interesting if someone could test this as well. Easiest would be to boot an unused client into debug mode. Then use the dd command from KKTwenty101’s posting to “murder the partition table”. After that try deploying (using the init files I posted) to that client.

@Jbob said:

@mrayzies not a problem. To answer those questions:

Yes, the client installs your servers’ certificate and ours. The “FOG Project” CA (made by us) servers 2 purpose. SYSTEM level services need to be digitally signed otherwise windows will throw security errors (I have seen this issue when imaging a machine with an unsigned client). This can also be used to ensure no tampering was done with the client files That certificate is used to “verify” upgrades. Lets say we release v0.9.10, the client will download the msi from your server and check if it was signed by us. If the msi was somehow tampered, the digital signature would no longer be valid. Using HTTP over HTTPS has no security benefit to the client. Why? Because all traffic is already encrypted. Here’s a very basic overview of how the new client communicates Each client has a security token. This is used to prove to the server that the client is the actual host and not an impersonator. This token gets cycled constantly. When the client first makes contact, it encrypts its token and a proposed AES 256 key using RSA 4096 using your server’s public key. (This public key is verified against the pinned server CA certificate by checking the x509 chain and fingerprints). If the server accepts the security token and the new AES key, all traffic from that point on is AES 256 encrypted using that securely transmitted key.

The whole point of our security model is to allow for secure communication over insecure medians.
Even then, the client installation has an HTTPS option, but it serves no real security benefit.

This stuff and a little other stuff has been added here:
https://wiki.fogproject.org/wiki/index.php/FOG_Client#Security_design

Added here:
https://wiki.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options
and here:
https://wiki.fogproject.org/wiki/index.php/Include_any_ISO_in_the_FOG_Bootmenu

This is related somehow to image replication. There is a much more specific thread here: https://forums.fogproject.org/topic/6296/replication-to-storage-nodes-not-working-trunk-version-4487

Solving this thread as there was never anything wrong with resizable images on this fog revision.

@fredlwal You will need to help us understand a bit more about your network. How is the network (distant) different than the network in the building you are?

Is there a router or firewall that isolates your building network from the rest of the network?

@fredlwal said:

@Wayne-Workman said:

undionly.k

So for option 67 do I still have to copy /tftpboot file undionly.kkpxe or just type that in the string value?

Just type in undionly.kkpxe for option 067 and the FOG server’s IP for 066. You don’t need to copy anything.

@fredlwal said:

@Wayne-Workman and does this have to be placed on all dhcp servers at each building?

Only on the ones you want to use with FOG. If you have slow WAN speeds, you might want to setup a storage node at each location and setup the Location plugin.

For the reference image build out, I have our setup configured to build the reference image completely using a single set of task sequences. That task sequence lays down the image (on the reference image) runs the windows udpates, installs office, vc runtime libs, and all of the other applications then runs a final windows update. Without the windows updates I can build the reference image in about 20 minutes. With the windows updates it takes about 14 hours (no problem I just start before I go home). Then once that is done I sysprep the image and capture with FOG.

Now I didn’t mention the drivers. In our case when we setup the reference image, we tell windows to look in the c:\drivers folder for any drivers. Then during OSD (OS Deployment) after FOG lays the image down on the target machine we run a fog postinstall script that picks up the model of computer and then copies the right drivers onto the target computer (c:\drivers). That saves us from having 15GB of drivers (12 Dell models worth) inside our captured image. Our golden image is about 15GB in size using this process. Also we can add new models without having to recapture the reference image. We do rebuild the reference image once a quarter to pick up the latest windows updates and to include updated add on applications (i.e. flashplayer, java, etc.) when required. But with a fully automated reference image build there is no heavy lifting to rebuild the reference image.

Excellent thanks!

I think I had this problem with fog 0.32 also. Does fog stay logged in when you let a tab with the logged in fog home screen (with the graphs) run all the time and open new/other tabs for working with fog? (Didn’t monitor fog 1.2 and svn versions for this problem yet)

also if you are creating a “universal” image and can spare an extra 10gb or so then look at “snappy driver” for deploying drivers. That is what I use for my “universal image”.

for our Windows 7 image I did the following:

*set up our “unattend.xml” using a workstation.
*from within a hyper-v guest, install fresh W7 and boot into audit mode.
*install base software (office, serif, any other site licenced products).
*install FOG client
*copy snappy drivers and download the packs.
*configure setupcomplete.cmd to run my snappy driver .bat. This BAT autoruns snappy driver to install MISSING drivers, then deletes the folder of drivers when completed.
*windows update
*copy the unattend.xml created earlier.
(I then “backup” my VM at this point so I can come back to it later)
*sysprep shutdown and generalise
*capture the image into FOG then restore VM from backup ready for the updates next time.

To get snappy drivers to install, simply open it, update the packs, then in your setupcomplete.cmd call

SDI_x64_Rxxx.exe -autoinstall -autoclose -license

The batchfile also cascades into an RD and shutdown reboot at the end of it so it is self cleaning. NOTE I also shutdown the FOGClient service in my setupcomplete.cmd as I DONT want it to join the domain as soon as it sniffs the network! It will join the domain (and rename etc) AFTER the drivers have been installed and rebooted. The batch file also ensures our KMS key is added and I run slmgr /ato. I also add the office KMS key and activate that at the end too, whilst there are default KMS keys when products are installed, I have other images with MAK keys as some of our machines are destined to be unplugged from the network (exam machines etc).

My image is a monster, weighing in at 40gb but works on every single machine I have thrown it on and they are pretty much ready to go (WSUS always has more updates on first boot)

for crying out loud, im blind as a bat. Sorry. With all the “fog.” I missed my own on the bottom.

Also please remember that UEFI is not necessarily Secure Boot. Secure Boot is an optional feature of UEFI, which you you will need to disable if you want to boot ANYTHING other than Windows. Yes, technically Secure Boot signing is available to the Linux community, but very few Linux kernels will ever work with Secure Boot.

UEFI support handles the new method of using the hardware initialization and interaction which is much more efficient than BIOS, which is one of the reasons that an OS that supports UEFI can boot so much faster on a UEFI board. So yes, you can make FOG work with a UEFI ecosystem, but you will either need to disable Secure Boot on each workstation every time you want to boot it with FOG, or you will need to disable Secure Boot completely. Honestly Secure Boot is more of a benefit to consumers, and only helps prevent them from getting their bootloader hijacked. A company or enterprise network should have other security measures in place that help prevent and/or mitigate this risk.

Via Google:
http://stackoverflow.com/questions/3407823/mysqlnd-driver-in-php-5-3-2-on-ubuntu-10-04