@tprice What new documentation (for future readers)?

@Scott-B just about every printer in the building is a different model. of which we have about 100. Some are USB, some network.

I manage the network ones with Active Directory without issue - it’s just this one printer being stupid. It needs replaced. It doesn’t even have drivers for Windows 7, I finagled Windows Vista drivers onto Windows 7 as a local TCP/IP installation before. It’s just impossible to deploy with Active Directory - everything I’ve tried has failed - and I’ve tried a lot.

Fog was my last resort.

But, here in the future, if it proves to be reliable and I think it will be, I want to use FOG for printer management because it’ll lighten the load on our DCs.

@Wayne-Workman Great video. Yeah, your image size isn’t large enough to find the standard transfer rates. Just as the transfer settles down its done. (not a bad thing). In our virtual environment we can pull a sustained 6-7GB transfer rate. That is with a VM with 2 vCPU and 2GB of RAM running on a 24 core processor. But again as long as the server can move the image from disk to net pretty quick, all of the heavy lifting is done by the client. On a e6410 with a HDD we can get no more than 4.5GB/min exchanging that HDD with SSD increases the transfer to 6.1GB/min on the same hardware.

Just for comparison, when I was working with that intel NUC as the FOG server. That dual core celeron with an 256GB SSD was able to transfer at 5GB/min to a e6410 with a SSD. So really the FOG server isn’t the key to deployment speed. It more compression used and target computer performance.

But either way FOG is darn impressive that it can wake the computer up and deploy a new image in under 3 minutes. With that you could almost reimage a whole computer lab {between classes} at any school system. That is impressive.

@george1421

Sorry for the long delay I have been swamped with other project. Thank you for getting back with me and the link to the guide. I will look into possibly upgrading that server to 2012. Thank you again for all of your assistance, it really is appreciated.

Thanks,

Anthony

I couldn’t resist the challenge. This should get you pretty close.

#!/bin/bash . /usr/share/fog/lib/funcs.sh; mkdir /ntfs 2>/dev/null echo "Mounting Windows File System"; mount.ntfs-3g "/dev/sda2" /ntfs 2>/tmp/mntfail mntRet="$?"; if [ ! "$mntRet" = "0" ] then echo "Failed to mount Windows partition"; echo ""; cat /tmp/mntfail; echo ""; sleep 12; exit 1; fi #Mount successful echo "******************************************************"; read -p "Enter your room number " rn echo "setx /M RoomNumber \"${rn}\" " >>/ntfs/Windows/Setup/Scripts/SetupComplete.cmd echo "******************************************************"; umount /ntfs sleep 5;

@Sebastian-Roth said in BASH on Windows 10 … and maybe FOG also?:

as well do Intel Macs (confirmed in my own lab!!)…

Any news on that subject? My organization has thousands of Macs. Is it easier now?

@ITCC Would you be willing to get a step-by-step guide for Debian ready? Would be a great starting point.

I’m sort of ashamed that I haven’t done any of the things I said I’d do in this thread yet 😕 I’ll make it a point to test out the various file types soon.

@chimchild That would do it. I favor iptables for major network appliances. It’s commands and config make more sense to me than firewalld does.

@C-M said in How do fog images work and can it do this?:

I’d prefer the thin method as it seems easier to keep up to date and add and remove apps at will.

Both thin and fat images have their place. If you update your images every quarter (to have the latest windows updates) then adding in your software is not a big deal (as long as MDT does it). There isn’t any more work involved than having a thin image and layering on the applications post deployment. Plus with a fat image I can go from bare metal to fully deploy and ready to move to the work site in about 13 minutes. That is with MS Office, SAP GUI, AutoCAD, and a few other PIG applications.

Using a fat image (and a multicast deployment) I can redeploy to a whole lab (50 workstations) in about 20 minutes. With that said there is also uses for thin images where you might have a dynamic application load. In that case we push the image out with FOG and then use PDQ Deploy to deploy the application set to the workstation. (I could use FOG Snapins for this too, we just had PDQ Deploy setup first).

Nope not a problem. But its easier with dhcp.

You may be able to do what you want using snapins and a 3rd party tool.

i believe i was able to get the esxi iso to boot using memdisk iso raw

Yeah that makes more sense

@Wayne-Workman

Thanks Wayne.

For anyone who finds this thread, on Ubuntu, just cd to /etc/php5/apache2 then edit php.ini

Using nano to edit, find upload_max_filesize and post_max_size and increase both as desired. I increased mine to 3000M (3GB approx.)

@Sebastian-Roth Go ahead and mark it solved, I haven’t had time to test and probably won’t anytime soon. It’s that busy time of the year 🙂

@mm-Ekimia May I point you to a topic in the iPXE forum where one of the main developers was saying that “USB support is starting to arrive in mainline iPXE” only about a good year ago. They have made progress I am sure! We have seen more and more people successfully booting their devices with USB NICs on iPXE.

The biggest problem from my point of view is if you want to PXE boot from the USB NIC! Using an USB NIC with linux (as you do right now) is fairly easy because linux takes control and provides full access through own drivers. Completely different if you want to PXE boot from the USB NIC. Then your client machine - its BIOS/UEFI firmware - must be able and willing to talk to the USB NIC for PXE booting. Sounds like you don’t aim for that but just wanted to point that out!

Back to your initial question… booting iPXE via USB key - which is easier than USB NIC PXE booting but still harder than booting linux to use the USB NIC. As George already said it’s a matter of finding a USB NIC adapter that is supported by iPXE. I started a list of supported USB NICs some time ago. Unfortunately I lost track of it all as it was very hard to follow without having my own devices for testing. Maybe this is a good point to start again. Searching the forums we should be able to find a lot of information as lots of people have tried USB NICs lately, known working e.g. ASIX AX88772C…

But that’s still not the whole story I’m afraid! iPXE provides native drivers (should work both for UEFI and legacy BIOS) as well as UNDI (for BIOS) and SNP (for UEFI):

undionly.pxe, kpxe, kkpxe, usb, iso - BIOS no native drivers ipxe.pxe, … - BIOS with native drivers and UNDI interface snponly.efi, usb, iso - UEFI no native drivers ipxe.efi, … - UEFI with native drivers and SNP interface smsc95xx/intel/realtek.XXX - “single” native driver

So you might need to play with the different iPXE binaries to see which one is working for you. Please let us know which USB NIC exactly you have - make and model!!

Edit: I just updated the mentioned wiki article. Hope this is useful for a lot of people. Please keep us up to date with USB NIC adapters you try.

@Sebastian-Roth @Wayne-Workman I think an adjustable time would be nice though. Hard coding in a time might not be best for everyone, I am not a seasoned programmer but coding a field in the DB along the same lines as the FOG_SERVICE_CHECKIN_TIME to give the time a value doesn’t seem like it should be much harder. FOG_CRON_TASK_EXPIRY. Having it a global value, and not per task I think would be fine.

That way it could be set in a fashion of every night run this task, if task hasn’t been run in X min delete task. This would allow a task to run at anytime through the night, but expire before morning when the computer would be used.

@Wayne-Workman bolder the better, I say 👍

@fredlwal Most probably a FTP credentials problem: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP