Our company is getting ready to begin prep and testing for our Windows 7 migration from XP. We presently use KBOX for all of our Windows XP imaging, using a simple baseline image with drivers for each device type we support and then install all software and configurations in a series of post-install tasks so we usually only update our images if we want to refresh the drivers or OS patches.

We're a predominately Lenovo shop. Some Dell, but not a lot and moving away from it. We're also not usually high-volume imagers either. In a typical week we might build 5-10 machines.

I wanted to get some ideas of what processes are working for KBOX users who have already moved to Windows 7 in their company. Specifically things like:

* Using a more traditional captured/Sysprep'ed image vs. scripted installs
* Managing drivers and having a 'universal' image vs one for each device (especially if non-Dell).
* Tips or tricks for post-install tasks on Windows 7 that are different than they might be for XP.
* Managing default user profiles/configuration
* Including the 100 MB system partition or no (if not using BitLocker, etc.)
* Any other tips or tactic?

I'm not looking for a detailed how-to necessarily, but just an idea of how people are architecting their images or installs in KBOX 2000 for Windows 7 and why it works or what issues were encountered.

Thanks!

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
0

timantheos,

1) Deploying via scripted installation can make OS deployment quite quick, though default profile changes can be a little less intuitive, the decision between these two IMHO lies in the number of apps you've got to add in after deployment.  If you had more than 20 (in our case 150+ for education) I would go WIM, it will be faster to dump the lot down than install each application individually.

2) If you control your driver package installers well then you shouldnt have any trouble with bundling and deploying these. Remember you can usually use a vbscript to query machine model from WMI/BIOS and also from your K1 if you keep that information. This makes selective deployment of drivers easier.

3) Again, see point 1, this depends on the number of apps.

If you've only got a small SOE then this is a great starting point. Everyone has their own ideas as to what works best and usually thats based around their environments being completely different to everyone elses. I would only say that maybe the USMT is going a little far. We use it for our senior leadership team but apart from that we make staff and student data their responsibility if it isnt in their home drive, but that also can come down to policy.

My suggestion, try both the WIM and Scripted install method and see what will work best for you. Also K-Image is an option, this allows you to perform repair installs without formatting drives obsurdly quickly in some cases. If you format the drive though it'll be slower than the others.

Answered 03/12/2012 by: Roonerspism
Third Degree Brown Belt

  • Hello Gentlemen,

    I am new to Kace and so far I built an image that I would like to use it for different machine but for some reason when I drop the image on any  other machine drivers are not getting installed. Even after putting them in the correct path of the post_install foldel and recaching the drivers. If I drop the image on the model of machine I created with all drivers get installed. Can someone please point me to what I am missing.

    Thank You,

Please log in to comment
1

I'm still pretty early into this, but so far I'm wondering if an approach like this might work best. Especially given our largely non-Dell environment. The input so far has been good.

1. Deploy OS with a scripted install. Maybe or maybe not customize a WIM for default user settings, though I haven't looked into it enough yet to see what, if any, default user settings I might want to customize...vs. manage through Group Policy and KBOX scripts and post-install tasks?

Not sure yet about a 'pre-deployment' task with USMT to migrate user data off to a network and reapply later or do a local hard-link? The local approach sounds nice, but absent testing on our part yet I guess I'd be concerned about risk of data loss for anything that wasn't already on the network somewhere?

2. Create a bundle of required driver installers for each supported device and attach them to a batch file to install them as a post install task. Wondering if this will satisfy hardware independance or if a possible need for reboots or other activities before post-install tasks to install applications will cause a challenge?

3. Install applications as post install tasks.

Does this seem like a reasonable approach or am I making anything too difficult by going this way?

Answered 03/12/2012 by: timantheos
Orange Belt

Please log in to comment
0

* Using a more traditional captured/Sysprep'ed image vs. scripted installs
I use sysprepd images mainly because most of my computers are part of labs with unique and complicated software. A because i feel I get more control of whats going on.

* Managing drivers and having a 'universal' image vs one for each device (especially if non-Dell).
I'm running 3.3.5 and using the driver feed work around and its great with our dells. I keep one image for latitudes and one for dells, and a few other master images for some more legacy models running XP. With 3.4 though it looks like you can also load drivers for non-dells into the the driver feed so that's pretty cool.

