I think I solved it! We do currently have a .32 server in place as it has good images on it and I didn’t want to completely drop it and lose those unitil i knew that I had the New 1.1.2 server 100%. I was able to deploy fine with the .32 server but not the 1.1.2 but it looks like the problem was the NIC driver. installed the updated driver and all is well in the world of imaging, for me atleast. Ill just inject the new driver into the windows driver store so i don’t have to install it on all the machines after the imaging process

Yeah I figured there wasn’t really much of a way around it. Thanks!

Is this server pointing at another server to get information.

The exact link should [url]http://IPOFFOG/fog/client/FogPrep.zip[/url]

[quote=“Matt Harding, post: 11827, member: 1207”]I’ve had this problem before in the early days of me trying to deploy snapins and get my head around it… easy enough to fix if it’s the same problem I had with my snapins…

When you install the FOG service it installs itself and runs as a local system account… for some reason this doesnt work for me for everything… I just changed the user to local administrator on the service before I imaged… see the posted pic. Try that and see if it starts working.

Incidentally, is this the only snapin you’ve made that you’re struggling with or do they all do this?

Hope this helps anyhow.[/quote]

I came across the same problem when joining the client to a domain after imaging. It might be an individual security-dependency of the domain but your solution helped. Thanks for posting…

I figured out the issue, and I’m here to report I’m an idiot. 🙂

The original Windows Server 2012 installation had a 100GB system partition.

When I created the test VM, I used the default of 60GB for a system partition. My bad. The clues were there (Single Disk - Not resizable), I just missed them. If I could make a request: If the target partition is smaller than the source, can an error be sent to the screen, or logged to a file somewhere? It may have reported an error to the screen, but then it scrolls by very fast before rebooting. I’d like to thank both of you for your time in helping me with this issue! It looks like FOG will work very well for us in replacing Ghost.

[quote=“Jared, post: 32861, member: 25032”]I am having this issue as well. What is MPS? Lenovo ThinkpadT420[/quote]

Multi Partition Single Disk Its part of the disk type assignment for the image.

Okay, I got the problem fixed. The issue really was the script only applying the hostname change to the last partition restored. These are the steps I’ve done:

root@e21a101:~# cd /var/www/fog/service/ipxe/
root@e21a101:/var/www/fog/service/ipxe#
root@e21a101:/var/www/fog/service/ipxe# xz --decompress init.xz
root@e21a101:/var/www/fog/service/ipxe# mkdir initmountdir
root@e21a101:/var/www/fog/service/ipxe# mount -o loop init initmountdir
root@e21a101:/var/www/fog/service/ipxe# vim initmountdir/bin/fog.download

Then I added the changeHostname call to line 281 like the following:
268 elif [ “$imgType” == “mps” ]; then
269 parts=fogpartinfo --list-parts $hd 2>/dev/null;
270 diskLength=expr length $hd;
271 for part in $parts; do
272 partNum=${part:$diskLength};
273 echo " * Processing Partition: $part ($partNum)“;
274 sleep 2;
275 imgpart=”$imagePath/d1p$partNum.img";
276 if [ ! -f $imgpart ]; then
277 echo " * Partition File Missing: $imgpart";
278 else
279 writeImageMultiCast $part
280 fi
281 changeHostname;
282 done

root@e21a101:/var/www/fog/service/ipxe# umount initmountdir/
root@e21a101:/var/www/fog/service/ipxe# rmdir initmountdir
root@e21a101:/var/www/fog/service/ipxe# xz -z -9 -C crc32 init

That’s it. This way it works perfectly for me. But keep in mind this is a rather quick and dirty fix and only applies to distribution by multicast with a mps type image (Multiple Partition Image - Single Disk (Not Resizable) - (2))! So let’s hope that there will be a clean change to the repos that targets all type of distributions and images.

1.) This could be a registry error or possibly a driver issue. Some refurbishing companies are notorious for swapping a motherboard out with a “compatible” board. Yes the CPU and everything seems to be fine but the video card may be a different version (not talking model but version of BIOS on the video card).

