I have to say, FOG has been quite solid lately. I’ve been on RC10 working since it came out and I haven’t found any bugs in my environment. Keep fighting the good fight developers. I live vicariously through you guys since I don’t have one iota of programming skill!
Best posts made by fry_p
-
RE: FOG Activity - Status
-
RE: FOG Unresponsive under "heavy" load
@george1421 We will be doing an exorbitant of lab re-imaging this summer, so testing will not be an issue. I will do this and certainly report back. Probably in the next few days.
-
RE: Issue joining domain & activating Windows after deployment
Since setupcomplete is running after the image, I am assuming this was not an OEM version of windows as it wouldn’t automatically run at all. It seems to be hanging on part of it. My recommendation is to start simple. According to the wiki, the setupcomplete.cmd file should contain the following:
sc config FOGService start= auto shutdown -t 0 -r
I see you have some customization for your environment in your current one. I would omit those for testing.
Please also try to reset the encryption data on the host. This can be done from the host management page on a yellowish button at the top.
If all else fails, please post the contents of your fog.log from a pc that is not automatically rebooting.
-
RE: FOG Client 0.11.18 Officially Released
@Sebastian-Roth and anyone else who worked on this, great work on continually improving the client that some of us rely so heavily on!
-
RE: Kernel Issue
@george1421 I can get a screenshot to you on Monday, but I believe this is just simply an ordering issue on the Web UI in 1.5.5. I went to update the kernel, got the same message, and realized I installed 4.3, which was at the top of the list of available kernels. A lot of users including myself are used to it being ordered by newest to oldest. I had to go down near the bottom of the page to find 4.19.1.
-
RE: Associate all new hosts with Snapin
@george1421 I think I misunderstood the meaning of persistent groups off the bat. This is certainly something that can help me with my use case. I am a little embarrassed I didn’t know about this a long time ago to be honest. I got scolded for remote work this holiday weekend already, so I will look into implementing this on Tuesday if it isn’t busy. Thank you for the info!
-
RE: Issue joining domain & activating Windows after deployment
@fry_p said in Issue joining domain & activating Windows after deployment:
If all else fails, please post the contents of your fog.log from a pc that is not automatically rebooting.
Doing this will help our friends diagnose the issue. You can find it either at
C:\fog.log
or atC:\Program Files (x86)\FOG\fog.log
depending on where you chose when you installed the client. -
RE: Filesystem check error after capturing W10 image.
@luis-acacio said in Filesystem check error after capturing W10 image.:
I’ve tried to follow these tutorials but they are missing a lot of information… they’re just awful. Specially the one in the wiki.
I feel as if I may need to clarify something for you. I understand you may be frustrated, but the FOG Project is an open source solution that is not only free and designed/maintained completely by a small group of very intelligent volunteers, but also has top notch support on these forums that rivals paid support contracts.
Admittedly, the wiki is outdated. This is because these few developers are working on continuously improving fog and running a full fledged helpdesk for free, so it is understandable that the knowledge base takes the back burner. I assure you that every issue I have ever posted about in these forums was solved in an appropriate time-frame.
I don’t speak for the project and the only way I am involved in it is solely as a user, but I hope you now have some insight into the reasons behind the shortcomings of the wiki and I hope your issue is resolved soon and to your liking.
-
RE: Issue joining domain & activating Windows after deployment
@ckasdf I am seeing some authentication issues in the log. If you did migrate from an old server to a new one, please take a look at this article from the wiki https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server
I believe you can follow the first set of instructions (copying the ssl directory from the old server to the new one and rerunning the installer). I would strongly advise against recreating the CA (second set of instructions in this part of the article) because it will essentially break all existing fog client installations.
If you do not have access to the old server, I think someone else may have to help as that is beyond my knowledge. -
RE: FOG Clients Stop Working
@UWPVIOLATOR My colleague and I have a PS script that at least checks if the service is running. It exports the results into .csv file. It can at least give you an idea of how many and which ones need fixed. (I sanitized this a bit, so put in your own stuff where needed)
ForEach ($Computer in (Get-ADComputer -Filter * -SearchBase "OU=XXXXXXXXXXX,DC=MYDOMAIN,DC=COM")) { $ComputerName = $Computer.Name If (Test-Connection $ComputerName -Count 1 -Quiet) { $FogService = Get-Service -Name FogService -ComputerName $ComputerName -ErrorAction SilentlyContinue If ($FogService) { Write-Output "FOG is running on $ComputerName" | Out-File C:\Scripts\FOG.csv -Append} Else {Write-Output "FOG is not running on $ComputerName" | Out-File C:\Scripts\FOG.csv -Append }} Else {Write-Output "$ComputerName is Offline" | Out-File C:\Scripts\FOG.csv -Append} }
From there, I am pretty sure you can just add affected PC’s to a group in Active Directory and map a GPO to run the following batch script (Note I sanitized a bit, so insert your own stuff where needed):
msiexec /q /x "PATH TO FOG CLIENT MSI" msiexec /i "PATH TO FOG CLIENT MSI" /quiet USETRAY="0" HTTPS="0" WEBADDRESS="FOGSERVERIP" WEBROOT="/fog" ROOTLOG="1" net start FOGService
-
RE: Issue joining domain & activating Windows after deployment
@ckasdf I realized I was only looking at the beginning of the log and replied before I read enough. So it looks like it is authenticating properly as of 5/9. Let me look for a few moments, but chances are you followed proper protocol when you migrated.
-
RE: Issue joining domain & activating Windows after deployment
@ckasdf Please do the following for me. Log into the FOG web gui and search for the host. Select the host and click the “Service settings” tab. Please take a screenshot of this so I may compare to my setup.
Please also, while in the web gui, click on the three gears icon (Client settings) and pick the task reboot tab. Please let us know which boxes are ticked.
Finally, please click on the wrench (FOG Configuration) and click on FOG Settings on the left column. Scroll down to the FOG Client - Task reboot heading and click on it. Please let us know what is checked there.
-
RE: Issue joining domain & activating Windows after deployment
@ckasdf This is very strange you are getting an “Access is denied” because setupcomplete.cmd runs in the local system permission context. This is indeed the issue I think. So in my eyes, the hostname changer in the fog service is running fine, but the service is failing to start with the setupcomplete.cmd script thus causing your issue. The screenshots that I asked for pretty much mirror my setup.
So unfortunately I myself cannot recommend anything but to rebuild the image as it seems the local system account is borked. @Sebastian-Roth @Wayne-Workman @george1421 may have other ideas because they are actual wizards.
-
RE: Issue joining domain & activating Windows after deployment
@Sebastian-Roth I used 1803 up until last week. We are making new images with 1903 and the behavior is still normal for me. Very strange
-
RE: Windows 10 Image constantly trying to join domain after join.
@SKasai From the fog.log excerpt you posted, this appears to be regular behavior. I checked a log on one of my clients, it matches exactly. Correct me if I am wrong everyone, but I think the client checks to see if it is joined regardless of if it is already joined. This is only speaking to the fog.log message. It appears to me that the FOG client is successfully “talking” to AD as well judging by the “already joined” message.
May I ask what other behavior this is exhibiting? Is it trying to reboot to change the hostname endlessly? If not, and the only symptom is the log message, I myself would not worry too much about it as my clients also do the same. Others, please correct me if I am wrong!
-
RE: Adobe Acrobat Reader snapin not working
I have successfully gotten the exe to work by doing the following:
1 - Download the latest version of acrobat reader DC for your language and OS version here (this is important because it is the offline installer):
https://get.adobe.com/reader/enterprise/
2 - Compress the file into a .zip
3 - Create a snapin pack with the following content:
a - Choose the .zip you just created to upload
b - Change the file path from “MyFile.exe” to the name of the exe you downloaded earlier
c - Put the following in the Snapin Pack Arguments section:
/sALL /msi /norestart ALLUSERS=1 EULA_ACCEPT=yes
Here is a screenshot of my settings:
Then you save the snapin, and deploy away!
Please let me know if this works for you -
RE: MSI vs SmartInstaller
Sorry to necro this thread, but I also want to mention a certain use-case for the MSI. You can pass arguments using msiexec to install. This is useful for remote/silent installation. This has saved me in the past.
From the Wiki:
msiexec /i FOGService.msi /quiet USETRAY="0" HTTPS="0" WEBADDRESS="192.168.1.X" WEBROOT="/fog" ROOTLOG="0" Firstly, all options are optional. Here’s what they all do: USETRAY= defaults to "1", if "0" the tray will be hidden HTTPS= defaults to "0", if "1" the client will use HTTPS (not recommended) WEBADDRESS= defaults to "fogserver", this is the ip/dns name of your server WEBROOT= defaults to "/fog" ROOTLOG= defaults to "0", if "1" the fog.log will be at C:\fog.log, otherwise %PROGRAMFILES%\FOG\fog.log