Windows 10 Client 0.11.4 Windows Service

[Max Kern]

@Joe-Schmitt Sometimes 5 min, 10 min at some Clients longer(hours) but nothing under about 5 min

[Joe Schmitt]

@Max-Kern sounds like a bad windows configuration to me. This would not be caused by the clients code base. It sounds like your service controller is messed up or the fog service definition / dependencies are bad.

[Max Kern]

@Joe-Schmitt maybe, but on the machine with the ssd´s it work well(i have tested it 5 minutes ago with a deployment of 25 clients). Now one deployment with the start type “delayed-auto” it works on the clients with hdd, i will do a full deployment for the 20 Clients now and tell you if it works with this settings.

[Joe Schmitt]

@Max-Kern that also indicates an incorrect service configuration. I’m not denying that it could be a coding issue, but your issue fits a service configuration issue in every regard. None of the service controller stall prevention code base is being initialized, none of the eager JIT compiler response time minimizers are running, the offloaded worker threads aren’t kicking in, and the IPC bus isn’t initializing. This all indicates that the service controller is misbehaving.

[Max Kern]

@Joe-Schmitt with the delayed-auto option it works fine for the slow machiens, maybe there is a Problem with the configuration of the Service Controller (but why this is the only service and why on the other clients it work?). I think the Fog Services is start very early and waiting for dependence (i dont know which, so i cant say anything to it) maybe a network or somthing else, and at startup this dependence first must initialize befor it can go on, that would explain why this is working with delayed start of the service, because all dependence are loaded, this also will explain why it will start if the machine has loaded the gui and all other stuff.

[RLane]

Cross posting here:

https://forums.fogproject.org/topic/8206/0-11-4-rc4-ad-question/

Same issue I’m having. You marked it as solved, I’m assuming you just set the service to start as delayed prior to sysprepping and that solved it?

[x23piracy]

@RLane you should not use delayed-auto if so there is a race condition for breaking the image when deploying, for some machines you could have luck and for some maybe you will get an error.

In short when using OEM you can’t use SetupComplete.cmd without calling it by unattend.xml section firstlogoncommands.
If you are not using OEM you can use SetupComplete.cmd as normal but stay away from delayed auto.

@Tom-Elliott @Joe-Schmitt Could someone add this information to the wiki?
If OEM call setupcomplete.cmd via unattend.xml section firstlogoncommands
if no OEM use Setupcomplete.cmd as normal

Check here: https://forums.fogproject.org/post/74436

Regards X23

[RLane]

@x23piracy I’m not using OEM. I’m using a KMS key - Windows 10 x64 for Education. I had no issue with the same setupcomplete.cmd and unattend file with 0.11.2. After upgrading to the RC’s, it began to give me issues.

[Max Kern]

@RLane Hi,
Yes this worked for me very well on about 60 machines.
I put the delayed-auto into the SetupComplete an deactivate the Service like it says the wiki.

[Joe Schmitt]

I will look into this when I get a chance. Could you describe in detail the hardware that has this issue and the OS config (e.g. if its sysprep please provide the unattend and setup complete) also the exact OS info. I need to figure out how to replicate this on my vms.

[x23piracy]

@Max-Kern said in Windows 10 Client 0.11.4 Windows Service:

@RLane Hi,
Yes this worked for me very well on about 60 machines.
I put the delayed-auto into the SetupComplete an deactivate the Service like it says the wiki.

Well but i like that it works with any machine i try from vm to high end workstation.
some days ago the wiki was itself talking about delayed auto but this has changed and that for a good reason.

Well if you only using one special type of hardware you sure could stay with delayed auto and your good to go.

Read this i think he knows what he’s talking about https://forums.fogproject.org/post/73883

Regards X23

[Max Kern]

@Joe-Schmitt I will do it tomorrow when im at work.

[Max Kern]

@Joe-Schmitt Hi,
In this Textfile you see the Hardware of two diffrent machines, the Bluechip with the SSD work with the auto and delayed auto option, the HP 6300 Pro Clients with the WD Hdd only working with the delayed-auto option.
0_1469777655120_Spec 112 113.rtf
Unattend:
0_1469777856949_unattend.xml

SetupComplete:
sc config FOGService start= delayed-auto
net start FOGService

Software:
Windows 10 education 64 bit
Office 2016 32 bit
AndroidStudio
Eclipse IDE
VLC
OpenOffice
Chrome
Firefox
All updates of Office and Windows are installed, also it is the current Version of the other Software.

[Joe Schmitt]

Can you update your setup complete to restart as described in the updated wiki article?

[RLane]

@Joe-Schmitt I did. I’ve tried with the reboot - didn’t work. I’ve tried with automatic-delay - didn’t work either.

[Joe Schmitt]

@RLane are there any entries in fog.log?

[RLane]

@Joe-Schmitt There isn’t because the service is not starting until a manual reboot. In event viewer, it shows that the service failed to start after 3000 ms or something, failed twice like this.

Good news though… works well on an SSD. Any machine with a 7200 HDD, it doesn’t start the service in time. I haven’t had a computer fail yet with an SSD.

[Joe Schmitt]

Yes I understand, I need to see if any entries are being made in the fog.log on the failed start.

[Wayne Workman]

@RLane You can’t expect support for the new FOG Client without giving the senior developer of the new FOG Client a log, which he needs to give support.

[Joe Schmitt]

The v0.11.5 release candidate should fix this issue. More testing needs to occur before I mark this as solved though.