Win7 SP1 OOBE Fails Works On Non SP1

[H105]

Hello everyone. I am having a serious issue getting a Windows 7 Pro SP1 64 image to install correctly after deployment. 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. Now of course I can [Shift+F10] and go into regedit and change the value in the setup.exe registry key from a 1 to a 3, restart, and the computer will complete OOBE and everything works. Now this is with a fresh image with SP1 and Internet explorer 8. Now if I deploy my Windows 7 Pro 64 image that does not have the service pack everything works perfect. Any machine. Any day. But this is a problem because our fog setup is being use for a school district with multiple different system configurations. Hence the golden image. Also the newest fog client can’t be installed without the newest .NET and the newest .NET cant be installed without SP1. I’ve tossed around the idea of using our SCCM to push out the SP1 and IE updates after the image but this is not practical nor the correct solution. I’m using the same unnattend.xml for both images. Both are setup exactly the same apart from one having service pack 1 and the other not. I have also completely recreated the SP1 image a couple times and tried different things but it seems that there’s something in the service pack making OOBE not work properly after devices have been installed. I’ve been working on this problem for a week now at work and late into some nights after hours. Any help would be immensely appreciated.

[Quazz]

Did you sysprep with /generalize?

[george1421]

Typically when I see this error it is because a driver failed to install right. You know the back door to get into the system so the system is fine, just the drivers (or lack there of) caused the install to fail.

You didn’t mention the target system you are deploying to AND what version of FOG are you using (look at the number near the Cloud on the FOG management gui)

What I recommend, is probably not what you want to do but I’ll say this.

Rebuild your reference image using microsoft MDT. This will let you go from the dvd to a complete reference image using the lite touch method. I’ve got slightly above average IT skills and from never touching MDT to my first (rough) reference image it took about 3 days including setting up MDT. From there it took me about 2 weeks to perfect the image to get a fully deployed and patched lite touch fat image (with all of the applications). We rebuild our master reference images once a quarter with the latest patches so we needed a fully automated way to go about this. There are plenty of examples on the internet for setting up MDT. In our case we have one golden image for all systems, then just inject the correct driver pack with a fog post install script.

[Tom Elliott]

I’ve also seen this happen with something as simple Antivirus. But I digress.

[Wayne Workman]

@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.

Wiki excerpt:

"Windows Setup could not configure Windows to run on this computer’s hardware.” …
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

[H105]

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

Typically when I see this error it is because a driver failed to install right. You know the back door to get into the system so the system is fine, just the drivers (or lack there of) caused the install to fail.

You didn’t mention the target system you are deploying to AND what version of FOG are you using (look at the number near the Cloud on the FOG management gui)

What I recommend, is probably not what you want to do but I’ll say this.

Rebuild your reference image using microsoft MDT. This will let you go from the dvd to a complete reference image using the lite touch method. I’ve got slightly above average IT skills and from never touching MDT to my first (rough) reference image it took about 3 days including setting up MDT. From there it took me about 2 weeks to perfect the image to get a fully deployed and patched lite touch fat image (with all of the applications). We rebuild our master reference images once a quarter with the latest patches so we needed a fully automated way to go about this. There are plenty of examples on the internet for setting up MDT. In our case we have one golden image for all systems, then just inject the correct driver pack with a fog post install script.

I don’t think this is a driver issue because that’s what I immediately thought. I’m using driver packs from driver packs.net as well as pointing to a driver store on our network via the device path registry key. And as I said it works just fine on the non SP1 with the exact same drivers and settings. I am interested in learning MDT and this may be the route I go after trying the above suggestion in the wiki if they don’t work. It looks promising and seems logical seen as Fog client is not installed on my non SP (due to the .NET issue) image and it is on my SP image. There is no AV installed on either. I am using sysprep /oobe /generalize /unnattend:c:“unnattend.xml path”. Will try tomorrow and report back.

[H105]

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.

[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