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

@gordon-taylor The binary might have changes (refind.efi) though we don’t know what changed (we don’t write the refind program stuff.)

I’ve made scan_delay = 0 the default when 1.5.1 releases.

Hi,

something additional, today i registered a host, enabled domain join and a snapin like i always do. deployed the image and was wondering why the host hasn’t joined the domain. After checking the hosts settings i could see that joining domain wasn’t saved for this host. enabled it again and the host joined the domain and rebooted.

I don’t know if this is related but i have the feeling it could.

Regards X23

@wayne-workman Just noticed I put those settings on a different scope.

Everything is working now.

Thanks!

@george1421 Thank you very much for your time George. I’ll try today and back to you asap

@dpotesta50 said in Question About Windows Licensing:

I see the area you’re referring to but wouldn’t that be the product key just for THAT particular one machine? The same key won’t activate every machine I pull that image to, correct?

Correct, and if all you have are individual licenses for individual machines, this is the ONLY legal way you have. If you had a MAK key, you could use groups to apply that to many hosts at once - but you don’t unfortunately, you just have Pro keys.

Here’s what I did for 100+ laptops, you need two people for this. One good at typing and listening, one good at reading and speaking clearly. One reads keys, the other one types them in. Yes, it will suck, better to get it over sooner than later. Also you’ll definitely want to backup your database when you’re done so you don’t have to do it again!

@fox134 Well lets hope you don’t have an ipxe.exe in there…

The client gets its booting information from (the) dhcp responsible for assigning an ip address to the target computer. So if you want the target computer to use a different boot file then you might update dhcp options 67.

Now with that said, from your OP you say that FOG is giving out the IP addresses on a dedicated imaging network. So if you want to change the boot file, you will need to edit the dhcp config file on your FOG server.

To see what you config file looks like, you can review this example: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

You will see for arch 7 and 9 it calls out ipxe.efi. You can replace that with maybe snponly.efi or any of the other efi files. Then you must restart your dns server. On ubuntu you would issue the command sudo systemctl restart isc-dhcp-server to restart the service.

@jfulton Try putting a dumb switch (unmanaged mini-switch) between the target host you’re working with and the rest of the network, see if it makes a difference or not. If there’s a difference, we have additional steps for you on how to fix it.

The problem seams to have self resolved. This can be closed. FYI, nobody changed any settings. It just started pulling from the correct node on its own.

One GB. Is small because in this partition is the WINPE.

/dev/sda4 : start= 102758400, size= 2095104, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EDED91DC-7BDE-4F7B-B502-B57A6C90EF 30, name="Basic data partition"```