Deploy of Windows 7 (64 bit) and image types and image sizes

mkstreet

I’ve looked at this forum, Fog wikis/guides, and other sites that google found for me.

There seems to be a lot of different and often conflicting information out there, often posted at different times over the past 3 years.

I’d like to get clarity in one place of the current information…

Here are my technical details:
Fog Server: vers 0.32 under Ubuntu 12.04

Deploy boxes:
Windows 7, 64-bit

 Image computers (and most deploy computers) have:
 Windows HDD configuration:  C drive (about 130 GB) and D drive (about 170 GB)

 fdisk shows 3 partitions
  /dev/sda1   boot partition,  partition type ID 7 "htt... something"
  /dev/sda2                         partition type ID 5 "extended"
  /dev/sda5                         (logical partition that matches dimensions of /dev/sda2), partition type ID 7

To the questions/issues…

When I create my image, I don’t run sysprep and I don’t run chkdsk… but I’ve successfully deployed to about 50 computers (although those computers were identical in every way). Am I missing doing an important step(s) such that I should use sysprep and/or chkdsk?
When I create the image, I’ve not gotten image type of NTFS resizable to work (upload). I have successfully created, and deployed, both multi-partiion single disk (not resizable) and multi-partion all disks (not resizable). I’ve seen older information suggesting that NTFS resizable wont work with Windows 7. Am I doing this correctly to NOT use NTFS? This leads to my next two items (#3 and #4)… [I also saw older comments saying that they had used multi-partition single/all disks RESIZABLE – but this isn’t an option in my Fog vers – I am guessing this resizable was there before and is deprecated now?]
It seems to be the case that the target computer’s partition table entries need to exactly match the image creator’s partition table…or the deploy won’t start. I think there have been some cases where the target computers partitions are larger and that seems to work. I thought that as long as the data of the partition was smaller than the defined partition that it would deploy? I’d read some comments to the effect that Windows 7 would work this way even with not resizable images (that Windows 7 would resize even though the image type is not resizable).
I’d like to make an image that is more hardware independent as far as HDD partition sizes… how can this be done (if it can be) with Windows 7 and the image types available?
Some of my computers run in a static IP environment and they have no issues with their wired ethernet connection after a deploy. However, I have noticed that dynamic IP/dhcp environment computers have two issues after a deploy causing the ethernet LAN connection to not work. First, Windows tells me that “network sharing and discovery is turned off” – where I am sure it must have been ON in the computer I imaged. So I don’t know how this got turned off. Second, after I turn network sharing/discovery on, the ethernet connection shows a “Default Gateway IP” (and I think also the DHCP server IP) with the value of the Fog server’s IP address. Is there a setting I have wrong on this?

Thanks!

mkstreet

[quote=“mkstreet, post: 30796, member: 24215”]

Some of my computers run in a static IP environment and they have no issues with their wired ethernet connection after a deploy. However, I have noticed that dynamic IP/dhcp environment computers have two issues after a deploy causing the ethernet LAN connection to not work. First, Windows tells me that “network sharing and discovery is turned off” – where I am sure it must have been ON in the computer I imaged. So I don’t know how this got turned off. Second, after I turn network sharing/discovery on, the ethernet connection shows a “Default Gateway IP” (and I think also the DHCP server IP) with the value of the Fog server’s IP address. Is there a setting I have wrong on this?

[/quote]

OK I think I have found at least part of the problem on #5… there are two profiles: 1) Home/Office – with Network Discovery turned ON… but also 2) Public – where it is turned off. The newly imaged machines don’t know they are part of the Home/Office and use the public profile.

Tom Elliott

[quote=“mkstreet, post: 30796, member: 24215”]1. When I create my image, I don’t run sysprep and I don’t run chkdsk… but I’ve successfully deployed to about 50 computers (although those computers were identical in every way). Am I missing doing an important step(s) such that I should use sysprep and/or chkdsk?[/quote]
Sysprep is useful for many reasons. It won’t hurt “not” to do it, but it won’t hurt to do it either. In the case of mass imaging (as fog is intended), it’s useful especially for Volume Licenses. That said, it’s not a necessity UNLESS::

[quote=“mkstreet, post: 30796, member: 24215”]2. When I create the image, I’ve not gotten image type of NTFS resizable to work (upload). I have successfully created, and deployed, both multi-partiion single disk (not resizable) and multi-partion all disks (not resizable). I’ve seen older information suggesting that NTFS resizable wont work with Windows 7. Am I doing this correctly to NOT use NTFS? This leads to my next two items (#3 and #4)… [I also saw older comments saying that they had used multi-partition single/all disks RESIZABLE – but this isn’t an option in my Fog vers – I am guessing this resizable was there before and is deprecated now?][/quote]
NTFS Resizable without Sysprep never worked with 0.32, only Sysprepped Windows 7 could be NTFS Resizable. FOG 1.X.X, brought this ability however. It is assuming, (just so you understand) a clean base install of Windows 7, either single part (all the disk is used for C:) or 2 part (100MB Recovery and the rest for the C:). This same principle exists as well for 0.32 (but again only if the system was sysprepped will it boot.)
[quote=“mkstreet, post: 30796, member: 24215”]3. It seems to be the case that the target computer’s partition table entries need to exactly match the image creator’s partition table…or the deploy won’t start. I think there have been some cases where the target computers partitions are larger and that seems to work. I thought that as long as the data of the partition was smaller than the defined partition that it would deploy? I’d read some comments to the effect that Windows 7 would work this way even with not resizable images (that Windows 7 would resize even though the image type is not resizable).[/quote]
This is wrong. The mbr file contains the Partitioning layout. In Multi-part (single or all) disk images, the MBR is backed up with the image. It is this MBR that get’s written to the hard-drive. The MBR contains the partitioning layout, and as such, the specified HDD Partition Sizes, this is where the image “fails” because the Partition is larger than the disk can handle. If the drive is the same or larger size as what the partitions are based on, things run fine, if the drive is smaller, it doesn’t know how to deal with the data.
[quote=“mkstreet, post: 30796, member: 24215”]4. I’d like to make an image that is more hardware independent as far as HDD partition sizes… how can this be done (if it can be) with Windows 7 and the image types available?[/quote] SYSPREP and Driver injecting!
[quote=“mkstreet, post: 30796, member: 24215”]5. Some of my computers run in a static IP environment and they have no issues with their wired ethernet connection after a deploy. However, I have noticed that dynamic IP/dhcp environment computers have two issues after a deploy causing the ethernet LAN connection to not work. First, Windows tells me that “network sharing and discovery is turned off” – where I am sure it must have been ON in the computer I imaged. So I don’t know how this got turned off. Second, after I turn network sharing/discovery on, the ethernet connection shows a “Default Gateway IP” (and I think also the DHCP server IP) with the value of the Fog server’s IP address. Is there a setting I have wrong on this?

Thanks![/quote]My guess is it’s due to, as you described above, being a “Public” network. This isn’t a problem in and of itself, but probably related to when the system boots for the first time after it’s been imaged. While the hardware (driver wise) may be the same, the hardware itself is completely different. So while the image still thinks it’s activated, it’s essentially a brand new system, therefore a new network interface which would default to public.

mkstreet

[quote=“Tom Elliott, post: 30893, member: 7271”]Sysprep is useful for many reasons. It won’t hurt “not” to do it, but it won’t hurt to do it either. In the case of mass imaging (as fog is intended), it’s useful especially for Volume Licenses. That said, it’s not a necessity UNLESS::

NTFS Resizable without Sysprep never worked with 0.32, only Sysprepped Windows 7 could be NTFS Resizable. FOG 1.X.X, brought this ability however. It is assuming, (just so you understand) a clean base install of Windows 7, either single part (all the disk is used for C:) or 2 part (100MB Recovery and the rest for the C:). This same principle exists as well for 0.32 (but again only if the system was sysprepped will it boot.)
[/quote]

What is the definition of the term “clean base install of Windows 7”? I think everything in my environment is derived from a copy of something else, and then modified. I don’t have a virgin HDD nor an official O/S CD-ROM to install with from scratch…

That said, it seems our shop has already violated the second stipulation since we have a C and D drive because we keep the C drive frozen (with deep freeze) and students are allowed personal files on the D drive as a “common space”.

So, given our configuration of C and D drives, even with sysprep, we won’t be able to resize it. Does that seem correct?

[quote=“Tom Elliott, post: 30893, member: 7271”]
This is wrong. The mbr file contains the Partitioning layout. In Multi-part (single or all) disk images, the MBR is backed up with the image. It is this MBR that get’s written to the hard-drive. The MBR contains the partitioning layout, and as such, the specified HDD Partition Sizes, this is where the image “fails” because the Partition is larger than the disk can handle. If the drive is the same or larger size as what the partitions are based on, things run fine, if the drive is smaller, it doesn’t know how to deal with the data.
[/quote]

I will have to look at this again, but I have had many examples in the past week where the machine wouldn’t load.
Then, after I did a Fog deploy-debug boot, I manually setup the partition table to match the image computer’s partition table (using fdisk), the deploy would run successfully right away.

The Fog inventory (at least under Fov v0.32) doesn’t seem to show the HDD sizes. If I could easily find that out, I would find the smallest drive machine and make my image on that… because then it would fit into all the bigger ones.

mkstreet

[quote=“Tom Elliott, post: 30893, member: 7271”]
This is wrong. The mbr file contains the Partitioning layout. In Multi-part (single or all) disk images, the MBR is backed up with the image. It is this MBR that get’s written to the hard-drive. The MBR contains the partitioning layout, and as such, the specified HDD Partition Sizes, this is where the image “fails” because the Partition is larger than the disk can handle. If the drive is the same or larger size as what the partitions are based on, things run fine, if the drive is smaller, it doesn’t know how to deal with the data.
[/quote]

FYI. I had this situation again on Friday. A PC with the same size HDD as the image was created with… I tried to deploy and it stopped right away. It tried to reboot and wouldn’t saying “missing operating system”. So something was attempted and erased something important. I then had to re-PXE boot in deploy-debug. I used fdisk to setup the partitions exactly the same as the machine the image was made on, typed FOG and the deploy happened without any further complaints or issues.

Tom Elliott

[quote=“mkstreet, post: 31062, member: 24215”]FYI. I had this situation again on Friday. A PC with the same size HDD as the image was created with… I tried to deploy and it stopped right away. It tried to reboot and wouldn’t saying “missing operating system”. So something was attempted and erased something important. I then had to re-PXE boot in deploy-debug. I used fdisk to setup the partitions exactly the same as the machine the image was made on, typed FOG and the deploy happened without any further complaints or issues.[/quote]

Same is is respective. Many times, drives are not Identical from one make or model. For example, a Seagate 80GB Hard drive and a Western Digital 80GB Hard Drive may not be of the “exact” same size. I’m not saying this is or isn’t the case for your situation, and I don’t know exactly what’s going on.

I only intended to give you information, not tell you your methods were wrong or anything.

FOG 0.32 had issues with non-initialized Drives in the past, and possibly still does under 1.x.x though I’ve made many things to try to thwart that.

mkstreet

[quote=“Tom Elliott, post: 31064, member: 7271”]Same is is respective. Many times, drives are not Identical from one make or model. For example, a Seagate 80GB Hard drive and a Western Digital 80GB Hard Drive may not be of the “exact” same size. I’m not saying this is or isn’t the case for your situation, and I don’t know exactly what’s going on.

I only intended to give you information, not tell you your methods were wrong or anything.

FOG 0.32 had issues with non-initialized Drives in the past, and possibly still does under 1.x.x though I’ve made many things to try to thwart that.[/quote]

I understand, and thanks for your answers and also the efforts on 1.x.x.

I think I was kind of spoiled with Fog in my first experience of it, two months ago. At that time, we used it to deploy to 35 machines which were purchased together for a computer lab. So, they are 100% the same. Once we got Fog setup, the issues with those were minimal.

Now, because of the success with those 35 in that lab, we’ve been tapped to work that Fog magic with the library and resource rooms, where we have a more rag tag situation of 3 different hardware configurations, purchased at various times.

So now when things happen – like this HDD deploy issue mentioned here – we don’t know if we are doing something wrong, or what the cause of the difficulty is because the lab deploy was so smooth and easy.

Bcundiff

[quote=“mkstreet, post: 30796, member: 24215”]

It seems to be the case that the target computer’s partition table entries need to exactly match the image creator’s partition table…or the deploy won’t start. I think there have been some cases where the target computers partitions are larger and that seems to work. I thought that as long as the data of the partition was smaller than the defined partition that it would deploy? I’d read some comments to the effect that Windows 7 would work this way even with not resizable images (that Windows 7 would resize even though the image type is not resizable).
I’d like to make an image that is more hardware independent as far as HDD partition sizes… how can this be done (if it can be) with Windows 7 and the image types available?

Thanks![/quote]

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.

mkstreet

[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?

Deploy of Windows 7 (64 bit) and image types and image sizes

235

11.7k

17.1k

154.6k