Jump to content

Recommended Posts

Posted

I have made a universal image for both my 64 bit and 32 bit build of Windows 7 to be deployed to the machines in my organization I have notice the following.

the 64 BIT Windows 7 the sysprep process finishes in about 15 minutes.

the 32 bit Windows 7 the sysprep process finishes in about 30-40 minutes

I have run this test in the same pc, both my 32 bit and 64 bit builds run exactly the same software.

Does anyone know why sysprep process is taking more then double the time than the 64 bit process. Is this normal?


Posted

Wow that is definately way too long. The longest I've seen was 5 minutes, but that is because there are a lot of programs installed. I do know of a sysprep delay issue with an updated IE installed but I can't seem to find it. You should look in Panther to see the log file, maybe it is encountering some problems (warnings) or it could be you just have a lot of files or programs installed.

Posted

Wow that is definately way too long. The longest I've seen was 5 minutes, but that is because there are a lot of programs installed. I do know of a sysprep delay issue with an updated IE installed but I can't seem to find it. You should look in Panther to see the log file, maybe it is encountering some problems (warnings) or it could be you just have a lot of files or programs installed.

Thanks I'll check the panther logs and post back here, is there any in particular log file i should focus on?.

Posted

If it happens every time, you might want to run a process monitor while sysprep'ing, with a filter perhaps on sysprep itself.

Posted

Here is one thing right off the bat:

2010-07-21 21:45:16, Error                 SYSPRP SPPNP: Error 0x2 setting SDDL on driver file C:\Windows\system32\igfxsrvc.exe!
2010-07-21 21:45:16, Error SYSPRP SPPNP: Error 0x2 enumerating locked down files!

This is the Intel Graphics service for controlling the onboard video. Sysprep is having a problem reading this file because either it can't close the service, the service is not responding or any other sort of reason. Do you use a video card in this system or are you using the onboard video?

But this error shows up at 21:45, but the log starts at 21:43 so definately not a long time according to the log file. So it looks like it only takes 2-3 minutes for sysprep to run, as it shuts down the log file AFTER the error with IGFX, so the slowdown might actually occur after the log file stops.

So suffice to say, Panther logs aren't really showing anything. Just for fun, try turning off the IGFX service before running Sysprep. You will still have video, but if you are running multimonitor the other display will turn off. Then run sysprep and see how long it takes.

Posted

So suffice to say, Panther logs aren't really showing anything.

Actually, are you sure about that? What is does show us is sysprep took about 2 minutes, and half of that was reflecting drivers:
2010-07-21 21:45:15, Info                  SYSPRP SPPNP: Reflected all boot critical driver packages (61153 ms).

If the OP is saying that sysprep is taking 60 minutes, and the log shows 2, we need him to actually get out his watch and note the time he presses enter after sysprep /generalize /oobe, and the time the box shuts down. Then, we compare that to the sysprep log to see where in that time sysprep actually runs, and finishes. My guess is sysprep runs at the END of the time the OP is stating, rather than the beginning, given that sysprep is shutting down the system (and I think the OP would recognize if shutdown was taking a long time versus sysprep). That would mean, at least empirically, that after the OP runs sysprep /generalize /oobe, it takes upwards of 57 minutes for sysprep to actually start - hence, PROCMON ;). Something's fishy, and given how long the boot critical driver reflection is even during the 2ish sysprep minutes of the panther log, I'm wondering if Defender, or an Antivirus product, or some other boot driver is hanging up actually running sysprep, or if he's got an unhealthily large registry...

Posted (edited)

Sealing the pc, is fast cluberti, it's after the reboot and sysprep is doing it's thing it takes 30 minutes before sysprep is done and I'm at the login screen,

Edited by clivebuckwheat
Posted

I think we have terminology conflicts here - sysprep does it's thing when you run it. After the reboot (or when restoring the image to another machine), setup is going back and specializing the machine (because you /generalize'd it with sysprep). Does this occur if you install Win7 on your hardware from media, add no apps or additional drivers, and then sysprep/restore it? I'm trying to figure out specifically whether or not it's the hardware/drivers or something you may have installed into the image that's causing an issue.

Posted

I think we have terminology conflicts here - sysprep does it's thing when you run it. After the reboot (or when restoring the image to another machine), setup is going back and specializing the machine (because you /generalize'd it with sysprep). Does this occur if you install Win7 on your hardware from media, add no apps or additional drivers, and then sysprep/restore it? I'm trying to figure out specifically whether or not it's the hardware/drivers or something you may have installed into the image that's causing an issue.

My 64 bit Windows 7 image has EXACTLY the same apps, drivers, etc as the 32 bit image.

The 64 bit image, once the pc is sealed and deployed to a pc. Sysprep does it thing, and I am at the windows login screen in 10 minutes.

The 32 bit takes 30 minutes deployed to the same pc.

All my images 32 and 64 bit have exactly the same apps, and drivers.

Sorry if I am confusing you with the terminology,

Posted

Sealing the pc, is fast cluberti, it's after the reboot and sysprep is doing it's thing it takes 30 minutes before sysprep is done and I'm at the login screen,

Ah OK, so we're not talking about "sysprep" as much as the OOBE process on the reboot. I think there is a different setupact.log that is in C:\Windows that we need to see and not the one in the Panther folder.

Posted

Well, they're not exactly the same drivers, because you don't use 32bit drivers on 64bit Windows, but I understand your point. If you can get the setup*.log files from C:\Windows, that might be helpful.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...