Client reboot screen
-
If you follow the fog client sysprep guide, there’s a section about re-enabling the client. What I would recommend is to do your work that gets done in auto log in, enable the service on startup, and then restart the computer. A FOG deployed snapin won’t run without the client running, but the client’s snapin functionality isn’t affected by if a user is logged in or not. Any sysprep scripts you have wouldn’t be affected by a disabled client either.
-
The question I would have to ask about the snapin system is: Will the snapins install without anyone logged in? That way via sysprep you can have a first login and do what ever actions are necessary then enable the fog client and then reboot.
The other thought would be to run the fistlogin stuff if you have it then log out.
[edit] Well I see that Joe answer my question before I posted it. [/edit]
-
Snapins will run exactly the same regardless if a user is logged in or not.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.
-
@Joe-Schmitt Then the only question would be is the fog client needed for other image deployment actions (renaming host, connecting to AD, and such) where a delayed start on the fog client would cause other issues.
I can say for my deployments we enable the fog client in the setupcomplete.cmd file which is executed before the fist login actions.
While I haven’t worked with the snapins at all, I could see value in an option for a snapin to install now vs a delayed install/reboot.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
the first 2 scripts handle machine naming, and a couple machine settings. the 2nd scripts handle ad join, and registering to zenworks, then deploying software bundles.
-
@adukes40 said in Client reboot screen:
the first 2 scripts handle machine naming, and a couple machine settings. the 2nd scripts handle ad join, and registering to zenworks, then deploying software bundles.
Why are you doing it this way? Are you deploying these scripts with snapins? There are other ways to go about this that we can talk about. I can say the fog client will do what your fist 2 scripts are doing.
Actually I’m not using the fog client for these actions but letting the unattend.xml file do this. I have a fog post install script update the unattend.xml file for that. Are you querying the installer for settings during your script runs?
-
@george1421 I’m down to try new ways of doing things. The client is calling the snap-ins and the snap-ins are PS scripts. I am aware the client can do some of things PS is doing, and I was going to explore those once I get everything stable to replace our current solution.
What other ways could this be obtained?
-
This really is a way of saving me 2 minutes lol. but on the other side the reboot screen just allow a user to talk up and hit delay for 10 minutes. This could cause other issues, especially working in a school district
-
@adukes40 Tell me a bit more about your setup. Where does the target computer get its name from and how do you select the OU that the target computer goes in?
-
@george1421 said in Client reboot screen:
I could see value in an option for a snapin to install now vs a delayed install/reboot.
If the snapin is script-based, one could easily include a sleep command in the script.
