With the help of Michael’s thread here

[url]http://fogproject.org/forum/threads/solved-task-is-complete-within-seconds-problem-with-gpt-mbr.1172/[/url]

I finally was able to solve my problem. In my case it seems as if the GUID partition table and the MBR were confusing each other, so the Linux-FOG-Kernel couldn’t find any partitions.

Here is what I did:

[B]Please note:[/B]
Since my computer was just a testing machine to create an image I did not backup anything before doing this. As recommended on the Fixparts webpage you should certainly do a backup (of MBR, system and data, or in other words everything ;-), if you’re going to do the following steps on an important machine/system.

Download Fixparts for Windows from here:

[url]http://www.rodsbooks.com/fixparts/[/url] (look for the link “download page”)

Unzip the file and execute it with administration privileges. A command window will now pop up.

Type in “0:” (this command is just for Windows!) to define your first (and in my case only) HDD to be the one to analyse.

Now the tool suggests to delete the GPT signatures and asks you to confirm. If you want to use Linux as well as Windows on your disk you probably should not delete those signatures. But in my case I only want to use Windows, so I say yes.

After that exit the tool by typing “w” (write changes to disk and quit). Restart your computer to check if it still works.

Sysprep the OS and upload the image to FOG.

I used the custom kernel written by yogipaolo, found here:
[url]http://fogproject.org/forum/threads/lenovo-x130e.587/#post-2813[/url]

Works like a charm - booting the kernal seems to take a while but otherwise perfect.

Having the same issue here as well. I will keep you posted. Thanks!

Little late to the party, but I am also seeing this type of issue on our main Windows XP image. After sysprep is done, fog services will not fire. Fog.log shows the following:

[CODE]
8/8/2012 9:40 AM FOG::GreenFog Starting green fog…
8/8/2012 9:40 AM FOG::GreenFog Attempting to connect to fog server…
8/8/2012 9:41 AM N/A Call was canceled by the message filter. (Exception from HRESULT: 0x80010002 (RPC_E_CALL_CANCELED))
8/8/2012 9:41 AM FOG::SnapinClient Sleeping for 497 seconds.
8/8/2012 9:41 AM N/A Call was canceled by the message filter. (Exception from HRESULT: 0x80010002 (RPC_E_CALL_CANCELED))
8/8/2012 9:41 AM N/A Call was canceled by the message filter. (Exception from HRESULT: 0x80010002 (RPC_E_CALL_CANCELED))
8/8/2012 9:41 AM FOG::AutoLogOut Unable to continue, MAC is null!
8/8/2012 9:41 AM FOG::UserTracker Unable to determine MAC address, exiting…
8/8/2012 9:41 AM FOG::TaskReboot Attempting to connect to fog server…
8/8/2012 9:41 AM N/A Call was canceled by the message filter. (Exception from HRESULT: 0x80010002 (RPC_E_CALL_CANCELED))
8/8/2012 9:41 AM FOG::HostnameChanger Host name was not found in the database.
[/CODE]

A temporary solution I have is to tell sysprep to run the net stop “Fog Service” and net start “Fog Service” commands on first login after the imaging is done, but this still fails when trying to join the domain. So my current solution would be to add a batch script that runs any time the computer logs in to restart the service.

Worked like a charm!

Thanks!

You got this right on target !! Thanks a lot !

Now my server is working I was able to upload and deploy images. I have my images in XP.
Now I have to try doing my Windows 7 Image. Hope not to face any issues.
Again, thanks you so much for the help ! Cheers !

Hmmm, interesting. I haven’t had any problems using a single resizable partition. I wonder if that’s because all of our machines still have the 100mb partition still in place when they are imaged, and perhaps the image just replaces the OS partition instead of the system reserved.

Our machines are all typically the Dell Latitude series (couple of Precisions, but they work too), and the master image came from a modified e6510 build (it’s been converted to a VM, since).

Thank you very much for this! Now with this being said…is there anyway to enact this with Group Policy to all clients? Let me know. Thanks a bunch!

I have to ask, why would you want to go to XP? Application compatibility?

astrouga

