Using FOG as Disaster Recovery System
-
There is an active task queued and visible in the GUI. and for system info I’m running FOG 1.2 and Ubuntu Server 14.04.2.
-
[QUOTE]“OS2 Warp on HPFS and German MSDOS machines” are capable of running the fog client? i’m confused[/QUOTE]
No, those will be purely iPXE user reboot. The reboot task is a problem for our windows machines which is the majority (80/20 rule).
-
did you install the fogclient for all users?
-
I’m only working on one windows 7 machine currently. This server build is in the proof-of-concept stage, but yes, FOGclient is installed on it.
-
no, i mean “everyone” vs “just me”
-
I’m not sure. So I’m uninstalling it. i realized though that I installed it as my AD login instead as the Local Admin login, so I’m going to do this new install as Local Admin.
-
The client install will prompt you:
Install for just me
Install for everyoneChoose everyone. Secondly can you not deploy snapins manually before imaging, and then upload C:\fog.log for me?
-
Here it is.
[url=“/_imported_xf_attachments/1/1996_fog.log.txt?:”]fog.log.txt[/url]
-
You tried scheduling an upload or deploy for this computer WHILE the client was running, correct? (You should also give it several minutes to check back in for the task reboot). And this log, it seems none of the modules are running except SnapinClient, are the others disabled?
-
Everything is enabled but nothing is ‘in use’. I don’t have groups set up nor have i changed any settings from defaults save for the pxe boot menu items. After I verify items work as intended with a the ‘unnecessary’ features left on and alone I’ll go through and start narrowing the services down. The only thing I want to do are cron-style uploads that will forcefully shut down a work station to start the process (only get certain windows in a week for some of these systems) and on-demand image downloads (instant deployments) in the event of a disaster situation.
Forward thinking, after I get this working, I’d also like to have 2 versions of an image for a workstation (or two image containers/images) one for the current upload and one for the previous just incase something bad piggy backed into the newest upload, but that’s after this hurdle.
-
Just attempted another immediate upload task with the force start on and it’s been around 20 minutes yet with no reboot. (just an update)
-
Check your PM inbox.
-
We do use Symantec, could this be blocking some of the modules from starting correctly?
-
Like a said in the PM, your logs are just off. Task Reboot is starting but not continuing. I would need to have remote access to the system to see what is wrong, as the legacy client is … unique. Or you can use the new client (still in beta, but for what you want it will work perfectly).
-
We managed to fix this. We had to go into the FOGClient config.ini which is located in the etc folder of the FOGClient installation folder. We had to change forcerestart under the taskreboot from 0 to 1. That’s all. If anyone has wiki access to change the Client setup page, please be sure to include this.
