Hi,

you can also integrate office updates into the installation,
download needed update files, extract them and place the msu file in the office updates folder:

[IMG]http://i.imgur.com/7WbPihg.png[/IMG]

To automate office installtion use config.xml

[CODE]<Configuration Product=“ProPlusr”>
<Display Level=“basic” CompletionNotice=“no” SuppressModal=“yes” AcceptEula=“yes” />
<USERNAME Value=“Bla” />
<COMPANYNAME Value=“Bla2” />
<!-- <INSTALLLOCATION Value=“%programfiles%\Microsoft Office” /> -->
<!-- <LIS CACHEACTION=“CacheOnly” /> -->
<!-- <LIS SOURCELIST=“\server1\share\Office;\server2\share\Office” /> -->
<!-- <DistributionPoint Location=“\server\share\Office” /> -->
<!-- <OptionState Id=“OptionID” State=“absent” Children=“force” /> -->
<!-- <Setting Id=“SETUP_REBOOT” Value=“IfNeeded” /> -->
<!-- <Command Path=“%windir%\system32\msiexec.exe” Args=“/i \server\share\my.msi” QuietArg=“/q” ChainPosition=“after” Execute=“install” /> -->
</Configuration>[/CODE]

It can happen that your office doesn’t have the admin folder then you cannot run setup.exe /admin,
then you will need to download adm templates for the desired office version, extract them and place
the admin folder in the office install folder, after that setup.exe /admin will work.

[IMG]http://i.imgur.com/3JO0yyD.png[/IMG]

[IMG]http://i.imgur.com/rQlRDnb.png[/IMG]

[url]http://www.microsoft.com/en-us/download/details.aspx?id=35554[/url]

[IMG]http://i.imgur.com/9lY72l2.png[/IMG]

Regards X23

I like your idea of booting into a pre-boot environment to do minor changes; however it seems like you are taking are hard approach at doing this when you could be creating your image with virtual box using snapshots at each major step so if you miss something or mess something up you can just revert the snapshot. Its still a timely and daunting process to create an image this way but it takes out the headaches of having to start from scratch each time. Then each time you think you have it right or after each modification you simply upload your new image over your old one.

I agree with adding UEFI support. something I’ve really been needing a full dd should work so I’m thinking if it’s possible to check where partition nr 3 starts (win7 / 8.x) then make a dd image from zero to the start of partition nr 3, then treat partition 3 as a “multi partition disk, no resize”

Not to confuse anyone i will start a new thread as i go because they are different threads

please see [url]http://fogproject.org/forum/threads/uefi-vs-legacy-bios-gpt-vs-mbr-single-partition-resizable-vs-multiple-partition-notresizable.11124/[/url]

Since FOG does not fully support UEFI i suggest just to disable this feature in the Bios before even installing the OS. If someone can * make it work with no issues with UEFI please share it so that i/we can understand it better.

[quote=“need2, post: 25853, member: 21891”]Are you sure the user data isn’t just in a deprecated user folder? Such as C:\Users\gobbledegook[/quote]

Late reply sorry, bu yes the files would have been under Mrs. Gobbledegook’s user files, however not all users save to just that location so I like to run full backups.

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.