Posts made by michael_f

@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

@Joe-Gill Can you verify that a normal user can access the share with windows explorer without providing credentials?

@Joe-Gill afaik you have to grant access to the “everyone”-group not anonymous. Don’t forget to set permissions in both sharing and security-tab.

I’m wondering, why you install the printer with a snapin? If you can unzip the driver-package, you can put the unzipped files to your share and point directly to the appropriate inf-file instead of ntprint.inf in the fog printer-settings.
I’m using this method with different epson models and a generic driver. As the printer-model is only detected automatically if the printer is online, I’m using config-files to prevent problems.

Greets,
Michael

@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!

Neu-Ulm, Germany

@Tom-Elliott Can also confirm groups are working againg.
Thank you Tom!

@michael_f The schema update is broken,the table groupMembers is missing in my DB

@Wayne-Workman Same problem here: since I upgraded to 7853 all groups are empty and no client can be added.
Also existing groups with members have been emptied.
Apache error log doesn’t shown any errors when attempting to add clients.
Updating to lastest trunk didn’t solve the problem.
Tried to delete all groups and set DB-Schema as Tom Elliot suggested. When doing a schema update i get the error message

PHP Strict Standards: Only variables should be passed by reference in /var/www/fog/lib/pages/schemaupdaterpage.class.php on line 48, referer: http://172.16.0.231/fog/management/?node=schema

Sorry for the delay, I had another urgent problem.

@Jbob said in Printer Management issues:

Can you post your settings.json file (Will be in C:\Program Files (x86)\FOG\, or no (x86) if this is a 32 bit machine). Also, is the printer which is supposed to be default on the machine? Or is it the one failing to add? Can you also upload your .fog_user.log file? It will be located at C:\Users\<USER_NAME>\.fog_user.log

1_1464218325051_settings.json
0_1464218325050_.fog_user.log

The default printer alias in settings.json is the desired one.
The printer is on the machine, renaming fails but the original printer stays on the machine.

And third issue, when renaming the printer alias fogclient fails to change it.

Can you shutdown the service (net stop FOGService), and then run this tool: https://github.com/FOGProject/fog-client/releases/download/0.10.6/PrinterManagerHelper.exe . Is the new alias present in the tool’s listing? And is the old one gone?

Meanwhile renaming the printer is working and therefore the new alias is shown and the old one gone, as it should be.
Maybe removing the $s as Tom Elliot suggested did the trick, I also noticed that the userclient is crashing sometimes.

Btw. I’d find it helpful to put the PrinterManagerHelper.exe under http://<fogserver>/fog/management/index.php?node=client as I recently had some problems finding it.

OK, I updated to 7853, behaviour is all the same.

Hello,

i’ve got some issues with printer management:
Similar to this post https://forums.fogproject.org/topic/7033/unable-to-set-default-printer the default printer is not set correctly.
Only obvious difference to the mentioned post is, that I’m using TCP/IP Port Printers not Network printers.
Fogclient 0.10.6 and Fog userclient are running, fog version is 7821.
It tested a bit (adding printers all at once or step by step, deleting and readding) and it seems that always the last added printer gets default regardless of the settings.

Another issue is that changes in the printer settings are not recognized. I added a printer config file, which works perfect on clients with newly assigned printers but doesn’t effect clients which got the printer assigned earlier. The Fogclient doesn’t seem to notice the changes.

And third issue, when renaming the printer alias fogclient fails to change it. Fog.log shows the following message which is repeated over and over until I remove the printer from the client in the WebGUI and reassign it

------------------------------------------------------------------------------
--------------------------------PrinterManager--------------------------------
------------------------------------------------------------------------------
 25.05.2016 22:30 Client-Info Client Version: 0.10.6
 25.05.2016 22:30 Client-Info Client OS:      Windows
 25.05.2016 22:30 Client-Info Server Version: 7821
 25.05.2016 22:30 Middleware::Response Success
 25.05.2016 22:30 Printer Removing printer: Drucker-Lehrerzimmer
 25.05.2016 22:30 PrinterManager Adding printers
 25.05.2016 22:30 PrinterManager Kopierer-Lehrerzimmer already exists
 25.05.2016 22:30 Printer Attempting to add printer:
 25.05.2016 22:30 Printer --> Name = Printer-Lehrerzimmer
 25.05.2016 22:30 Printer --> IP = 172.16.5.1
 25.05.2016 22:30 Printer --> Port = 172.16.5.1
 25.05.2016 22:30 Printer --> File = \\ads\fogpublic$\Epson-WF-5190DW\E_WF1KNE.INF
 25.05.2016 22:30 Printer --> Config = \\ads\fogpublic$\printerConfigFiles\wf5190.dat
 25.05.2016 22:30 Printer --> Model = EPSON WF-5190 Series
------------------------------------------------------------------------------

All the problems can be worked around quite easy and changing the configuration of a printer after pushing them out is maybe not a good idea at all, but maybe the fogclient doesn’t work as expected here.

Regards
Michael