Network, AD integration, and overall setup help needed

[Gink]

Hey all,

So I am very new to this whole situation, mass deployments, Linux, and large scale networks, so please bear with me.

In about a month I will need to be reimaging roughly 350 windows machines. I have chosen fog as my deployment method. The tricky thing about the network that I am on, is that the DHCP server isn’t hosted on either a Windows server or a Linux server. Instead, it is being handled by a Zyxel router. This router doesn’t(that I have seen)let you set a pxe boot server; it strictly does DHCP. So with that out of the way, does anybody know if there is a way for me to integrate a Fog server into this type of network?

What methods do you all use?

Anybody use NIC teaming/bonding?

Also, what kind of hardware are you running your servers on?

With my current build I can push out an image on a closed network, but I would like to be able to take advantage of the higher functions within fog such as AD integration, clearing of local users, and green fog.

If anybody can give me a hand with this, I would greatly appreciate it!
(Any advice for changes are welcome as well!!!)

[george1421]

DHCP: If your dhcp server doesn’t support dhcp options 66 {next-server} and option 67 {boot-file} then you can use an extension called DNSMASQ. This setup will allow your zyxel router supply the ip address and the dnsmasq service to function in a proxydhcp function and supply the missing boot information. I did write a tutorial on how to set this up using centos 7. The setup is very similar for other linux distros. If you have vlans behind a router, all you need to do is setup the fog server (running dnsmasq) as the last host in your dhcp-relay server. This setup will then supply hosts on other subnets with the proper dhcp boot info.

1. What does everyone use. Various dhcp servers, mainly MS DHCP server, others use linux, and still others use either switches or routers with dhcp servers built in. Either way, if your dhcp server doesn’t support it then dnsmasq can help.

2. NIC teaming only really helps when you do more than one unicast deployment at the same time. Teaming only give move lanes for traffic so you can deploy to more than one system at the same time. I can deploy a 25GB Windows 7 fat client in about 4.5-5.0 minutes. The server is really only moving the file from disk to the network to the client. The client (target) is really doing the heavy lifting by compressing (on upload) and decompressing (on download). If you need to deploy to more than 5 hosts at one time, you might want to consider a multicast (or broadcast) deployment. This way you can deploy a single image to a whole computer lab at one time and only consume the bandwidth of just a little more than one unicast deployment.

3. What hardware do you run on: Virtual. Again the FOG server really doesn’t consume much vCPUs. I’ve installed FOG on a dual core celeron intel nuc all the way up a massive 24 CPU virtual host server. The server isn’t really a factor for a fast deployment. Having a fast disk and GbE network is.

4. Closed network: You can use fog if you want to deploy over your business network, or if you want to setup fog with dual nics, with one for your business network and one for an isolated deployment network. Either mode will work. If you want a dedicated deployment network then I would setup the server with a single nic first and then install FOG. Once fog is setup then add the second nic for your business network for FOG server management. This ensures the FOG services are bound to the proper interface during setup. You can either have FOG connect your target computer to AD, or you can just have the unattend.xml file do it for you. I’ve done it either way.

If you plan on deploying to systems with UEFI firmware, GPT disks or WIndows 10, you will want to install the trunk version of FOG (pre-fog 1.3.0) since the 1.2.0 stable version of fog doesn’t support the previously mention features too well. The trunk version of fog is mostly stable so you shouldn’t be afraid to use it in production. I’ve been using different stages of the trunk version for over a year. The dev team will typically jump on reported bugs in hours (sometimes minutes) and have a resolution almost as fast.

[Wayne Workman]

Also a side note - DNSMASQ will only work with BIOS type firmware.

Many machines today are shipping with UEFI enabled by default. UEFI type firmware is indeed the future, but other technologies that are built around firmware haven’t totally caught up yet. DNSMASQ is one of them.

If you require UEFI network booting, I’m afraid you will be forced to change your DHCP setup. If BIOS will work for you, then you may use DNSMASQ just fine.

