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.



  • 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.


  • Senior Developer

    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 do use Symantec, could this be blocking some of the modules from starting correctly?


  • Senior Developer

    Check your PM inbox.



  • 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)



  • 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.


  • Senior Developer

    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?



  • Here it is.

    [url="/_imported_xf_attachments/1/1996_fog.log.txt?:"]fog.log.txt[/url]


  • Senior Developer

    The client install will prompt you:

    Install for just me
    Install for everyone

    Choose everyone. Secondly can you not deploy snapins manually before imaging, and then upload C:\fog.log for 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.


  • Developer

    no, i mean “everyone” vs “just me”



  • 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.


  • Developer

    did you install the fogclient for all users?



  • [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).



  • 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.


  • Developer

    “OS2 Warp on HPFS and German MSDOS machines” are capable of running the fog client? i’m confused


  • Moderator

    [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.



  • Will not perform any SnapIn tasks because an image task exists for this host.


  • Moderator

    What does the client logs say?


Log in to reply
 

449
Online

39209
Users

10856
Topics

103338
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.