@psyfer9983 since editing the Registry can be done via Linux, you could just add another boot option for a live ISO that contains a distribution with a registry editor pre-installed (or install it manually).

@Wayne-Workman thanks for pinging me about this. @88fingerslukee I’ll need to reproduce this issue before being able to properly address it; hopefully it should not take long.

@hanz said in RC10, client checkins not working correctly.:

11/21/2017 4:16 PM Service Sleeping for 4823 seconds
11/21/2017 5:11 PM Main Overriding exception handling

Could you elaborate more on the issue? That log indicates the client was aborted and started back up during its sleep cycle (which should have been 80 minutes). Was the machine abruptly shut down? Are there any Windows Error Logs about the client?

Fixed, thanks for reporting.

@Brian-David alright, thanks for testing. This will require a bit more work than I was hoping for it seems.

@Jay-Bosworth hmmm that is strange then. So its running and not logging? New client logs are appended to the end of the fog.log file.

@Jay-Bosworth you mentioned you’re using sysprep. Did you follow the client instructions for sysprep? We need more information to help solve this issue https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep
. The fact that the client isn’t logging indicates that the client didn’t start. The sysprep mis-configuration is the most likely cause. Regardless, at this point this is likely just an image configuration issue.

@andreiv A quick comment:

Why use an external tool, when the built-in one works just fine?

There are situations where the client is desired over sysprep when joining the domain, such as when you want computers to have the same hostname they have in FOG, and automatically take care of renaming the machine if you change the name in FOG. The client can also deploys software after imaging to help keep images smaller. Now if you’re in an environment where you don’t use the client (no snapins, printer management, hostname, …) then the sysprep unattended file is absolutely the way to go.

TL;DR: The client should be responsible for managing domain bindings if you want to use FOG as a management solution for software, printers, user tracking, and hostname. If you dont want the client, then sysprep unattended work just fine.

@Jay-Bosworth please post the contents of the ‘C:\fog.log’ file on the computer trying to join the domain.

@Brian-David thanks for the logs, could you try installing a new nightly build? Steps are as follows:

1. Uninstall the client on a computer
2. Under the computer’s host page in the fog dashboard, hit Reset Encryption Data
3. Download and run: https://build.jbob.io/Client/nightly/11-13-2017-pci-compliance-01/SmartInstaller.exe
4. Restart the computer

It will likely still fail, but it should be a step in the right direction.

@Brian-David could you test this build https://build.jbob.io/Zazzles/nightly/PCI-Compliance-01/Zazzles.dll

To test:

• stop the client: net stop fogservice,
• replace C:\Program Files (x86)\FOG\Zazzles.dll with the file I linked to
• start the client : net start fogservice

And then monitor the client logs / behavior for any more issues.

Ticket: https://github.com/FOGProject/zazzles/issues/24

@george1421 @Wayne-Workman when client installs, it sets the service to auto on boot, but does not start. A reboot is required to fully initialize the client on Windows.

As for detecting sysprep, while it can be done, it requires a significant amount of work and research to be done properly, to the point where the cost outweighs the benefits given the current backlog. Especially considering that there is a working, simple, solution in the wiki. I agree that it would be nice, but we just don’t have the time to do it right now.

@avaryan said in Service Fog Client:

I believe the latest SmartInstallers have the FOG Service start type set to manual by default.

They default to auto start

@zago123, @Psycholiquid is correct about not disabling the client being problematic. Failing to do so causes the client and sysprep to both try and manage the computer at the same time, causing many conflicts. See https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@Wayne-Workman as I said,

Obviously the fields I picked were completely arbitrary and some testing may need to go into it to pick the best identifiers.

and as Tom said, this is just brainstorming how to best identify hosts; nothing is set in stone.

Also, for the reasons you stated, hdd and ram have a lower weight in the fuzzy search; but they are still important metrics.

As for the motherboard being changed out, that’s essentially saying you have a brand new computer, not much we can do about that. But even then, the fuzzy search would be able to suggest a couple hosts that are more likely than the rest. That would allow FOG to cooperate with fog admins; if a host has been changed greatly, FOG can prompt the user to select which host it is, and update its metrics. The point of a fuzzy search is to handle most changes in a host gracefully. There will always be extremes.

@george1421 @Sebastian-Roth this is a very good conversation to be having. FOG 2.0 was looking at system uuids to identify computers, but for the reasons you stated, that wouldn’t work very well. Thinking out-loud here, maybe these points are worth considering:

• There is no 1 single we can rely on as you showed in your original post, and some derived value based on client information may be the best route to go.
• A static key derived from values may not be the best idea. Instead it should be a weighted component comprised of several fields. For example, one could think about it like so:
  • UUID: .4
  • Primary MAC: .2
  • Motherboard asset #: .2
  • Hard drive asset #: .1
  • Ram/CPU information :.1

For each field that matches, a score gets increment by that amount; the host with the highest score, and above some threshold, gets selected/matched (essentially a fuzzy search). This provides some tolerance against machine’s hardware being upgraded, or portable network adapters being used. Obviously the fields I picked were completely arbitrary and some testing may need to go into it to pick the best identifiers.

@alfredo-the-pasta you may want to try retrieving the success state of each cmdlet and saving it to a file:

So add $? | Out-File C:\powershell-log.txt after each command (or something alike)

@Alfredo-the-Pasta are both exceptions failing to add or just the network drive?

@Vinay https://wiki.fogproject.org/wiki/index.php?title=FOG_Client has everything you need;
for ubuntu: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Debian_8.2B.2C_Ubuntu_13.10.2B.2C_and_derivatives

The client will not manage domain bindings for linux. You can use a bash script Snapin for that though.

@matthieu-jacquart you should be able to update your signature now.