@amadrigal Just want to bring up my initial thought about maybe OpenVZ not being able to properly handle multicast in the first place. Can you try setting up another test FOG server as KVM instance just to rule out that possible issue!?

@george1421 Oke! Say it when you found something.

@msi Never mind. After I re-ran the installation from the Git. Problem solved.

Is there a way to reduce how often the fog node’s are checking back into the master server’s mysql?

@kafluke said in How do I schedule FOG image replication for after hours?:

@george1421 thank you so much! These are even the exact times that I needed to set the job for! You da man! This can be marked resolved now.

That is why I get paid the big bucks… oh wait… never mind.

@tesparza the file you are running doesn’t appear to be the installer. It appears to be a self extracting archive that contains the installer. Once you give it a path, it should place all of its install files there, including a DXSETUP.exe, which would accept /silent.

My suggestion is to either find a different version of the installer, such as an MSI, or to take the extracted files and create a snapinpack out of them.

Just going to add in here that when I want to see how busy my HDD’s are during tasks, I use nmon. Can run as normal user and press d to view disk activity percentage. Very friendly to a newb. Press n to also view network stats and c to view CPU as well.

If I was you, i’d bring a computer over to the same physical switch that your FOG server takes the image on. See if it sustains a better speed or not to determine if network routing is to blame or not.

@george1421 That is sent to you. Let me know what you find.

Thanks,

Just for an additional bit of information. Your reference/golden image should never be connected to AD before you sysprep it. Even if it was connected to AD, then removed from AD before system. The first time you connect a computer to AD the target computer will be tattooed causing every image created from that golden image problems down the road.

You can mark this as solved.

@tom-elliott said in Can't login to FOG web Interface:

@msi when you login guess what page it automatically takes you too?

Hi,
Make sense… Please close the discussion with satisfaction. Just to recap, below solved the problem for now. Hopefully, newer version will solve all the problem, including delays.
@msi said in Can't login to FOG web Interface:

[root@caor-fogmain ~]#sudo -i [root@caor-fogmain ~]#yum -y install git [root@caor-fogmain ~]# sudo -i [root@caor-fogmain ~]# cd /root [root@caor-fogmain ~]# git clone https://github.com/FOGProject/fogproject.git [root@caor-fogmain ~]# cd fogproject/ [root@caor-fogmain fogproject]# git checkout working-1.5.1 Branch working-1.5.1 set up to track remote branch working-1.5.1 from origin. Switched to a new branch 'working-1.5.1' [root@caor-fogmain fogproject]# git pull Already up-to-date. [root@caor-fogmain fogproject]# cd bin/ [root@caor-fogmain bin]# ./installfog.sh -y

@Paulo-Guedes See update here: https://forums.fogproject.org/topic/11207/error-could-not-open-inode-xxxxxx-through-the-library

that worked amazingly thank you very much!

@tiagoluz

Yes, you can manually rsync the images over. I’m doing the replication between nodes so my coworkers who know nothing of Linux can synchronize images across FOG installations without asking me to do it.

The active snapin tasks appeared empty, but when I typed the hostname in the search it showed up as queued. I deleted that queue and ran:

DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");

in mysql for good measure. Everything appears to be working now.

Thanks for your help and all that you do!

@fabzster The log file did not successfully upload, please try again.
Your script is most likely failing because the FOG Client runs Snapins as the SYSTEM user, whereas when you’re manually running your script, it’s being ran as Administrator. I would suggest you add logging to your script so you can see what line it’s hanging on.

Gotchya, I will switch back to that. Thanks Joe!

@callumhird said in Best way to utilize FOG_1.5.0 on LAN:

so we can install all the required software from our file servers

I would challenge you, that you don’t “need” to connect to the domain to map a drive to your file server to install software. If there are applications that require AD credentials to install, then those should be installed post imaging via a snapin or some other software deployment tool like PDQ Deploy.

The only software that I “must” install after imaging is our antivirus software because that application creates a unique GUID when its installed to identify the machine to the AV console. its not possible to clone a system after AV is installed because of this. But most all other applications can be installed before imaging without AD rights.

@cml Better mark this as solved. Loved it!

@themcv said in Image upload & deploy taking a long time:

@brad-schumann Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off 😄

manage-bde -status 😄

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

Tagging this for the #wiki