SOLVED Rolling FOG out to US Site

  • Hi all,

    We’ve been using FOG in our UK site for some time now (I introduced the company to it and they love it!). Now, we want to roll this out to the US.
    I’d ideally like to replicate the images we have on our UK-based FOG server across to the US installation. I’m wondering if a storage node would work for them (if I install tftp and pxe on there, as suggested here: or if there’s a way of installing a separate FOG server whilst being able to manage it through the GUI of the UK-based instance? What would you guys suggest doing?

    Also, how viable is it to update the images over site-to-site VPN? Ideally I’d like to be managing everything through one web gui instead of multiple for different sites.

    Any help with this would be appreciated.

  • @george1421 +1 for a wiki page. This is really useful stuff and I only found out about it when coming onto the forums and talking with George. Without the forums, I wouldn’t have ever found this out/get it working.

  • Moderator

    @Tom-Elliott Tom I feel you are right here. While this is a pretty lengthy thread, there is a bunch of information that can be gleaned from it. What Rob is doing is pushing the envelope of the FOG infrastructure (which is great since it forces FOG to mature and grow). This is the type of activity I would like to see in the FOG Project. I would (personally) like to see enhancements around the “fog servers” cross communication to eliminate the human involvement. Maybe for FOG 1.3.1 or a brilliant plugin (hint, hint) 😉

    My intent was not to cut this thread short of completion, just as a moderator it thing its gone a bit past the original post which hides the rich content of the post. I do think Rob’s current issue should be forked into a new thread since his complete issue is not resolved just yet. Its close but not solved.

  • I wonder if it would be worth while to capture the idea of the whole thread into the scope of a wiki?

    For example, showing how to use the Location plugin.

    Multiple “fog servers” cross communicating images.

    Post scripts that are useful for customizing the client information and installation.


  • @Quazz Simply because it removes some settings we like to keep, otherwise users can spend ages getting everything up and running again.

    Anyway, thanks to everyone who pitched in with this 🙂 It really is appreciated!
    The original issue was answered some time ago and this thread has evolved with the problems associated with it. As such it can be marked as answered.

  • Moderator

    @RobTitian16 First of all I’d like to state for anyone that find this thread in the future this current issue that Rob is facing is not a FOG issue but a Windows image creation one. This thread really needs to be marked solved as the original issue has been addressed. I’m not saying that your current issue isn’t important, only based on your original post this issue has been resolved.

    With that said, Rob I think you need to take a look at how you are creating and managing the imaging process. I can give you an option on how I do this today, but that may not fit in with your overall plan. I use MDT to create my reference image using the lite touch process. From there I sysprep and capture the image with FOG. I use FOG to deploy the image and inject the model specific drivers using a post install script. During OOBE windows picks up the drivers and installs them and then by using a post install script (that I placed in the proper location before syspreping the system) run any last minute activities like installing AV or GUID based applications that are required. Even with sysprep the system takes about 15 minutes to go from bare metal to ready to deploy using FOG. If a new computer model comes out, I just update the drivers cab and thats it. I can/do use the same captured image for every computer model.

  • Moderator

    @RobTitian16 SetupComplete only runs at the end of OOBE state (Out Of Box Experience).

    Might I ask why you can’t sysprep?

  • @george1421 I didn’t think the unattend.xml file would, considering you say in the tutorial:

    “Note: the unattend.xml file is only used if the reference image was sysprep’d before image capture.”
    Unless you’re basically saying to sysprep it. In which case… I guess I’ll have to as I can see the benefits of doing so now with this script, etc.
    Thanks for the help and support as always! It’s been a challenging one, but hopefully one that will be immensely beneficial 😄

  • Moderator

    @RobTitian16 said in Rolling FOG out to US Site:

    I can’t see where the post install script is actually telling the SetupComplete.cmd to run, though. I can see it copies, but nothing tells it to run.

    See I think there is where you may be a bit confused (and rightly so). The FOG post install scripts run in linux so they can’t touch any windows programs or windows behavior. All we are doing with the post install script is placing things where windows expects to find them. As Tom posted Windows OOBE will run what ever is in the setupcomplete.cmd file after OOBE is done and before the first login window is displayed. This is a windows thing and has nothing to do with fog other than fog placed that file there. That file could and should have been there when you captured your master image. But since it was not you are using the fog post install script to kind of patch what should have been there prior to image capture.

  • Moderator

    @RobTitian16 yes if you are using an unattend.xml file.

  • @Tom-Elliott Ahh okay. Is there a way to run this without the image being sys-prepped?

  • @RobTitian16 It will run as soon as the system completes sysprep steps (Setting up your device).

    The last thing it does is “SetupComplete.cmd”.

    The path should be:

    C:\Windows\Setup\Scripts\SetupComplete.cmd (though you can try with setupcomplete.cmd) as well.

    Of not, for Windows 8 and Windows 10, if the image is sysprepped using an OEM version of the software it will NOT run the setupcomplete.

  • @george1421 Indeed, this is something I’ve just found out - the SetupComplete.cmd is there with the FOGService.msi, but the .cmd is never actually executed. The target OS’s are always Windows 7/8/10/Server 2008/2012 R2/2016.
    I’m currently testing this with a Windows 7 x64 OS.
    I can’t see where the post install script is actually telling the SetupComplete.cmd to run, though. I can see it copies, but nothing tells it to run.

  • Moderator

    @RobTitian16 I didn’t even think about not having access client side because I copy files off my NAS by mounting it then copying.

    I think Tom’s suggestion is the answer now.

  • @Tom-Elliott Sorry, for some reason when I posted I didn’t see everyone else’s responses (only Quazz’s).
    I’ll give this a go 🙂 Thanks!

  • @RobTitian16 That is why I suggested copying the FOGService.msi to the postdownloadscripts directory.

  • @Quazz Yeah, I could copy it during the postdownload stage. But how would I do so? /var/www/html/fog/client/FOGService.msi doesn’t in the terminal in debug. I can only go as far as /var/www/ and that’s it (I’m not even sure if that’s on the FOG Server or where it’s looking to be honest…)

  • Moderator

    @george1421 Rob, I know this a bit confusing to setup because FOS runs linux it can only leave things in the right spot for windows to find them when OOBE starts. Once everything is in the right spot windows will go, Oh I know what to do with that and process it.

    I think through this whole thread, you never posted the target system OS. That may be important if the setupcomplete.cmd file is never really executed. You can have the setupcomplete.cmd file echo a value into a text file to prove if the batch file is actually running as a debugging step if needed.

  • Moderator

    @Tom-Elliott No fair giving Rob the answer. Shame on you!!

    Hint: You learn more from your mistakes than your successes.

  • @RobTitian16 You guys must remember. The scripts are running at the Client’s Scope.

    Meaning, the check for the msi file is not going to work. Why?

    The client (during imaging) does not have the “/root/trunk/packages/web/client/FogService/Fog Service Installer.msi” file on it. That (from what I can tell) is the location for the file as it sits on the Server when you run updates?

    You might just simplify this and add the msi directly to the images/postdownloadscripts folder.

    From the server run:

    cp /var/www/fog/client/FOGService.msi /images/postdownloadscripts/

    THe copy line would then switch to:

    (Changing _ with spaces of course)

    [[_-f ${postdownpath}FOGService.msi_]] && cp ${postdownpath}FOGService.msi "/ntfs/Windows/Setup/Scripts/FOGService.msi"

    Then your msiexec command would be:

    echo "msiexec.exe /i %windir%\Setup\Scripts\FOGService.msi /quiet USETRAY=\"0\" WEBADDRESS=\"${FOGIP}\" " >> /ntfs/Windows/Setup/Scripts/SetupComplete.cmd

    Just my two cents.