Win7 SP1 OOBE Fails Works On Non SP1

[Wayne Workman]

@H105 said in Win7 SP1 OOBE Fails Works On Non SP1:

Also the hosts all show as red in the Web UI. I have opened UDP port 7 and created an enable echo ping request rule on my image in the windows firewall which will sometimes let me send restart and shutdown commands from the Web UI but the only thing that seems to make those little taunting circles green is turning the firewall off completely which my superior does not want to do. Any ideas?

the ping feature isn’t critical or important and doesn’t impact anything, it’s there for convince. You can just turn it off, in FOG Configuration -> General settings -> fog host lookup. Turn your firewalls back on.

[george1421]

@Wayne-Workman Do we know the port where the fog client uses?

I’ve have these rules in my reference image build, but if we could narrow it down to the identified port(s) we could make the rule(s) a bit more precise.

  netsh advfirewall firewall add rule name="Fog Client" dir=in action=allow program="%ProgramFiles(x86)%\FOG\FOGService.exe"
  netsh advfirewall firewall add rule name="Fog Service" dir=in action=allow program="%ProgramFiles(x86)%\FOG\FOGServiceConfig.exe"
  netsh advfirewall firewall add rule name="Fog Tray" dir=in action=allow program="%ProgramFiles(x86)%\FOG\FOGTray.exe"

[Wayne Workman]

@george1421 I’ve never added an exception for the fog client, it’s always worked.

Either it does it on it’s own, or it uses just port 80 which is open for outbound and inbound.

Pretty sure it’s 80.

[Tom Elliott]

@H105 I still want to side with drivers. But not necessarily from the driver packs you’re using. Did you inject lan drivers before sysprepping? What about chipset? What about usb? I ask these things because I’ve run into this before under similar circumstances. If you inject drivers (usually done with pnputil) you must remember not to include unsigned drivers as Windows defaults to requiring drivers to be signed.

[george1421]

@Wayne-Workman Interesting, see that working if the fog client only uses the polled method of communicating (which may be the case). Then (typically) all outbound traffic would be allowed and polling would work unblocked.

But again then the OP would not be seeing different results with the firewall on vs off.

[Wayne Workman]

@george1421 host lookup from the server is different, it doesn’t use port 80. It uses some ICMP query that you’d probably know more about than me. It’s not a standard ping, and is faster and returns more than response/fail.

[H105]

@Tom-Elliott Just thinking logically to me i don’t see how drivers could keep it from joining a domain. I’m back to the office this morning after a week vacation so I’m getting to do real world testing on systems here instead of doing all my testing on a VM remotely from home. I did not inject any drivers. I simply told the OS to look for drivers that we store in a location on one of our servers once you’re in Windows. This morning I went ahead and upgraded to the latest version and booted my test VM and let it sit there for a minute and it did restart and updte the client from 11.2 to 11.4 like it should. And like i said it is changing the host name correctly too. Just not joining the domain automatically. Even if i issue a command from the web UI it does nothing. I have put my password in the field that does auto encryption and i have also put in the legacy encrypted password via FOGCrypt. I’m also able to issue power commands successfully now but still no domain and I’m at a loss as to why.

[Tom Elliott]

@H105 It’s not about the drivers.

It’s not even getting to the point that it can get to the domain. You said it’s failing while it’s loading.

It’s not the drivers … persay, rather the drivers that are on the image are currently unsigned. Again I don’t know what your environment is, all I can tell you is information based on what I’ve seen before.

[Wayne Workman]

@H105 Sounds like it’s those drivers you were talking about…

I simply told the OS to look for drivers that we store in a location on one of our servers once you’re in Windows.

A simple test would be to take a computer that is operating fine with all drivers installed, but not on the domain yet, and install the new fog client on it. If it’s not registered yet, register it. Then tell the host via the web interface to join the domain. See if it does or not. If it does, it means the AD stuff you have in fog is fine.

[Tom Elliott]

@H105, I’m confused.

Your post states you have an issue with it getting to the OS itself.

@H105 said in Win7 SP1 OOBE Fails Works On Non SP1:

I’m getting the “windows setup could not configure Windows on this hardware… please restart… blah blah” on any system I try to apply my Golden Image to.

However then you’re talking about it joining the domain?

@H105 said in Win7 SP1 OOBE Fails Works On Non SP1:

