Umm What verision of the software are you using, because we use the SMART board system and I deploy my image with the software and drivers already installed.
Try pushing an image with the smart software ommited on a test machine, if it works that way, try to install the software after it is imaged and see if the issue still arises.
As far as constant rebooting, I have encountered this, however I never troubleshot the problem, I just reverted to a previous snapshot and attempted to sysprep a little differently.
I have run into problems with the windows error reporting before the OS boots, but again, I just reverted to a previous snapshot and worked out the kinks.
[quote]Okay, so I read more and figured out that sysprep does what I need it to do. Questions though:
1.) What is sysprep actually doing?
2.) Can I only use it a max of 3 times?[/quote]
Sysprep releases the OS from the specifics of the hardware and thus allows it to be installed on another machine.
Sysprep takes care of all the mess of changing/deleting the registry values, and it allows the new hardware to write it’s ID information to the OS and will allow the OS to be activated.
KMS servers have to have a unique ID for each machine that wants to activate.
I do my sysprep process in a virtual environment and this will leave it open to any type of hardware, so long as I supply the drivers (i do so in the os and reference to them later with registry values). However you can also install the OS on a hardware to install updates, programs, etc then audit. After you update the Windows installation, at the command line run the Sysprep /audit /generalize /shutdown command to configure Windows to boot the computer to audit mode. You can then capture the Windows image.
Use the new model-specific reference image to install Windows on a new computer. The Windows image is applied to the computer, and Windows boots to audit mode.
(Optional) You can install additional applications and other updates. You can also test the computer to verify that all components are working correctly.
After you update the Windows installation, run the Sysprep /oobe /shutdown command.
NOTE
If you install Windows images by using the Sysprep /generalize /oobe command, the user experience will not be ideal. On the next reboot after you run the Sysprep /generalize /oobe command, Windows runs the specialize configuration pass, Plug and Play, and other Setup tasks before Windows starts OOBE. This process can take additional time and can delay a customer’s first logon.
To answer your second question, YES you can sysprep more than three times.
One option is to use the Virtual setup I talked about and use snapshots to revert to a time before sysprep has been ran and update/push again.
OR
During the set up of your unattend.xml file you can skip re-arming the os and this THEORETICALLY gives the os 999 re-arms, it should be noted that this is heavily frowned upon and I highly recommend the virtual set up. Snapshot can save you a LOAD of time if you don’t have to re-set up the OS and install the damn updates again!
If you would like, I have a word document I have been using to keep track of my sysprep adventures, it would give you a good base to work from, and it is set up in a walkthrough style.
I’m with smshahan I have made 12+ images of windwos 7 and imaged with fog and I have NEVER experienced this. I have however ran into issues with my user accounts in my early sysprep stages, but since then I have gotten a better grasp.
I would first start with a blank image on a virtual server, sysprep it with your CURRENT unattend file. If you don’t encounter the issue, then it is not with the Sysprep process. This is only to troubleshoot your unattend file. IMHO the unattend file is the most daunting task of the sysprep process.
If your sysprep files isn’t the issue, I would say it is a rogue program or a setting in the AD or Group Policy Settings. Again I’ve not encountered this issue so I can’t tell you exactly what it is. I would give that Link above a shot on one of your units, if it solves the issue then push out the Regfile as a log in script.
Way to go! Sorry I couldn’t be of more assistance to you, but I am glad you got it going!
Thanks for the reminder about that “Clone flag” Chad, I had actually forgotten about it! You are correct, when you go to thaw a machine by the DF client, under the status page, on the right hand side is “imaging options”, click the “Set as Clone” button. The computer will reboot.
Deploy Deepfreeze after imaging has completed.
Deepfreeze adds all kinds of hell to an image. I have successfully included DF in my image, along with a thaw space, but after deployment it ends up with 2 different thaw spaces rather than 1.
I use the thaw space for my AVG install and other similar programs, and during imaging the drive letter stays the same but it also adds another small thaw space on it’s own whim.
Also, don’t use FOGprep, it’s no longer needed unless you are using Windows XP
Currently I’d start by harvesting the drivers required and adding them in.
I.E. Video card, NIC, any kind of ATA or RAID adapters, basically anything that FOG is going to NEED in order to process the host.
You can use older KS kernels to, you don’t JUST have to use the recent one, matter of factly some users find that the older version of the kernel works where as the latest does not.
I don’t have any experience with MINT but, it is an Ubuntu derivative.
I this a fresh FOG setup? Has this worked in the past and just stopped working? or is this your first attempt at setting up a server and attempting to image?
I would check the log to see if the FOG server is 1 looking for the cast, and 2 is the owner of the process.
try this one here
[quote]
We were having issues with new laptops that use the Atheros 8161 Ethernet controller so we have compiled the compat-drivers (alx) with Kernel version 3.5.4-kitchensink. Here is a link to the download for anyone that needs it:[URL=‘http://davidouwinga.com/bzImage.zip’]http://www.davidouwinga.com/bzImage.zip[/URL]
You will need to extract the zip file and move the bzImage file to /tftpboot/fog/kernel/ as root[/quote]
It’s a kernel issue, one of the drivers are missing you just need to figure out which and include it.
this page explains how to include the drivers not included with the kitchen sink or not included in the kernel to enable.
[url]http://fogproject.org/forum/threads/dell-2330-all-in-one-network-issue.1054/page-2[/url]
and according to chad
[quote]
"I had a weird issue registering hosts similar to this. It turns out the students had removed the belt from the dvd-rom drives and Fog would freeze for about 45 seconds. I guess it was trying to get the status of the device, but without being able to confirm if the drive was open or closed, it just sat there and spun the motor back and forth for a while.
I found ejecting the drive with a paper clip immediately caused Fog to continue to the normal registration.
[B]Something else to consider is that the error you see has nothing to do with what is really causing registration to fail. Consider booting the debug mode see if the error you see is truly what’s wrong. There is a wiki guide to debugging somewhere.[/B]"[/quote]
[url]http://fogproject.org/forum/threads/unable-to-register-certain-host.773/#post-3457[/url]
Best of Luck.
Does nothing else error out? if your other images upload it can’t be a permissions issue. Permissions are not intermittent.
How is the harddrive set up? Does it use the new formatting style with caching partitions?
Is this the only type that has the issue? Is there other hardware you can test, does it also error out?
if there is no way to “fake” the sata controller, use the custom kernel guide to include the SCSI controller drivers that Proxmox uses. You may try the kitchen sink kernel before you compile your own, it will normally take care of most issues. I found with VMWare ESXi even including the drivers did not help, but I could upload just a slow speeds. If your drive can’t be found, your kernel is missing the drivers necessary.
if you upgraded to a recent revision of Ubuntu, you may need to manually start the service after a reboot.
Hello all, I’ve hit a wall with this one, i hope it is a silly fix but here it goes.
I have received some of the “latest and greatest” from our dealer for student machines. I had no problems registering the units to FOG or even imaging them. FOG has done beautifully with both. However, upon completion when Windows does it OOBE crap it comes back after the first registry sync and claims “Windows can not be installed. Windows can not be configured to run on this hardware.” Which I KNOW is bologna, the units came shipped with a vendor Windows 7.
At first I thought it had to be a setting in the bios, but here I am day 3 of trying different bios settings but nothing seems to work.
My other collegues work with the WDS server and pull their images from, and I decided to give it a shot too.
I pulled the WDS image and immediately uploaded it to FOG. I push this image to my FOG units, I have NO problems, installation completes properly, with NO changes to the BIOS at all.
So my question is this, I am fairly certain it is not a FOG issue, otherwise my other image would fail. The image is pushed to my units fine, so I’m saying FOG settings are not the issue.
However, I’m trying to figure out what the difference in the images is. Is there something specific that I forgot to install in my imaging process? Does someone have a place for me to start at, because right now, I’m lost in the dark 
Thanks all!
I can’t explain this, but from time to time I run into these issues or problems with a specific hard drive where fog just can’t see it or the partition information or something. I end up swapping the drive with something else that will work. It’s not a bios setting, I can take the drive to another piece of hardware and it still won’t work, where as the hard drive I just pulled from it did.
My units are fairly aged though, 2006-2008 models, the newer ones thankfully don’t seem to be having as many problems.
I’ll try installing something else on the hard drive and then try FOG again, there has to be something particular causing this.
Yeah I wish I could have spent the time figuring out what the issue was with VMWare hardware, but I had to get my images done and I wasn’t running on anything fancy. It was painfully slow trying to operate on the machine I was using as an ESXi server. Virtual Box just WORKS and extremely well 
Glad you’re on your way!
If you decide to go back to figuring out the ESXi problem I am willing to help as well!
It’s still there, maybe someone with some expertise can help, I imagine a setting got wonked somewhere.
I just wanted to make sure you had the client installed and set up on the server for the actions
Build a custom kernel with the drivers included for the VMWare drives. This is an issue with hardware and drivers. My recommendation is the scrap that ESXi, it’s damn near useless with FOG. Instead use Vitual Box, which uploads a HELL of a lot faster than VMWare.
I troubleshot this when I started my imaging this summer, and I never really fully figured it out. I got SOME speeds back with a custom kernel and the kitchen sink kernel, but all in all time was saved by using Virtual Box instead.
Don’t bother trying to port your VMWare to Virtual Box either, you’ll save time but just starting over because of the hardware that VMWare uses.
This is just my personal experience, take it with a grain of salt, but the issue is Kernel drivers.
[url]http://fogproject.org/forum/threads/increase-vmware-host-upload-speeds.4388/#post-12649[/url] My post all I had to search for was VMWare, it was the second listing.
Have you installed the FOG client?
Naming a unit in the hosts section does nothing unless the counter part FOG client is installed on the host and the option is enabled in the FOG settings. My recommendation is when you install the client leave EVERYTHING checked and turn off what you don’t need at the server.
Please check to verify that Wake on Lan capabilities are enabled in the OS and the BIOS.
Restarting from WOL is extremely unreliable just as a technology, I wouldn’t count on it for anything. It’s nice to wake the units in the morning, but I still walk around and manually check, never trust WOL
Raff is right, as long as you assign the image in the hosts section, when you upload it overwrites the current image information with the new information, the only way to keep if from doing this is to assign a new image each time you upload and adjust the image for the host properly.