Service Fog Client
-
Hi,
I’m creating my image in the virtual box, I’m installing the fog client, I’m going to have some problem if I leave the fog client service already started in the image? after the ready image I do sysprep
-
You will want to disable the fog client before sysprep and set in the unattend.xml to start it back up on first start
-
why? what would be the problem of letting him get started?
-
I cant tell you the exact reason it has issue I just know that it does.
In my script I add the following:
<FirstLogonCommands>
<SynchronousCommand wcm:action=“add”>
<CommandLine>del /Q /F c:\windows\system32\sysprep\unattend.xml</CommandLine>
<Order>1</Order>
<Description>Deletes unattend.xml</Description>
<RequiresUserInput>false</RequiresUserInput>
</SynchronousCommand>
<SynchronousCommand wcm:action=“add”>
<CommandLine>del /Q /F c:\windows\Panther\unattend.xml</CommandLine>
<Description>Deletes unattend.xml</Description>
<Order>2</Order>
<RequiresUserInput>false</RequiresUserInput>
</SynchronousCommand>
<SynchronousCommand wcm:action=“add”>
<CommandLine>sc config FOGService start= auto</CommandLine>
<Description>Changes FOG server to Automatic</Description>
<Order>3</Order>
<RequiresUserInput>false</RequiresUserInput>
</SynchronousCommand>
<SynchronousCommand wcm:action=“add”>
<CommandLine>net start FOGService</CommandLine>
<Description>Starts FOG service </Description>
<Order>4</Order>
<RequiresUserInput>false</RequiresUserInput>
</SynchronousCommand>
</FirstLogonCommands>This turns the service back on after sysprep runs.
-
@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
-
@zago123 said in Service Fog Client:
why? what would be the problem of letting him get started?
The problem is when the client starts reaching out to the FOG server before Windows is completely done getting ready. The client can cause the host to reboot before Windows is finished setting up… which is a bad thing.
I believe the latest SmartInstallers have the FOG Service start type set to manual by default.
-
@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
-
could be solved in the future?
with some new version of it? -
@joe-schmitt It might be possible to detect sysprep & first startup processes happening.
-
@wayne-workman said in Service Fog Client:
@joe-schmitt It might be possible to detect sysprep & first startup processes happening.
Or just provide a command line switch to force the installer to install the client but disabled. The default action would be to install and start like it does today.
-
@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.
-
@joe-schmitt said in Service Fog Client:
when client installs, it sets the service to auto on boot, but does not start.
I guess what needs to be turned into a feature request is a msi install command line switch to alter this behavior. This switch would install and set the service to disabled. Or alter the process to require a command line switch to set the service to auto and the default would be disabled. Either way would work. Probably the command line switch to disable the service would cause the least amount of pain for already installed environments.
Most of the time the fog client is being installed before the system is sysprepped, which is causing us the most problems. So if the client installs but doesn’t start until the FOG Admins wants it to, that would eliminate that source of imaging pain. Also if we can keep the fog client from starting during reference image development, we can keep the fog client from tattooing to the defined FOG server until after OOBE is run (I’m not sure if there is a benefit there).
On the back end to turn the auto start service back on we could have a command line option for the fog client to start the client and enable the service that can be called from the setupcomplete.cmd file. Something like “c:\program files\fog\fogclient.exe /autostart” (I just made up the path and file name just as an example)