Thanks @george1421 , the reason I wasn’t using sysprep oobe generalize was because it was causing my system to lock up at “Please Wait”. I found that un-joining and re-joining it to the domain “generalizes” the system enough so that everything works for us.

Anyway - I re-built the image and integrated the FOG Client (agent) into it. Now it appears the domain joining is working. Bad news is I’ll need to do another round of manual deployment, but that is the last time - after that I will have a full hands off deployment system.

Thanks for your help so far!

Your post is a bit unclear. Are you having an issue capturing the image or deploying the image?

When you say it reboots before its ready to deploy, is there an error message? Is this reboot happening in FOS image push or in/during WinSetup/OOBE? if the error is in FOS then capture a clear screen shot of the entire screen with a mobile phone and past the results here. The context of the error is almost as important as the error message itself.

@george1421 thank you for your responses. The timeout is fine the way it is, as long as I understand how it functions. Just need to turn it up while I join 100 clients to it. 😉 Though, since you say it’s probably a layer 8 problem on the group based multicast, I’ll try to find the time to run a few experiments on my side and see if it’s now working. I have a fairly simple network (air gaped single subnet educational lab), so that shouldn’t be the issue.

The repeating multicast would be handy but, as you say, there are certainly potential issues there as well. Again, as long as I understand the mechanic I can work with it! Thanks again for your answers(and all your help in the past as well).

Philip

Yes, what you say helps. I am new to fog and coming from using other device management programs so I am learning how fog works. It’s just a little new way of thinking for me right now. Not that this is a bad thing, I’m truly liking how fog works.
Thank you

My recommendation is as always when jumping OS versions like this. Spin up a new FOG server and then migrate your database and raw files. This does two things. First it gives you a clean OS and a clean install of FOG to build from. Second, if something happens with your upgrade your fog imaging is down. Yes I know you can always restore from a snapshot, but that still doesn’t address the first issue of having a clean OS (not upgraded).

Here is the process to migrate your fog install to a new server. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG The only gotcha is don’t change the IP address of your new FOG server after FOG is installed (you can but its a bit of a pain to do so). With your new FOG server at a new IP address you will also need to update dhcp to point to your new fog server. On a plus note you can always fail back to your old fog server by just resetting dhcp back to your old fog server’s IP address.

@gaconvn1106 How is this related to FOG and what’s exactly your question?

muchas gracias!!! me servira de mucho y voy a realizar pruebas

@lambdacalculus Typically, this error is not caused by accessing certain pages… Generally speaking, your database connection is totally busted, or is intermittently working. And when it’s intermittently working, it’s usually load related problems. I have some questions for you:

How many hosts do you have running the fog client? How much ram/cpu do you have allocated to your fog server? What OS & version is your fog server running? What version of FOG are you running? Give us a screenshot of the output produced by the linux top command on your FOG server while the problem is occurring. Check for a duplicate IP address concerning your FOG server’s IP address using these instructions.

@george1421, great stuff! How couldn’t I see this before?
lol!!!
Well, I reinstalled it, and already applied what Elliot said. Let’s see if it will take things easy. Thanks!!

The intent of the following tutorial is to show you how its possible to use FOG to pxe boot a live environment with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
Again creating a disk-less boot environment is not the intent of FOG, its just a proof of concept.

@ylber you can get the code from from working_dev branch in git repository.

@agray said in Issues with copying software configs?:

here are 13 people that will be using that PC. All accounts where set up, including IBM Notes, on the PC before Cloning.

Was this system sysprep’d? I know Lotus Notes (been a Domino admin on and off for almost 10 years). LN creates is config file in the user’s home %appdata% directory. Its possible that sysprep is cleaning out these directories where LN lives. I know post install you can just copy the notes data directory over from one computer to the next without any problems or needing to reactivate the account. With Notes 7, we were running the notes data directory from the user’s home drive without issue. That allowed users to roam between computers without needing to mess with local directories. Since then I understand LN now supports roaming profiles, but I digress.

@Wayne-Workman Interesting, I found our problem was the initial setup of the Ubuntu server that hosts FOG was set to allow auto-updates. This will come in handy for future installs, thanks!

@anhphuong all assigned to that host. i agree that being able to select what snapins you want at the time of deploy would be nice, but the logic is tricky and there hasn’t been a lot of demand for it.

@meobeou Hi, i am using it and it‘s easy to use, google for create pushbullet api key, create it in your pb account and paste it into the fogs pb config. After that it should work.

Bild Text

Bild Text

Easy 🙂

Regards X23

@sampsont I guess you could come up with a solution where you add our FOS linux system to your clients and boot from it. I don’t know anyone who’s done this but I reckon it’ can be done. Surely Ubuntu 12.04 had grub installed. So you’d copy bzImage and init.xz to the clients and modify grub.conf to boot exactly that as first boot option. The problem I see is that you only have one go (old Ubuntu and FOS being wiped from disk as soon as imaging starts) and if things do wrong…?!

And you’d need to prepare all the clients so why not just using clusterssh and do a normal dist-upgrade 12.04 - 14.04 - 16.04 - 18.04? Probably not trouble free either but not much involved to try it out with the first batch.

What kind of hardware do you have? As George said, some manufacturers like Dell and HP might provide command line tools that let you change boot options.

Would be real interesting to see if FOG would image properly while wiping itself from the disk. Should work as it is loaded to RAM but I never tried that before.

@Wayne-Workman Thanks for the response. I ended up renumbering the image name to include 01. through 14 and that did sort them. I appreciate the quick thinking and that fixes my issue!

@vishalthejigsaw What’s the end-goal here? Snapins? And you should think about SnapinPacks. Put all your stuff into one SnapinPack and then run that on a schedule. Documentation here: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

With fog you would set the image type to “multiple disk resizeable” and pick “all partitions”.

Thanks kafluke! This was just what I was looking for!

For anyone else looking:
To change selinux to premissive permanently in CentOS 7 edit /etc/selinux/config. Change “SELINUX=permissive” the write out.