* Tips or tricks for post-install tasks on Windows 7 that are different than they might be for XP.
Post install tasks sometimes wont work right if the machine hasn't restarted once after completing sysprep.

* Managing default user profiles/configuration
Sysprep guides will tell you to use the administrator profile to setup the default profile. While this is less than desirable to me, it's the way I've made things work.

* Including the 100 MB system partition or no (if not using BitLocker, etc.)
ewww no. I had to make that mistake and learn from it. The less partitions in your image the better. DISKPART is not very user friendly and not easy to automate. My district had an alarming varied amount of partition arrangements, especially with dell's oem partition. I came up with this solution to auto-handle any partition situation
http://itninja.com/question/how-to-wrap-a-.exe/.msi-installer-in-a-custom-.msi-packet1&mpage=1𕚭

* Any other tips or tactic?
On my one shot boxes, I have the K1000 user portal pop up after imaging where I can install more unique software packages without having to wait/break the image while it recompiles. I can have up to 6 different people imaging at once and i know they're not going to talk to each other, so the less I change the post install tasks the better.

Answered 03/08/2012 by: Tentacle Master
Third Degree Black Belt

Please log in to comment
0

The first suggestion I can give is 'dont image with the 100mb partition' it makes things much more finnekey with the K2.

Personally we use a WDS server to do our deployment on large installs because its quicker but we are starting to make the move to the K2 since the KNIT and 3.4 came out. Its starting to look a lot better with its ability to natively deploy WIMs now.

As far as Sysprepped Vs Scripted, that entirely depends on your situation. We here have an soe that is 37gb and has over 180 apps.  All are required for students and staff so scripted just is not an option for us. It would take days lol! But, scripted installs DO work for small setups, ie, a few of our boarding students just need office and win7 and it'll push in about 20 mins which is great.

We have a completely hardware agnostic image which works for 14 hardware types so far. Using a query from the K1 we pull the machine model and perform the driver install post drop so that we can use the one post install task from the K2 and when dropping with WDS we do the same, so its very fluid.

Remember if you're going to do a Sysprepped image, build it in audit mode. A great article on this is here: http://blog.brianleejackson.com/sysprep-a-windows-7-machine-%E2%80%93-start-to-finish-v2  (step 9 specifically)

Default user profiles etc are covered in the same blog.  If you're doing scripted installs etc you'll need to mod the OS directly.

My biggest tip is that no matter what imaging method you use, if you have a K1, I recommend thoroughly integrating it as much as possible into your imaging procedure.

Hope some of this has helped!

Answered 03/07/2012 by: Roonerspism
Third Degree Brown Belt

Please log in to comment
0

We migrated 250 machines to Win 7 at about that rate using a scripted universal Win 7 x64 image. (I'm not of big fan of ghosting - too much can go wrong)
This is on a mix of Dell models. The less variation in machines you have the easier it is.
You can tweak the setup XML to join the machine to the domain, named with the machine serial number and turn off UAC. Since the latest driver pack we only had to add a couple NIC boot drivers to be able to script a couple newer machines where the driver was missing. Get all the new drivers first.
Video drivers are the major issue, the correct driver is usually not installed, so this is a manual process after the OS. Not a big deal. There are some published work arounds, but I did not have success with those.
Our 'standard' image has post installs for all common software, Office, Acrobat, etc, the only thing that won't chain into the process is Symantec AV, so we have a managed install on the K1000 to target and install it on any machine that doesn't have it.
We keep it simple, so everything is formatted to one drive partition, we eliminate the Dell utility partition on the drive.
We have Windows update turned on by default, so there are usually about 80 updates in the queue after first boot, we run those before handing off the machine. I could probably slipstream those into the load, but haven't had time. If we overlook the Windows update, the K1000 delivers the critical patches automatically after the fact on the next patch schedule. We try and have them done before handing off the machine to the customer, as the updates can take awhile and we don't want complaints about a slow machine while all the updates install.
We aren't migrating profiles with USMT due to configuration effort, storage size and bandwidth constraints. User data migration is also a manual process. Someday I'll have time to work on USMT to automate that.

Answered 03/05/2012 by: mlathrop
Fourth Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity