Many will want to rollout Win 8.1 on new hardware well before the expiry of XP in April 2014
-
I have files for Win8x32 also, they are similar except for activation is done with ADBA instead of KMS.
-
Thanks for sharing your information and files chad, I’ll look through them and see if I can learn anything form them too
-
[quote=“chad-bisd, post: 20978, member: 18”]With Windows 7 and Windows 8, it’s much easier to use Sysprep. I create images for each hardware platform as I have not yet figured out driverpacks. I have a sysprep answer file for Win7x32 and one for Win8x32, and a helper script that runs commands to copy my answer file and setupcomplete file, and to rearm Office 2010/2013 before running sysprep and shutting down the machine.[/quote]
Chad,
I’ve had much success, and easier to implement than Driverpacks, by extracting the Installers of drivers for the systems we have. Then I use a script:
[code]@echo off
net use z: \{NETWORKLOCATIONOFDRIVERS} domainpassword domainuseranddomain
for /r z:\ %%i in (*.inf) do pnputil -a %%i
net use /del z:
[/code]Anything that prompts with RED means it’s an unsigned driver and I DO NOT INSTALL as it will cause issues from a sysprepped machine.
Hopefully I’ve helped somebody.
-
Most of us like to continue with what we are most familiar with. I’m no exception.
I take warnings from others seriously. But Jaymes I think you are too quick to dismiss my own 9 years of experience in deploying XP in a domain environment. I’ve clearly demonstrated that sysprep was never “essential” for either Ghost or FOG XP deployments from and to identical hardware. So all the “warnings” I read in 2005 of the need to sysprep were not true for identical hardware. In the case of Win 8.1 today, sysprep may be essential, but maybe not on identical hardware again.My hope today was that I could save time by just doing the same as I did before, only this time with SIDCHG instead of NewSid.
I like having the administrator profile already setup with mappings and shortcuts etc. (helpful but not essential)
For the first user login I don’t know how to get past the OOBE window and go straight to the classic windows login window with user, password and domain fields. (I know the answer file can get you past most, if not all, of these setup questions, but I don’t look forward to sorting all that out. Chad you said yourself "
I know there will be other issues related to sysprep that I will have to come to terms with. It all takes time, research and questions on forums. I am replacing the entire system, PCs, iPads, wireless access points, server etc. I only work 60%. $300 is a small amount to pay to avoid even more hassle and uncertainty.Chad, I will only be using Win 8.1, 64 bit and Server 2012 64 bit, so your suggestion of active directory activation rather than KMS sounds better.
Jaymes, I have not heard of DeepFreeze. I’ll look into that.
Good advice when you write: “If you’re worried about the time it takes to get the answer file correct, set up a virtual image and save some snapshots before you sysprep, that’s what I do, then I just revert back, and edit my file a bit, save and upload again.” -
Ignor the half finished sentence:
" Chad you said yourself " "
-
Deepfreeze is a program that locks a station in a “frozen state” meaning any changes to the OS revert back to the original “frozen state” on each reboot. You can thaw a machine, make changes and then freeze it again if you like, I do so to update my windows image when the students leave for the day by installing Windows Updates from my WSUS. This keeps the students from moving my icons around and putting them in the trash can, the second I reboot my stuff comes back. So with that being said: It won’t affect much when it comes to imaging, just keeps your image clean after you push it out.
I understand your concerns with trying to use Sysprep, don’t take this the wrong way. I was never insinuating that my intelligence is higher than yours, just that I too have experience deploying Windows 7. I spent ALL of last year working on Windows 7 deployment, I know MANY ins and outs of it, but even I will not accept that I know EVERYTHING there is to know about it.
We are merely trying to prepare you for the journey ahead. You have expunged a lot of information from us regarding the process and how to complete it properly, it is ultimately up to you to decide how you image. We aren’t going to twist your arm, we are just trying to figure out if there is a volatile reason you want to avoid it like the plague, because we MAY actually be able to help you to work around it.
Either way, good luck.
-
[quote=“chad-bisd, post: 20978, member: 18”]With Windows 7 and Windows 8, it’s much easier to use Sysprep. I create images for each hardware platform as I have not yet figured out driverpacks. I have a sysprep answer file for Win7x32 and one for Win8x32, and a helper script that runs commands to copy my answer file and setupcomplete file, and to rearm Office 2010/2013 before running sysprep and shutting down the machine.
A high level overview of my procedure is:
- Start Windows setup, go until it reboots and asks for a computer and user name
- Hit ctrl+shift+f3 to restart in audit mode
- load programs, update local group policy
- shut down and take a pre-sysprep image, an “audit-mode” image
- push the image I just made to a second machine to verify it works and comes up in audit mode
- run my helper script that copies files, rearms office, and starts sysprep with the proper command line args.
- upload this to a new image as the “oobe image” for this hardware.
- set clients to use the oobe image and deploy
My FOG service is stopped and set to manual so it doesn’t try to rename/join domain while I’m loading software. My answer file has all the options setup so it doesn’t prompt for anything during the oobe prompt. My setupcomplete scripts activates windows and office either against KMS or against our AD (Active Directory Based Activation), sets the FOG server back to auto, starts the FOG service, and FOG then renames and joines the computer to the domain.
I have a checklist of software and settings that I can load for each platform depending on if it’s a student, teacher, or lab computer, and what campus it’s on. Since we use Deep Freeze to secure out student and lab computers (and some admins/teachers that like coupon printers and fake news websites) we cannot easily push out software after the machines leave the technology department.[/quote]
Chad,
At 3 of my schools I administer, I use Deep Freeze on all the Windows 7 machines. Updating and installing software has become so easy because of the remote console and all the features. Do you not use PStools in conjunction with Deep Freeze to deploy/update software?
-
Are you managing labs/desktop computers or 1-to-1 devices like laptops and tablets?
-
Chad I’m scrutinising with great interest your December 19 post and files you provided for me then.
You mentioned you had files for Win8x32.
Do you now have files for Win8.1x64 ?
I’m hopeless with scripting and need working files that I can modify.
I need to deploy in the next few days.
I have installed ADBA on server 2012-R2 and have activation objects for both Windows 8.1 and Office 2013. I will not be using a KMS host as I only have win 8.1 clients. Even if you have a Win8.1x64 unattend.xml, I may still have to make my own, but at least I can see what you have included or excluded.Grateful for anything you can provide and practical tips.
-
I do not currently have any Windows 8.1x64 clients that I deploy. All of our tablets that run Windows 8 are 2GB RAM, so no need for 64bit.
The main differences will be in the unattend.xml file, which is specific to 32 or 64bit. The sections and answers are almost the same, but have different paths (32/86 changes to 64). If you installed DISM and made an answer file, just look at the 32 bit one and answer the same questions with the same answers, just in the 64bit paths.
The setupcomplete script will remain almost untouched as will the CopyFiles-RunSysprep.bat, with changes made for filenames that changed.
-
Thanks so much Chad. Apparently with win 8, Microsoft recommends use of ADK which contains VAMT, WSIM (Windows system image manager), and other tools. So yes I have installed this package and have already checked out WSIM.
One remaining question which will sound strange: Your script includes:
“%programfiles%\Microsoft Office\Office15\ospprearm.exe”I know about the need to rearm Office in many situations, but is it really necessary here?
The reason I ask is because volume license versions of Win 8.1 and Office 2013 activated themselves on my new PC without me doing anything. The only thing I had done was install ADBA on my new Server 2012, and created activation objects for both Windows 8.1 and Office 2013. When my PC joined the domain, bingo! Will the same thing happen to the final Sysprepped teacher image when it is deployed to all the clients?I only ask because Office can only be rearmed, is it 5 times, so why do it if not necessary.
Have I missed something here? I’m not trying to be difficult, but I do like to understand why I need to do something in a certain way.
But if I don’t include the script, and they don’t activate, then I’ll be kicking myself. -
I have 2 images for each hardware platform I use (I don’t use driverpacks or golden images). One is audit mode before I run sysprep or rearm anything, the other is after I have run my rearm scripts and sysprep and shutdown. I use the audit image to update the base image, and the sysprepped image (in oobe) to deploy to hosts.
With that being said, all of my reading has led me to believe that in order for each office install to be unique, it must be rearmed before being deployed (cloned). I do this because I have windows 7 clients that must use KMS to activate in addition to the Windows 8/Server2012 clients that can use ADBA. I cover my bases. And with the rearm as part of the oobe image and not the audit image, I never run out of rearms because the base image never gets rearmed (only the image that becomes the oobe image for deployment).
-
I’m doing exactly the same as you: 2 images for 2 hardware platforms. (4 images - no driverpacks) One audit and one after sysprep. That’s why I’m keen to use your files as a guide. And you’re right of course, you’ll never run out of rearms because the base image never gets rearmed.
It’s strange that sysprep only resets identifiers in Microsofts Windows and not their Office. I suppose there’s a good reason.
Now I’ll have to bite the bullet on these scripts. They need to be Norwegianised too.
By the way I have discovered the following answer file command which looks very interesting. I haven’t noticed any references to this in the FOG forum:
Create an answer file to customize the default user profile
- Create a second answer file to use when you run Sysprep to generalize the Windows installation. This answer file contains the CopyProfile setting and is used to copy the customizations that you make in audit mode to the default user profile.
In Windows SIM, create a new answer file. To do this, click [B][FONT=Liberation Serif]File[/FONT][/B], and then click [B][FONT=Liberation Serif]New Answer File[/FONT][/B]. - Add the following setting to your answer file:
[SIZE=4][B] [/B][/SIZE]
Windows Image Component Path
Configuration Pass
Setting and Value
Microsoft-Windows-Shell-Setup
[B][FONT=Liberation Serif]4 specialize[/FONT][/B]
CopyProfile=[B][FONT=Liberation Serif]True[/FONT][/B]- Save the answer file as CopyProfileunattend.xml on the USB flash drive.
- Create a second answer file to use when you run Sysprep to generalize the Windows installation. This answer file contains the CopyProfile setting and is used to copy the customizations that you make in audit mode to the default user profile.
-
For the sake of clarity:
Windows Image Component Path = Microsoft-Windows-Shell-Setup
Configuration Pass = [B][FONT=Liberation Serif]4 specialize[/FONT][/B]
Setting and Value = CopyProfile=[B][FONT=Liberation Serif]True[/FONT][/B] -
You can use the copyprofile command if you want to setup a bunch of stuff and save it as the default profile. It works, mostly. But I ran into the case of most things I wanted to be part of the default profile were not included in the copyprofile specifications. Also, copyprofile has issues if you have more than one user profile on the base image, which you shouldn’t if you are using sysprep to create local accounts and audit mode to run everything as built-in\administrator. Remember that sysprep copies the profile and then deletes it and disabled the built-in\administrator account before going into OOBE.
-
Very helpful comments. Thanks.
-
Hi
Interesting discussion here, im a tech for schools too, im using a cloning software since many years (ghost or acronis) because this way we can have a bank of clone image readily available .
Win7 was ok with cloning, but since Win8, it happen they lose the trust approbation of the domain, so im trying to find a way to avoid this. I was not using sysprep since we can clone a pc and just change the name and add it to domain and its ready with a default profile, deepfreeze and BrowseControl, printers, softwares, icon on desktop, wifi…
I have found sysprep too much time consuming, adding info and using script… the other way, you just configure a station and clone it! easy and fast and could be done with multicast.
Now i have to think if we should buy the software for the newsid or take some time to get back into Sysprep. Thanks for all input, the sysprep explanation are very helpful since i have used sysprep many years ago… -
I would say go with Sysprep. Once you get comfortable with it, you should be able to automate your tasks whenever you do have to remake an image. I just don’t see paid products that do what sysprep does being worth the money.
-
[quote=“need2, post: 26701, member: 21891”]I would say go with Sysprep. Once you get comfortable with it, you should be able to automate your tasks whenever you do have to remake an image. I just don’t see paid products that do what sysprep does being worth the money.[/quote]
Even more so when Windows has offered sysprep for FREE and a kit to create your unattend.xml file.
-
just my 2 cents, personally - i couldn’t recommend sysprep more, we have one image per OS (under most circumstances) rather than per hardware and had to find this solution because we have over 30 models on our network (don’t ask!) so to have nearly 60 images to look after wouldn’t be feasible… can you imagine just having to install windows updates on each one!?!.. cringes
just to give you an idea of how i’ve set it up here (i understand this way doesn’t suit/work for everyone)
our image is stripped down and has minimal on it as possible, so it basically just has company branding, microsoft office on it and all windows updates, nothing else (unless it’s software that takes a long time to install or doesn’t change frequently etc…) - this is all built in audit mode. to keep unnecessary drivers etc off the image and keep image size as small as poss, i build the base image in VM also meaning i can just use snapshots for the “before and after” sysprep and if i want to update the image just fire up VM and revert to snapshot rather than deploying etc.
Then when the image task completes and before fog reboots this is what i get the init.gz to do.
- changes hostname in unattend.xml to that of the machine to match fog
- adds ad details into the unattend.xml if set to join in fog (domain, ou, account to auth etc etc)
- downloads drivers to disk for that specific model and OS you just deployed (drivers are stored in same directory as images on server/node and drivers are extracted into .inf form.)
- edits registry on machine to include the location of the downloaded drivers
- downloads software installers from server/node to the root of the disk (this way when machine boots up and is installing them, it’s running installers locally and don’t have to worry about “network traffic/auth” etc etc…)
so when the machine then boots up into sysprep, it’s got it’s unique details already and the drivers get installed as part of sysprep, it also eliminates the needed reboots to change hostname, add to domain etc or run any scripts post sysprep (apart from snapin!:)).
machine is set to autologin so logs in and snapin is set to lowest sleep time possible so it kicks off pretty much instantly and the snapin is just a small script with a gui (a pretty progress bar!) doing little changes, removing autologin, adding shortcuts here or there and installing those software previously pulled down from the server/node things like, adobe, java, AV, remote tool etc etc etc then finishes by removing installers, cleaning up, updating bios and reboots and it is then ready for the user to use.
doing it this way means i barely have to update my images, only for windows updates really. When new software comes out like adobe, all i have to do is update the installer on the server (also synchronizes across nodes) which means minutes work rather than having to update the images.
same goes for a new model - all i do is add the drivers for that model to the driver folder and presto! new model supported
takes around 15-20mins to build new machine from start to finish (ready for user to use) and there’s nothing for our engineers to do once imaging starts, so all in all only take 2/3 minutes of their time (to register machine and kick off image)
sorry for the long post just thought i’d share my setup too!
p.s. chad i could help you with the driver setup if you want but with recent development within FOG and upcoming/future plans might not need the assist, watch this space…