[quote=“SMoRZ3, post: 4501, member: 1375”]Hi all,
I’m just getting into syspreping and I have some questions…

I have a PC setup exactly how I want it (WinXP_Pro_OEM_SP3)). I’m going to upload it to fog as a backup. Then I plan on running sysprep.

I’m also just reading into the [URL=‘http://driverpacks.net’]Drivers Pack[/URL] website. And trying to copy some of the suggestions in [URL=‘http://fogproject.org/forum/threads/how-to-create-a-universal-windows-xp-image-using-mysysprep-exe-and-vm-ware.616/’]this tutorial[/URL].

[1] I really don’t care about image size, but if I just beef up this image with all the drivers possible, could I potentially have a universal setup built off of a real PC, instead of a VM PC like in the provided tutorial? I’m assuming updating the image would mean having to deploying the pre-syspreped image, updating it, then re-syspreping it which is where having the VM would be ideal.

[2] I also was wondering if I really need to use the sysprep.inf file to give an admin account password since the image im making already passworded it, or would syspreping remove this password so I then need the sysprep.inf to give it back?

[3] Also the create random computer name should be fine because fog will then rename it after the image is deployed right?

[4] We also just use the Product Keys on the Dell boxes we have. I should just be able to use the same code on every PC since it will auto activate because of the OEM Bios correct? I mean, we’ve never syspreped before and never had an issue with all the XP machines using the same image with the same product key/activation.

I know this is a lot, but I’ve read so much that its all just one big blurry confusing mess on exactly what is possible with sysprep. It seems like everyone has their own opinion on how to do it, which doesn’t seem to help with the confusion! 😛

I’m just trying to make a setup that possibly works with more than one hardware configuration if at all possible.

Thanks for any answers.
-SMoRZ3[/quote]

#1. In theory yes, however it’s easier in a VM due to you being able to roll back changes, make updates, or test things out. You will want to build your image on the OLDEST hardware to make it the most compatible (if it’s xp)

#2. Yes you need a sysprep.inf answer file to give the admin password the correct info

#3. If you have the fog client installed it will rename the pc to what ever is in the database. The add-in Capone (google it) can also do advanced imaging options based off of DMI info

#4. Don’t worry about product keys if you are using an oem disk. You need to have 3 things correct if you use an oem copy of xp for sysprep.

A. OEM hardware (dell / hp / compaq / etc.)
B. An oem slp key - [url]http://technet.microsoft.com/en-us/library/bb457078.aspx[/url]
C. The proper oembios files (this happens when you run the oemscan.exe snapin)

you need to sysprep due to having a unique SID, otherwise you have issues.

Enjoy

Please check the tutorial forum. I have a start to finish guide on making a universal image - [url]http://fogproject.org/forum/threads/how-to-create-a-universal-windows-xp-image-using-mysysprep-exe-and-vm-ware.616/[/url]

Dude… sounds like the host is not registered with FOG. but at the sime time, looks like it is.

Have you tried to remove the host and re-add it?

Or… jump into the database and see what is happening?

Look here for some information regarding pxe/tftp over vpn.

[url]http://fogproject.org/forum/threads/tftp-issues.823/#post-4112[/url]

Solved with help of another forum. Using the GUI sysprep does not read the unattended.xml file. You must use the command line and the unattend option. I’m amazed I am the first to have this issue.

While researching this I came across an article which talked of how memdisk booting large files can cause memory errors because of the nested memory method it uses. Rather than using memdisk for your kernel and the Windows 7 disk for the init file, you might look for other options such as booting grub4dos.

I can now confirm that the problem has nothing to do with fog. A few testruns later it seems sysprep or some other think did it. A direct copy from original to target was successful. Even running sysprep afterwards was successful.

I am stumped. Any ideas?

Well, unfortunately I get stuck right at the get-go. The image takes on VM, but I can’t use my keyboard or mouse at the log-in screen to even do anything. I’ve tried a few things, but can’t get it to work. Could this be because we have never syspreped any images before uploading them to fog for deployment?

Have you considered a Fog snap-in to run post imaging that might execute whatever commands you need to enable the 2nd monitors?