@george1421 and @Jaymes-Driver fyi, this is what I’ve been referring people to: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
It’s step-by-step procedures for moving from an old server to a new one using the most linux-noob friendly methods I could think of, and has links throughout it to other relevant resources.
@sourcaffeine Well if these 60 computers are all identical besides the HDD, then taking an image from one that deployed correctly isn’t going to prove or disprove anything, because the original image also deployed correctly on some of these systems.
For a sanity check, check the free space on the server, look for partitions that have 100% use:
df -h
The error you gave in the OP, that’s not the one that is typically given when the FOG Client is causing the issue. The error literally says “could not complete the installation…” The installation of what? My guess? Drivers, maybe some weird attached device like a scanner or printer or flash drive or SD Card, we’ve actually seen times where an SD card that people left in laptops will cause issues for capture/deploy sometimes.
But, I’m going to guess drivers.
There’s some simple troubleshooting to figure out what’s going on.
To test if it’s the FOG Client causing the issue (which I don’t think it is), just delete these 60 hosts from fog, and manually using the boot menu do “Image Deploy” with the correct image. When the computers boot after imaging, the FOG Client will communicate with the server but not get any commands to do anything in this case. If this works fine consistently, then the FOG Client is probably not disabled on your reference image. If this doesn’t make a difference and the systems are still having issues booting after imaging, it’s probably at that point that it’s a driver related issue like @george1421 said, and I’d follow his advice.
Another very simple thing it could be - mismatched HDD operation modes in the firmware, and mixed operation modes, or the image is BIOS but some of the machines are in UEFI mode in firmware.
@sabotage Put a small server at each site. The hardware can be your choosing. You could use small and low-end servers if you have the money, or you could use old desktops for it. Up to you. Then setup your main FOG Server at HQ, and install all the site’s boxes as fog storage nodes. The storage-node installation process allows you to attach it to a main fog server. Then setup the location plugin and configure all your locations. We have documentation for this in our wiki. But…
For now - you really should just setup a test FOG Server at your HQ and just try things out. Generally, newbies of FOG have lots of questions about basic stuff.
@imagingmaster21 said in Windows 7 Image:
The machines using the image will be using BitLocker Encryption.
FOG cannot image machines with bitlocker encryption except with RAW images, which is terribly slow, inefficient, and the worst way to image.
Here’s the best practices:
@george1421 Right, and then there’s the problem of DHCP giving out the right binary, and that binary requesting the right kernel and init.
@aruhuno Typically this is because when ran manually, you are running the script as Administrator, but when the FOG Client runs the script, it runs the script as SYSTEM. There are limitations on what SYSTEM can do, this is by design of Microsoft for security related reasons. To figure out what’s wrong, I’d suggest redirecting the output for those lines to a log file, maybe it’ll reveal the error.
@dclark Please do share with the community. This is an excellent way to contribute to the fog project. Also, it’s always refreshing and nice to hear positive stories about FOG.
Oh you know what? I just figured out why this happened. blah.
I was just talking to Tom and he asked to see if the /home/fog directory existed.
It doesn’t. Why? Because I blasted the entire /home directory this morning because all those fog backups in there was crashing the server… rm -rf /home/* Yes sir…
I fixed it with
mkdir /home/fog;chown fog:fog /home/fog
@jpaul You’ll most likely have lots of problems using 1.2. I recommend you update to 1.4.4 - instructions are here: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG
I’m liking this guy already.
I found this: https://wiki.fogproject.org/wiki/index.php/FAQ and I’m wanting to update it. If you have a question:answer to add, post it here.
Raymond had the same issue I had, I remoted in via join.me and did the same troubleshooting steps that Joe instructed me to do. It gave a driver error. We swapped out the driver for another and it worked. We did some tests with removing the printer via fog and re-adding it, both were successful…
Unlike my work, Raymond has copied all drivers he needs to the local c:\ drive, in a hidden folder. This appears to be working, but there was simply an issue with one of the specified drivers. It could have been something as simple as a typo, or an incompatible driver, or bad arch or something, not sure. At work, we are successfully using a anonymous read share to distribute drivers now and it’s working, and this problematic printer Raymond has is now also working.
using the printer manager helper is the first way to troubleshoot a printer deployment issue. It’s got a 2nd tab at the top for adding a printer. Just plug in the settings you have for the fog printer, and hit add. It’ll either work or throw an error which will guide you to a solution.
Here is the link to the printer manager helper, you will want to use the version corresponding to the fog client version you’re using:
https://github.com/FOGProject/fog-client/releases
@robertkwild In addition to the link posted by @igorpa2 and in addition to this wiki article refered to by @Sebastian-Roth, there is a tool called updateIP.
updateIP was created as a easy to use tool for updating your FOG server’s IP settings after you’ve updated the OS’s IP. I would highly recommend it.
Found this in my error log, which is pretty obvious:
sh: htmldoc: command not found
sh: htmldoc: command not found
If you look at the history on that one, it was added by “admin” in 2010 (probably by @Chuck-Syperski). I don’t remember seeing this article before.
When I was doing printers with fog (which works great last I used it), I just made a share on the Windows server to hold drivers, accessible anonymously.
This article is newer and better suited for creating samba shares: https://wiki.fogproject.org/wiki/index.php?title=Password_Protected_Samba_Share
I wrote that in 2016 when there wasn’t even RHEL 8/CentOS 8, but had foresight to add the correct commands.
Wow is this a huge improvement, it’s so sleek and sexy!
@Joseph-Hales said:
I would think multiple uploads would be an edge case I would love to have this as a feature especially if it could compress a temp copy so you could deploy immediately.
Well, I suppose the uncompressed copy could serve as the “temp” copy.
And, I suppose FTP could go ahead and just move that over from /dev to /images like normal
and in the background, the server could compress the /images image to /dev and when it’s done (and waiting for active tasks for that image to complete), it could replace it with the compressed copy?
Using scripting techniques, the base command is this: msiexec /i FOGService.msi /quiet WEBADDRESS="x.x.x.x"
Look here for information on the new client: https://forums.fogproject.org/topic/4250/new-client-progress
@Jbob is the new client developer. He’s talked about having the new client automatically uninstall the Legacy client but I’m unsure if this has been implemented yet.
I think this is easily accomplished.
Using Ch3i’s script for compression, and making that automated, and scheduling a Cron task on the server to run that script every hour or so should do the trick.
The script will need a default compression set, and it’ll need to check the DB for any images that aren’t set to that default (say, compression 1). Then, it would check to see if that image exists in it’s storage node, if so, recompress it to /node/dev , and then check the DB if there are active tasks associated with that image… and just wait till they get done, then replace the old image with the new.
I think I can do this, I’ll try tonight or tomorrow night.
@Arrowhead-IT said:
Also, I love that I can install the client and it adds itself if the client isn’t already in fog.
In my opinion - that is singularly as large of an improvement in FOG as the entire new client is.
The whole idea behind FOG is to lower workload. And clients automatically reporting in for approval is FAR better than registering 1,000 computers by hand, or trying to rely on importing some shady spreadsheet that probably isn’t half correct with a million typos in it.