Windows 10 Client 0.11.4 Windows Service
-
Hi,
there is the Log 0_1469538827543_fog.log , but maybe you see that it is from 14:36 and her now it is 15:15. After i started the Service, the Client Reboots and Joining the Domain.I also see, that after a bit of Time (10 min) the other Clients start the Service and so they join the Domain and so on. After that the Service is running good.
Another solution i figured out is to set the On Start Timeout higher than 30 seconds.
Therer is no zazzles log, so i think everything is good.
Here you have a Screenshot from the StartupScript and the Event Viewer(only in German).
There it says, that the Timeout for Startup the FogServices is over. -
@Max-Kern I didn’t realize this was post sysprep. I’m assuming the client starts properly if you just restart the machine?
-
@Joe-Schmitt sorry for that bad Reply.
No the Client don´t start if i reboot the machine, i must start it or wait until the System will start it. After first Start of the Service it allways will start. I think there are some initial things your service is doing, so the start need time.
I will set the Start Type in the Script to automatic delayed and maybe it will work better.
At one Client it worked, now i will look if this work for an Deployment. -
@Max-Kern said in Windows 10 Client 0.11.4 Windows Service:
No the Client don´t start if i reboot the machine, i must start it or wait until the System will start it
I’m confused. So the system is or is not automatically starting the client without any changes to the stock service configuration?
-
@Joe-Schmitt The System wont start it on Startup, because he says after 30 Seconds, that the On Start takes to long. After the Startup, if the machine is in idle, suddendly the Service will be started.
-
@Max-Kern as soon as the client fails to start, what is the status of the
dnscacheservice? -
@Joe-Schmitt it is running also the DHCP Service
-
@Max-Kern you said the client automatically starts if the computer is idle. How long do you have to wait for that to happen?
-
@Joe-Schmitt Sometimes 5 min, 10 min at some Clients longer(hours) but nothing under about 5 min
-
@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.
-
@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.
-
@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.
-
@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.
-
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?
-
@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 normalCheck here: https://forums.fogproject.org/post/74436
Regards X23
-
@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.
-
@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. -
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.
-
@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/73883Regards X23
-
@Joe-Schmitt I will do it tomorrow when im at work.
