Trying to understand best practice with FOG, Sysprep, and Windows 8.1



  • Hello friends. I’ve used FOG extensively in the XP days and have rarely touched it in the last two years or so. Given that what Windows machines we have today are 8.1 based, I got to wondering about some best practices with sysprep, as I have some questions. I already have my answer file built, but I’m trying to lay out in my mind how to handle this tomorrow, a month down the road, a year down the road, etc.

    Here’s the story. I have a base image with Windows 8.1 on a Lenovo E430. We’ll call it system A. I uploaded the image both before and after sysprep, so I basically have LenovoE430Windows8.1Base and LenovoE430Windows8.1Sysprep. It’s my understanding that for future “maintenance” when it comes to adding new updates to the image, I should deploy the non-sysprepped image, update it with Windows Update, then reupload as the sysprepped image. Okay, fine.

    But let’s say system A gets destroyed, or deployed, or for whatever reason I no longer have the exact system I built the image on. Let’s say I do however have system B, a totally separate system, but still identical hardware; Lenovo E430.

    Am I “okay” to deploy the non-sysprepped image to system B to pull down new Windows Updates? Or will I introduce issues? I would suspect that imaging system B with system A’s image, despite being identical hardware, would have some sort of Windows SID related issues. That being said, I would also suspect that once I run sysprep on system B and upload that as my mass deployment image, that I may very well rectify that issue as part of the sysprep process.

    What do you folks do in your environments and recommend for this situation? Maintain two images, one being my base image to add new things into, and then an identical sysprepped variant of that image to utilize for mass deployment? Is dumping the non-sysprepped image on a different (but identical hardware) system in the way I described okay to do?


  • Developer

    the option to resize partitions is done by simply choosing the “single disk - resizeable” Image Type. the rest is done automatically for you. i can’t remember if ext resizing is implemented in 1.2.0, but it is in the svn version that will become the next release.



  • I’m still tinkering around with FOG but I’m curious where that option is to auto expand partitions? Also, is this feature NTFS only, or will it work on EXT systems for Linux based images too?


  • Developer

    [quote=“VincentJ, post: 42606, member: 8935”]You can have windows expand the drive later.[/quote]

    or you can have fog expand it when you deploy it


  • Moderator

    by sysprepping it afterwards your making it a ‘blank slate anyway’

    I keep a Pre-Sysprep and a post sysprep to deploy.
    As for different hardware, any of my images will boot in almost all of my hardware (I have some really old stuff that isn’t 64 bit)

    No matter what I use the drivers are included.

    Something to watch out for… Make your master image smaller than your smallest HDD by a good chunk… not all HDDs that say the same size are actually the same. You can have windows expand the drive later.


Log in to reply
 

484
Online

39003
Users

10718
Topics

101766
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.