@Seydoo did you follow these steps: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server ?
If you have completey copied over the snapins directory (including hidden files), then re-run the fog installer on the new server with the --recreate-keys flag present (this is all described in the wiki article).
@Seydoo uninstalling / installing the client requires additional steps (https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Reset_encryption_data). As for macs, if they are pending, then they do infact exist on that host (they could be tunnel interfaces, VirtualBox interfaces, or any other kind of virtual adapter),
Also be sure to check the fog.log to ensure that it is still the private key not found error, and not a new one now. Just because the client is still not authenticating doesn’t mean the underlying issue hasn’t changed.
Your original issue Private key not found is strictly a server issue. How did you copy over your installation to the new server? On fresh installs or upgrades this issue is not present, indicating its likely a permission issue from when you migrated the server, or something alike. @Tom-Elliott would be best equipped to tell you which files / permissions to check.
@Scott-Adams said in Computers not joining domain after password change:
I had thought about that as a work around, didn’t think that would be the actual solution though. Thanks @Wayne-Workman
@Scott-Adams You’d need to post the fog.log from a problematic host.
@jpaul said in network printers not coming in when imaging with fog 1.2.0:
ill not populate even after all the forced group policy updates per machine . Has anyone found the the problem might be with fog imagining or is it just something wrong with our group policies,
@jpaul it sounds like an issue with your GPO. Is there also a reason why you just started using 1.2.0? It’s fairly outdated and doesn’t support newer operating systems (like Windows 10) very well.
For anyone still having this issue, you can run this tool as Administrator and it will clean up leftovers from the legacy client (only run after you have uninstalled the legacy client): https://build.jbob.io/Tools/CleanLegacyClient.exe.
@Sebastian-Roth @Joseph-Hales theinvalid time comes from creating the user-cache, specifically the auto log out time.
The client logs show the error:
11/28/2017 1:40 PM HostnameChanger Logon failure: unknown username or bad password, code = 1326
So the credentials are not set correctly on the server. A couple ideas:
If you are sure both are correct, I can provide instructions how to use the client’s debugger to find the exact issue.
@TomcatKZN @Wayne-Workman that error just means the client hasn’t authenticated with the sever yet and doesnt have a token.
The real error here is 2018/01/22 21:10 Middleware::Response Private key path not found . Try rerunning your fog server install script. @Tom-Elliott would be of help debugging this issue here.
@tesparza this sounds like a server issue to me; the client is showing no indication that it was told to perform any power management tasks. To be sure, can you try the following steps on this problematic machine?
net stop fogserviceReset Encryption Data if its an optionfog: prompt, please enter these commands, pressing enter after each one:
middleware configuration server http://10.154.72.190/fogmiddleware authentication handshakedump cycle saveThe debugger should point you to a FOGCycle.txt file. This contains all the information the server tells the client, completely decrypted. Please post it here, after filtering out any sensitive data (such as active directory password).
To clean up:
Reset Encryption Data again on the host in the gui@tesparza nope! Basically, the client works by “locking” into the server. Once the client is locked in, no other program or computer can easily pretend to be that client. “Reset encryption data” removes the lock, and allows a new program to “lock in”.
So what I had you do was allow the Debugger to “lock in”, or become the FOG Client from the server’s perspective.
@tesparza Just a heads up, it may be a few days before I can get to this. I’m currently tracking down a severe bug on Windows 1709:
@tesparza the tool Wayne listed should be run a computer where you already have the desired printer installed.
Without any more information, my guess would be that the printer failing to add is due to the inf file being stored on a network share. I’d first try the generic inf file that PrinterManagerHelper.exe will point you to, as it should work. If it does not, and you need to use the network share, then you will need to ensure that the share has Anonymous read privileges for all computers. The client runs as SYSTEM, which causes some issues with network shares. Specifically, even if the machine is already joined to a machine, the client will not be able to access shares enabled for computers bound to a domain.
@tesparza did you run PrinterManagerHelper on a computer that has the printer already installed? It will give you all the field values, as sometimes even things such as Model aren’t what you think they should be. Did you also try using the generic printer inf the tool will point you to? It should work for the majority of printers.
@Wayne-Workman until we know more information its doubtful the powershell script will likely do anything to resolve his issue, as we do not yet fully know what it is. Based on the errors this seems to be a simple configuration issue for now.
As a note, the client log states that it has already attempted to configure the printer, not that it is installed. If a printer configuration fails to add once, there is no reason for the client to continue spamming your printer spooler every cycle unless the config has changed. If you scroll up more in the log to where the client first attempts to add the printer, you’d probably see an error message similar to what PrinterManagerHelper is giving you.
@blkeller what error does the client provide when set for http? Are you redirecting port 80 to port 443? Is the certificate on “https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crt” trusted by the computer? This definitely seems to be related to the SSL cert.
@msi We’d need the C:\fog.log from a computer that is running the Snapin and not completing
@x23piracy unfortunately it’s more than just the network not being up. The client interfaces with several different win32 api and depends on several other Windows services to even function. If the client starts up too early, it can actually start before those apis are ready, or those dependent services aren’t running. This causes a whole series of issues like failed runtime bindings.
The “big” thing here is that when the client starts too early, it can’t even log. It just fails to start, which means there’s a fundamental dependency missing, to the point where the client can’t even do basic things like logging. 0.11.13 was supposed to make the clients dependencies explicitly defined so this can’t happen, but evidently I missed a couple.
@adrien17 the autologout module is contained in a different, user-specific, log ~/.fog_user.log
However, my gut reaction is that you’re missing the needed dependency for Linux autologout: xprintidle. Try installing that via your package manager (or even use a snapin to automate it!) (src: https://github.com/fogproject/fog-client#autologout).
@Scott-Adams with 560 clients you will definitely want to increase the client checkin time. Right now it seems to be around 1 minute (the default).
It’d also be worth while switching to php-fpm instead of Apache’s mod_php, as its better suited for more heavy PHP usage:
The main issue with mod_php and Mpm Prefork is that every time Apache forks
into a new process (every new request) the entire PHP module and all its sub
modules have to be loaded into memory along with all your other data which
means you’re wasting a lot of memory on multiple copies of the same thing.
To get around the memory usage caused by loading php into every Apache
process is to use PHP as an external resource (PHP-FPM instead of mod_php) this
then also allows you to run Apache with MPM Worker which mean Apache has
a master process (now smaller as it doesn’t include all the bloat that comes with
PHP) that spawns a small number of child processes to deal with http requests,
CSS, Images, file downloads etc allowing for faster parallel processing.
Src and a good guide for scaling PHP and Apache: https://www.wirehive.com/wp-content/uploads/2016/09/Configuring-Apache-and-PHP-for-stability-an-performance.pdf
(Tom and I both use php-fpm in our development environments, so we know it’ll work fine)
@msi said in Snapin not running:
I checked the port 445. its open.
Then it’s likely just a DNS configuration issue: if the FOG server can’t resolve hostnames, then it can’t ping them. If you’d like help with that please open a new thread, though this is ultimately not a FOG issue, so it may be best to search other resources on how to configure DNS (assuming this is the issue).
@tesparza unfortunately exe arguments are not standard, and so that’s why we don’t have argument templates. Your best bet is to search for your programs name followed by “install arguments” or “silent install”. For example if you had an exe for Firefox and you wanted to find the arguments you would search “Firefox silent install arguments”.
In general, usually /s or /S would enter a silent install, but that’s not guaranteed.