@Tom-Elliott Just thinking logically to me i don’t see how drivers could keep it from joining a domain. I’m back to the office this morning after a week vacation so I’m getting to do real world testing on systems here instead of doing all my testing on a VM remotely from home. I did not inject any drivers. I simply told the OS to look for drivers that we store in a location on one of our servers once you’re in Windows. This morning I went ahead and upgraded to the latest version and booted my test VM and let it sit there for a minute and it did restart and updte the client from 11.2 to 11.4 like it should. And like i said it is changing the host name correctly too. Just not joining the domain automatically. Even if i issue a command from the web UI it does nothing. I have put my password in the field that does auto encryption and i have also put in the legacy encrypted password via FOGCrypt. I’m also able to issue power commands successfully now but still no domain and I’m at a loss as to why.

Logically speaking these two statements are conflicting as the first quoted text would mean you’ve not made it that far yet. My responses are to this.

[H105]

@Tom-Elliott I’m very sorry. I have been unclear. The “windows setup could not configure Windows on this hardware…" error has been solved by following the instructions provided in the wiki that was linked by Wayne. IE: disabling the fog service and creating a setupcomplete.cmd to turn it on after oobe. I posted this previously and quoted it below. And forget everything i said in the last post. After testing on a faster physical desktop here at the office everything worked! Perfectly. The clear problem here lies with slower systems. Which makes sense because the VM system i was testing on all week was very slow due to the storage setup over the network. I just imaged two physical systems here. One being very slow. An old Gateway E2600D, that desperately needs a checkdisk, and a newer Daktech system. I noticed on the Gateway the FOG Service was not running despite it being set to automatic start. I then told it to manually start and got a timeout error. So i tried again just to be sure and the service started. I have let the computer now sit for 10 minutes and as I’m typing this the system has restarted and It is at the CTRL+ALT+DEL to login. So to me the obvious, is that the service does not start in a timely fashion on slower older systems. And i mean slow. Something you and I would consider a throw away but an end user that doesn’t know any better may not. So does there need to be maybe a delay in the command string of the setupcomplete.cmd before it tries to start the service? Or is there a way to make it re-try say 3-4 times after a failed attempt? Again sorry for the confusion.@H105 said in Win7 SP1 OOBE Fails Works On Non SP1:

OK. Sorry for the late reply. The steps provided In the wiki did the trick as far as it giving me that error. Worked a charm. I did not mention the system type because that should be irrelevant I would think according to my setup. Anywho we have daktech systems and Dell mainly. A few old gateways. Now the last problem I’m having before this beast is tackled is it will not join the domain. It renames the host and restarts the computer though. And I’ve read the information on here and it seems to be a common problem. I’ve made sure passwords are set correctly in the Web UI and all that. I’m using SVN 5846. Also the hosts all show as red in the Web UI. I have opened UDP port 7 and created an enable echo ping request rule on my image in the windows firewall which will sometimes let me send restart and shutdown commands from the Web UI but the only thing that seems to make those little taunting circles green is turning the firewall off completely which my superior does not want to do. Any ideas? Thanks for the help thus far.

[Joe Schmitt]

Perhaps instead of advising people to enable and start the service we advise them to enable the service and restart the machine. This way the natural windows service startup sequence is used.

Essentially on your slower systems I believe the client service dependencies are not up yet (the network services) and those are what cause the stalled service.

[Wayne Workman]

@H105 said in Win7 SP1 OOBE Fails Works On Non SP1:

So does there need to be maybe a delay in the command string of the setupcomplete.cmd before it tries to start the service?

Just read the rest of your post and saw this. I was thinking exactly what you were, about a delay.

Try any of these samples below, see how it goes. They all do the same thing - Delay starting the fog client by 30 seconds. Please let us know how it goes.

sc config FOGService start= auto
SLEEP 30
net start FOGService

sc config FOGService start= auto
TIMEOUT /T 30
net start FOGService

sc config FOGService start= auto
PING 127.0.0.1 -n 1 -w 30000 >NUL
net start FOGService

#wiki worthy

[H105]

@Wayne-Workman Its been a long road but I finally have everything working. Tested on 3 different systems. A Daktech, An old Gateway, And an older Dell Optiplex all deployed perfectly with 1 Golden image. Drivers and all. The solution i came up with was to create a reboot.bat using “shutdown -t 0 -r -f” and at the end of setupcomplete.cmd place “CALL C:\xx\xx\reboot.bat”. It seems the slow systems just need a reboot to get the service to load properly as Joe suggested and of course we all want it to be automated. The delay could possibly work as well but i cant confirm since i came up with my solution before seeing this. At least the information is there if someone else stumbles across this. Thank you everyone for helping me tackle this. I greatly appreciate it.