It depends on where and how you want to focus your effort.

I already have extensive scripting and sysprep solutions for our deployments, much of which FOG can’t touch or isn’t built for, so it’s easier for me to use Microsoft’s existing tools then it is to look for a solution elsewhere.

Move to Feature Request

@Tim.Trageser said:

I have the Virtual Drive set to IDE should I try SATA?

You should be using SATA in VMWare (or other solutions) no matter what kernel you’re using. Yeah do it.
But I doubt this will solve your problem… We’ll see.

For the time being I am on 3501, once I get through the bunches of systems I have to image I will be keeping up with trunk, just don’t need anything to break right now, so staying put where I got it working.

I will just update to SVN later on and be good to go with the Kernel.

no, it’s not.

However, each storage node has it’s own NFS setup.

So if you edit the image location in your /opt/fog/.fogsettings to be relevant for the node you’re on, the exports will be created following the proper nfs share point.

lol… so now on I’ll just say “Update to Latest Trunk”

Solved as the Apache error is corrected for in latest svn.

Tom has fixed the issues and I am 100% up and functioning

It won’t use any rearms at all unless you actually run sysprep. If you do run sysprep and you don’t want it to rearm, just include Skiprearm set to 1 in your unattend file.

Here’s a bit of my unattend file so you can see where the SkipRearm bit should be:

<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:sc.... <settings pass="generalize"> <component name="Microsoft-Windows-Security-SPP" ..... <SkipRearm>1</SkipRearm> </component> </settings>

As for not being activated - I found it annoying and activated in the end, since you have something like 3 rearms you can use. But I think it at least affects Windows updates so if you wanted to include those on your image, then activate once if you can.

Please examine this:
https://wiki.fogproject.org/wiki/index.php/Known_FOG_Bugs#The_Image_Resize_Bug

I think you’re affected.

Please examine this:
https://wiki.fogproject.org/wiki/index.php/Known_FOG_Bugs#The_Image_Resize_Bug

I think you may be affected.

@Tim-Trageser

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

Awesome, thanks I am up and running again. Glad it wasn’t something I did.

okay, it is fixed I had to restart both mysql and tftp.

Thanks I am bookmarking the pages out of your signature.

Thanks, I will test this out incase this issue comes up again. My colleague was able to get a license from a reseller of the old application.

Also, I think changing this line will keep you from having to enter in the TFTP server IP manually into each workstation:

You have:
[CODE]pxe-service=X86PC, “Boot from network”, undionly.kpxe[/CODE]

Change to:
[CODE]pxe-service=X86PC, “Boot from network”, undionly.kpxe, <tftp-server-ip-goes-here>[/CODE]

Reference:
[url]http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html[/url]

Great that is what I was thinking, but got confused somewhere while researching.

Thanks!

Fedora 21 server videos coming soon.
I plan to cover installation & configuration, with a 2nd video about basic imaging.

@sebastian-roth This fixed my issue as well…set permissions to 777 🙂 I’ll tighten here in a minute.