@Joe-Schmitt I can confirm printer-management is working flawlessly with the new client-version.
Printers are assigned correctly, setting default printer and renaming printers is working.
Only thing I didn’t test yet is if changed config-files are recognized.

I also appreciate a lot the new powermanagement module! This is really awesome!
Thank you so much, you and the other devs do a really great work!

I agree with @Wayne-Workman , meanwhile you could use setupcomplete.cmd as a workaround.
Do the following steps:

• Before Sysprepping disable Fogservice as described here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

• Create a file setupcomplete.cmd in C:\Windows\Setup\scripts and put your code inside

• Add the lines
  sc config FOGService start= auto
  net start FOGService
  after your code

setupcomplete.cmd is called by windows after setup is finished. As the fogservice is disabled, it can’t interrupt your script.
The last two lines enable and start the service.

@Wayne-Workman OK, I thought about installing the fog client after imaging by calling the msi-package from setupcomplete.bat, but this way is even easier.

I can confirm this working for me.

Thank you!

@Wayne-Workman Maybe i’ve got the clue. I too have a blanked settings.json file.

The windows eventlog shows an unexpected shutdown at 14:17:56

Windows Explorer shows, that settings.json was last changed at the same time

So I guess the file was opened to get updated while windows crashed.

@Wayne-Workman setupcomlete.cmd has to be placed under C:\Windows\Setup\scripts in the master system.
As the name indicates, the script is called by windows just after setup has finished.

Btw. l set the Fog service to delayed start, ie I put
sc config FOGService start= delayed-auto
into the script.
I don’t know, if this is really necessary with the new fogclient, but it doesn’t harm.
Reason for this is i’ve got some computers which require delayed start with the legacy client (afair network doesn’t come up fast enough)

@Tom-Elliott I’ve got the same problem (on ubuntu 14.04 and fog 1.3.3)

Here is the fog.log 0_1484747088387_fog.log

And error.log 0_1484747149856_error.log

@george1421 Thanks George, using net start seems to work.
@Scott-B The fogclient is included in the Image as this is the way I do it in my Win7-Images without problems.
As for now I’m fine with George’s solution, but I keep your tip in mind if other problems may show up.

I’ ll try that. But when fogservice renames the client and joins to domain it causes a reboot too, doesn’t it?

I’m building my first win10-Masterimage.
I try to deploy win10 pro x64 v1709 including FogClient following the instructions in the wiki
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

The reboot command

shutdown -t 0 -r

breaks windows setup. Placing the command in unattend.xml doesn’t work either.

The reboot command in setupcomplete.cmd leads to the following error page

It states that windows isn’t ready yet but might be working after applying an update.
Rebooting now causes windows to create a new user and (i suppose) again calls setupcomplete.cmd which again interrupts setup completion and thus leads to a boot loop.

The installation can be forced to complete by changing some registry values without any further issues (see https://miriamxyra.com/2016/04/14/registry-hacking-against-sysprep-errors/).

So it seems that setupcomlete.cmd is called a bit to early in the setup process, thus the reboot command prevents setup to finish.
Does anyone know a way to reboot windows safely after windows setup is finished?

@Tom-Elliott Installing working-brach 1.3.4 fixes the error. There are no more errormessages in the apache error.log, fogclient is working again.

Thank you, Tom

@Tom-Elliott Of course you’re right, i didn’t read the errormessages carefully enough.
In the apache-log the message changed from

[Wed Jan 18 22:31:45.800312 2017] [php7:error] [pid 12380] [client 172.16.10.5:58412] PHP Fatal error:  Uncaught Error: Call to a member function getDispVals() on null in /var/www/fog/lib/client/displaymanager.class.php:32\nStack trace:\n#0 /var/www/fog/lib/fog/fogpage.class.php(2787): DisplayManager->json()\n#1 /var/www/fog/lib/fog/fogpage.class.php(262): FOGPage->requestClientInfo()\n#2 /var/www/fog/lib/fog/processlogin.class.php(57): FOGPage->__construct('')\n#3 [internal function]: ProcessLogin->__construct()\n#4 /var/www/fog/lib/fog/fogbase.class.php(391): ReflectionClass->newInstanceArgs(Array)\n#5 /var/www/fog/management/index.php(29): FOGBase::getClass('ProcessLogin')\n#6 {main}\n  thrown in /var/www/fog/lib/client/displaymanager.class.php on line 32

to

[Wed Jan 18 22:48:20.808860 2017] [php7:error] [pid 12381] [client 172.16.10.5:58589] PHP Fatal error:  Uncaught Error: Call to a member function isValid() on null in /var/www/fog/lib/fog/host.class.php:694\nStack trace:\n#0 /var/www/fog/lib/fog/host.class.php(735): Host->_setDispVals()\n#1 /var/www/fog/lib/client/displaymanager.class.php(35): Host->getDispVals('width')\n#2 /var/www/fog/lib/fog/fogpage.class.php(2787): DisplayManager->json()\n#3 /var/www/fog/lib/fog/fogpage.class.php(262): FOGPage->requestClientInfo()\n#4 /var/www/fog/lib/fog/processlogin.class.php(57): FOGPage->__construct('')\n#5 [internal function]: ProcessLogin->__construct()\n#6 /var/www/fog/lib/fog/fogbase.class.php(391): ReflectionClass->newInstanceArgs(Array)\n#7 /var/www/fog/management/index.php(29): FOGBase::getClass('ProcessLogin')\n#8 {main}\n  thrown in /var/www/fog/lib/fog/host.class.php on line 694

I’ll install the 1.3.4 branch and report back

@michael_f In this thread @tmldale found that disabling the displaymanager gets the client working again, which i can confirm.

@Tom-Elliott Unfortunately this doesn’t fix the problem. Error-messages in both log-files remain the same.

@Tom-Elliott I’ve got the same problem (on ubuntu 14.04 and fog 1.3.3)

Here is the fog.log 0_1484747088387_fog.log

And error.log 0_1484747149856_error.log

@Wayne-Workman Maybe i’ve got the clue. I too have a blanked settings.json file.

The windows eventlog shows an unexpected shutdown at 14:17:56

Windows Explorer shows, that settings.json was last changed at the same time

So I guess the file was opened to get updated while windows crashed.

@Joe-Gill As Joe Schmidt says, maybe the share is not setup correctly. Nevertheless I would try the following, costs you 5 minutes:

• put the unzipped files to the share

• figure out the path to the inf-file and set the path in printer-management dialog, Printer Config File can be left blank, the other settings should be fine
  

• Assign the printer to a client and see, if it gets installed. If not, check fog.log