2.) If you contact your Microsoft vendor and give them all your single licenses they will combine them up and give you a volume license for as many single licenses that you have. This will negate all the single licenses but now you have a useful volume license. Then, you can just load the volume license on the image and not worry.

Eureka!!! The storage management one got me. Thank you.

Any idea ?

I’ve seen this with a sysprepped image.

The profile isn’t properly removed, and isn’t valid for the new system. So, as the “new” system is created, it can’t create C:\Users\Administrator as it already exists, so it creates C:\Users\Administrator.<hostname>

It doesn’t hurt anything usually though.

I imagine you could make a script to reset the administrator info after login and delete the folder.

If you enter Audit mode and intend to sysprep, you can make all the changes you need. Then before running the sysprep command, you can upload the image to the Fog server and keep it safe and use it as a “back up” in case you need to revert to a point before you ran the generalize command.

A better solution is to build the image virtually and use snapshots and revert that way.

Either way, you will be able to make a back up before using the generalize command.

I only recommend using the skip re-arm when you are learning to set up your unattend.xml file. But then again using a snapshot, or keeping a back up on the fog server would also negate the need to skip re-arm.

Hope this helps!

Just make sure you don’t upload over top of the “Before” image O.O

are you using a multi partition single image? it shouldn’t expand on it’s own

Ok, well after setting up the computer back up, all is well and working like it is supposed to.

[quote=“Bcundiff, post: 31717, member: 22232”]This is where sysprep can be useful-- we use a master image with a ~40GB Windows install partition and then use ExtendOSPartiiton in the answer file to extend the C:\ drive to fill the remaining space in whatever drive the image is deployed to. The same answer file can also be used to make partitions, but that seems a bit riskier.
Sysprep’s generalize flag could also help with other hardware issues-- I’ve spent a few months working with Fog 0.32, Ubuntu 12.04, and W7 Pro x64 clients, and I’ve been able to get away without sysprep on occasion while testing, but, in my experience, sysprep /generalize really helped us deal with varying hardware, including things as trivial as getting an image from a 120GB drive to a 128GB drive.[/quote]

Hi, and thanks for your input.

I started to “play” with creating an image and sysprep last week.

I followed these instructions:
[url]http://fogproject.org/forum/threads/windows-7-deployment-fog-sad2-driver-tool.380/[/url]

and did this on a virtual box.

It went fine until “Step 8” (Drivers- SAD2). I did the suggestion at the end of Step 8 which says “you might want to try the tool out manually”. I did this and it updated a lot of drivers in the image on the virtual box. When it was all done, my network adapter was gone (i.e. without a driver) and several other critical path components too. I didn’t have more time to play with this, so I wiped it out and got a fresh image.

Do you follow these same procedures? Has this situation with drivers ever happened to you?

[quote=“Matt Harding, post: 8912, member: 1207”]If anyone is interested, I’ve put together a snapin to change the resolution on a PC. It uses 12noon’s Display Changer which is free for personal and educational use. I’m happy to share the information with anyone needing a windows 7 solution.[/quote]

I am interested in this snap-in. I am using Fog v.32.

How can I get this?

[quote=“Bronzli, post: 28203, member: 24373”]Hello,
I’ve just upgrade my fog server to 1.0.1 and have problème to boot the host under pxe!!!
few informations :
ubuntu 12.04 ; fog 1.0.1
service tftpd-hpa running
my fog config.php :
…
[/quote]

I run Fog under the same version of Ubuntu as you and in the past I have had PXE boot issues. I don’t remember exactly what all the symptoms were, but over time I have come up with this two line script and I just run this every time, first thing, after I reboot the Fog server… since I started this practice…never had any problems again:

sudo this file

start isc-dhcp-server
restart tftpd-hpa

Oddly enough, this problem fixed itself. All of the workstations are working just the way they are supposed to, no errors, images deployed just peachy. Going to chalk this one up to gremlins.

awesome, thanks i’ll try that!