Using FOG as Disaster Recovery System
-
We currently are using SCCM for our deployment needs but we (the SCCM team) had issues using that same system for Disaster Recovery purposes (scheduled dedicated image uploads with on-demand dedicated image downloads, dedicated meaning 1 image for 1 machine). In search of something that will work with all of our systems (we have some god awful legacy stuff) I have run across FOG (an iPXE, PartClone solution capable of sector-by-sector imaging). In practice this has worked great so far; register host with server, create image container for host, flag the host for upload using CRON, reboot host after flag is set. All of this is being done without implementing FOGClient making it non-intrusive to the image itself. BUT the powers-that-be (supervisors of our target users) would rather not leave the reboot up to the users (what if the reboot gets missed at the end of the shift, troubleshooting happens during a shift, reboot is required, then the image starts; this will result in downtime). So I turned to FOGClient to perform a shutdown -r on windows systems.
If I first schedule the upload task, then the snapin deployment (shutdown -r); the snapin never happens with no error. If I schedule the snapin deployment then the upload task, the upload task fails because the Host already has an active task. To answer that I created a snapin that would run a .bat which uses the schtasks.exe in windows to schedule a shutdown -r task that reoccurs every 20 minutes for the next hour (should only need to happen once, but just in case the upload task doesn’t flag before the first reboot), then I schedule the upload task for 10 minutes after the snapin. The snapin finishes installation, the upload gets scheduled, the computer reboots and, ta dah, upload is happening with ZERO user interaction. BUT only if the user is logged in will the snapin load under their credentials (based on how the service is running) so I change the service to run as an admin, now the service doesn’t communicate with the server. End up having to reinstall the service and reregister the host to the server to get the scheduling to work again. After an afternoon of playing with this setup I decided it may not be worth trying to use FOGClient for this purpose and instead use the schtasks.exe from the IT computer to schedule the task for a distant end (this would also have the benefit of not installing the FOGClient service on the host computer, it’s easier to pitch this as a DRS if I don’t have to install local software).
The task I have ahead of me now is to create a Powershell form that generates the schtasks.exe line for scheduling a repeated reboot in the windows after setting the upload flag using cron-style upload scheduling (still working like a dream). If I get this working I’ll end up with a process that requires two systems to prepare a recurring image upload for a computer (granted, it’s all front end work that should work for the life time of the machine…) I’d like to get this down to using one interface for the scheduler. I have found that Powershell can SSH into another computer (say the FOG server) and create the schtasks.exe command, which may mean that I could use one Powershell form to create the schtasks.exe line for the reboots as well as create the cron style job in FOG only… what are the commands involved for creating a cron style upload job for a computer so that it function in FOG as if it were created through the web interface?
(Holy long post, Batman. I would appreciate any feedback/criticisms whether it’d be helpful or otherwise.)
Deastrom
-The computer science student trying to IT. -
I really must ask. Why did you try using snapins to reboot machines for tasks? The client will automatically reboot the machine if an imaging task is waiting. It can even be made to force the reboot even if a user is logged in.
If it wasn’t rebooting for you, PM me and I’ll try and get it sorted out for you.
-
I wouldn’t do a sector by sector image upload… that’s incredibly wasteful and unnecessary.
So, what if the hdd breaks down and you only have one that is slightly smaller to replace it with? Sector by sector will prevent you from getting that system going.
Please use resizable instead.
-
[QUOTE]I really must ask. Why did you try using snapins to reboot machines for tasks? The client will automatically reboot the machine if an imaging task is waiting. It can even be made to force the reboot even if a user is logged in.
If it wasn’t rebooting for you, PM me and I’ll try and get it sorted out for you.[/QUOTE]
Really? I’ll have to play with that…
[QUOTE]I wouldn’t do a sector by sector image upload… that’s incredibly wasteful and unnecessary.
So, what if the hdd breaks down and you only have one that is slightly smaller to replace it with? Sector by sector will prevent you from getting that system going.
Please use resizable instead.[/QUOTE]
OS2 Warp on HPFS and German MSDOS machines… old legacy machine controlling computers.
If resizable handles HPFS well, then I’d be happy to use that. -
Not sure about HPFS.
Works great with NTFS MBR and GPT
-
The client is not restarting the computer while a force-to-start immediate upload task is queued up.
-
What does the client logs say?
-
Will not perform any SnapIn tasks because an image task exists for this host.
-
[quote=“Deastrom, post: 47400, member: 29582”]Will not perform any SnapIn tasks because an image task exists for this host.[/quote]
Is there an image task inside the tasks page?
If not, sounds like your tasks table is dirty. You can manually clear out the active/waiting tasks if need be. -
“OS2 Warp on HPFS and German MSDOS machines” are capable of running the fog client? i’m confused
-
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.