[Tom Elliott]

@Wayne-Workman for clarification I think dnsmasq only works with just bios when used as a proxydhcp method. If you’re using dnsmasq as the primary dhcp server, uefi is supported.

[Gink]

@Wayne-Workman
Thank you for your reply! This will work perfectly because 99% of my machines are not UEFI.

[Wayne Workman]

@Tom-Elliott Yup, correct. But, if you aren’t using DNSMASQ in proxy mode, then you should probably just run a full ISC-DHCP server. In relation to FOG, we recommend DNSMASQ for Proxy Mode.

[Gink]

@george1421 OK, so I set up a test virtual fog server and installed DNSMASQ as per your instruction page/fog wiki. I was not able to find where I enter the IP of my fog server into my router(Zyxel USG 1900). However when I tested it on the same vlan as my fog server I got the message to press f8 to choose boot. When I selected “boot from network”, it looked like it was going to sucessfully finish booting to the FOG pxe menu, but instead it jumped past that and began to boot to Windows.

Any ideas?

(This is all my router allows me to configure for DHCP):

[george1421]

@Gink Just for clarity since your dhcp server does not support dhcp boot options there is nothing to change there. You don’t/shouldn’t touch your dhcp server settings if you have dnsmasq (dhcp proxy) setup correctly. The settings for your install are done in dnsmasq. If you have set it up as my tutorial is outlined it should just work as long as the fog server (running dnsmasq) and the target computer are in the same broadcast domain (subnet/vlan).

Make sure the dnsmasq service is running on your fog server.

You should be able to press F10 or F12 depending on the target computer during the initial post and select NIC or Network boot then you should see the PXE ROM attempt to pick up a dhcp address, if everything goes well you should see the iPXE kernel load and then after a short discovery period the FOG menu. You have about 3 seconds at the fog menu to move the cursor up or down or it will default to a hard drive boot. If there is a problem with pxe booting you should get an error message like EXX-XXXX as an error number. We’ll need to know that error number or take a picture of the pxe error screen with your mobile phone and upload the image here.

[Gink]

@george1421 I apologize for not getting back sooner. I restarted my server and made sure that DNSMASQ was actually running. This time when I attempted to PXE boot it actually completed! One little quirk that I noticed was that one of my machines took a really long time to obtain an IP…
Now, I’m not sure if this is possible, but would it be difficult to make this work cross vlan? Or will it only work with clients within the infrastructure vlan?

My current setup is this:
Fog server is on infrastructure vlan(172.16.1.x)
I need to use Fog on Staff vlan (172.16.10.x), and Student vlan (172.16.20.x)

Here is a section from my setup file:

# This range(s) is for the public interface, where dnsmasq functions
# as a proxy DHCP server providing boot information but no IP leases.
# Any ip in the subnet will do, so you may just put your server NIC ip here.
# Since dnsmasq is not providing true DHCP services, you do not want it
# handing out IP addresses.  Just put your servers IP address for the interface
# that is connected to the network on which the FOG clients exist.
# If this setting is incorrect, the dnsmasq may not start, rendering
# your proxyDHCP ineffective.
dhcp-range=172.16.1.31,proxy,255.255.0.0

Thank you guys so much! You have no idea how much you have helped me!

[george1421]

@Gink OK the first step is to get it to boot on the same subnet. The next step is a bit harder. Its not so bad if you are using a MS/Linux DHCP server, with DNSMASQ the next process “might” work.

On your router between the vlans. You probably setup a dhcp-helper or what also called a dhcp-relay service. In that service configuration you would typically point that service towards your real dhcp server. Then the router knows where to send the dhcp requests it hears on other vlans. Now in this setup, add the fog server IP as the last device in your dhcp-relay service configuration. You still want your main dhcp server to provide the IP addresses for everything, just dnsmasq has to hear the request so it can reply correctly, otherwise the dnsmasq service is only listening for dhcp broadcasts on its local subnet. (understand this is just off the top of my head, but it sounds logical)