Windows 10- moving from 1511 to 1607 in audit mode?
-
@mr626 said in Windows 10- moving from 1511 to 1607 in audit mode?:
Given that Microsoft have said that there will be at least a couple of anniversary updates for Windows 10 per year, I guess this means we’ll all be rebuilding our images a couple of times a year?
I wouldn’t be the guy to ask. At my old job (that I just left last week) we built all images 100% fresh and clean once per year and imaged everything every year because it was a school district with lots of available downtime in the summer.
If sysprep is giving you pains, it’s not absolutely necessary to use sysprep depending on your environment and # of models. Read through this post, it has a ton of information in it:
https://forums.fogproject.org/topic/8906/to-sysprep-or-not-that-is-the-question -
We rebuild our reference images from the beginning every quarter and install the latest OS and application updates. This is for Win7 and Win10. We use MDT to automate the process to make each quarterly build consistent. And yes you need to install 1607 from scratch and not upgrade 1511. If you use MDT then you can just copy your task sequence customizations between task sequences for each Win10 OS you choose to build. Its a little bit of a pain to do, but when a new anniversary update comes out, we just import the OS image into MDT, create a new task sequence for the new OS, and then copy and paste our custom sequences from the old OS to the new OS. It may take 15 minutes to setup a new MDT build for a new OS. But then it will build the reference computer using the light touch process (almost touch-less).
-
@george1421 said in Windows 10- moving from 1511 to 1607 in audit mode?:
We rebuild our reference images from the beginning every quarter and install the latest OS and application updates. This is for Win7 and Win10. We use MDT to automate the process to make each quarterly build consistent. And yes you need to install 1607 from scratch and not upgrade 1511. If you use MDT then you can just copy your task sequence customizations between task sequences for each Win10 OS you choose to build. Its a little bit of a pain to do, but when a new anniversary update comes out, we just import the OS image into MDT, create a new task sequence for the new OS, and then copy and paste our custom sequences from the old OS to the new OS. It may take 15 minutes to setup a new MDT build for a new OS. But then it will build the reference computer using the light touch process (almost touch-less).
Would you mind sharing the rough process that you follow for using Fog in conjunction with MDT?
I haven’t really used MDT much before, but it is sounding like I may need to.
-
@mr626 We will setup a VM to build our reference image. With MDT you have it build a boot ISO image to kickstart MDT on the reference vm. We transfer that mdt boot iso to our SAN where our VM hosts can access. Then we setup the VM Client to boot from that ISO image into MDT.
From there we are in MDT and select the MDT task sequence to build the reference image. We have several (many) custom task sequences to configure the reference image with our branding, and applications. Our applications are setup to do an unattended install in MDT. When the process is done we have a complete reference image with all of the changes we defined and the applications installed that are universal. You have to install GUID based applications like Anti-virus and other after deployment, but most applications can be installed directly in your reference image.
From there we then run sysprep and have sysprep power off the VM. Then we pxe boot the vm into FOG (the vm has already been registered). We have FOG capture the reference image and upload it into the FOG server for deployment. We don’t have to deal with the rearm or rearm count since we build the reference image from the beginning each time.
Since we have a universal image when fog deploys our sysprep’d image we also have a FOG post install script that copies the model specific drivers into the target image just after FOG copies the disk images back to the target computer. When the target computer boots it finds the drivers during OOBE and loads them.
-
@george1421 Thanks for the reply- that is how I would like to try and do it for us I think.
We have a lot of GUID based programs unfortunately, so will be interesting to see how many can be install into the reference image.
So just so I’m understanding you correctly, if I am following this guide:
the iso that you are loading in your VM is the one described in these steps? (under the sub heading 'Build the Windows 10 reference image):
Build the Windows 10 reference image
Once you have created your task sequence, you are ready to create the Windows 10 reference image. This will be performed by launching the task sequence from a virtual machine which will then automatically perform the reference image creation and capture process. This steps below outline the process used to boot a virtual machine using an ISO boot image created by MDT, and then execute the reference image task sequence image to create and capture the Windows 10 reference image.
Copy the E:\MDTBuildLab\Boot\MDT Build Lab x86.iso on MDT01 to C:\ISO on the Hyper-V host.
Note
Remember, in MDT you can use the x86 boot image to deploy both x86 and x64 operating system images. That’s why you can use the x86 boot image instead of the x64 boot image.Create a virtual machine with the following settings:
Name: REFW10X64-001
Location: C:\VMs
Memory: 1024 MB
Network: External (The network that is connected to the same infrastructure as MDT01 is)
Hard disk: 60 GB (dynamic disk)
Image file: C:\ISO\MDT Build Lab x86.iso
-
@mr626 you have to delete any other user profiles before you sysprep.
I use delprof2 for this:delprof2 /q /id:retsch /i NET USER retsch /DELETE del /F c:\windows\system32\sysprep\panther\setupact.log del /F c:\windows\system32\sysprep\panther\setuperr.log del /F c:\windows\system32\sysprep\panther\ie\setupact.log del /F c:\windows\system32\sysprep\panther\ie\setuperr.log net stop FOGService sc config FOGService start= delayed-auto del /F "C:\Program Files (x86)\FOG\fog.log" del /F "C:\Program Files (x86)\FOG\token.dat" rem cscript slmgr.vbs /cpky >nul rem cscript slmgr.vbs /upk >nul rem cscript slmgr.vbs /ipk VK7JG-NPHTM-C97JM-9MPGT-3V66T >nul rem Powershell.exe -executionpolicy remotesigned -File C:\Support\Tools\Checkpoint.ps1 rem reg import c:\support\tools\Checkpoint.reg rem reg import c:\support\tools\Productkey.reg cleanmgr /sagerun:1 c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /shutdown /unattend:c:\windows\system32\sysprep\unattend.xmlRegards X23
-
@mr626 Yes, while I use ESXi for virtualization that is pretty close to what we do. For the vm client we will create it with 4 vCPU just to speed up the windows update process but the rest is spot on.
For the MDT server we just use a desktop windows OS to host the MDT files and development environment. While you can do this all in one, we have a separate MDT server for Win7/2008 and Win10/2012. We use a similar process for creating our server vm templates (but FOG is not used for windows server template creation, that is all done in vSphere).
We do use /configure the administrator account (only account ever created on the reference image) exactly like we want the default user settings then in the unattend.xml file use the copyto option to have sysprep copy the administrators settings to the default user profile.
While its been a few years since we first started with MDT, it took me about 3 man days to go from knowing zero about MDT to being able to produce my first VM reference image. Then it was about 2 weeks to customize/perfect the task sequences to do exactly what we wanted. Now we select the proper task sequence and MDT does everything from building the image, installing all current wsus updates, installing the applications and patching. We don’t touch the reference image again until its time to sysprep and then capture the image with FOG.
-
The problem with Windows 10 is that the anniversary updates is not really an update. It actually reinstalls Windows on top of your current OS. So, you may not have intentionally done an upgrade, but the update actually performed an upgrade without your knowledge.
To confirm, if you look in your
drive, you should see a Windows.old folder.To get around this, you should be able to do a disk cleanup and remove previous windows installations. Once complete (and you verify the Windows.old folder is gone), you should be able to sysprep.
-
@george1421 Thanks for that, really appreciate it.
@Scott-Adams Thanks, am aware of it being more than just an update. Your suggestion about removing Windows.old to allow sysprep is interesting, however:
-I’m pretty sure sysprep still didn’t work for me even after removing windows.old (I remove it regardless if it exists as it is just taking up space)
-Even if it did work, you are still increasing the re-arm count@x23piracy Thanks, but I’m not sure what that has to do with what I’m taking about here. I’m fairly familiar with sysprep and what is / isn’t required.
-
@mr626 Try the following after clearing old Windows Installations:
Remove this KEY from the Registry:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup\UpgradeRemove this REG_DWORD from the Registry:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup\UpgradeSet this REG_DWORD from the Registry:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\CleanupState [Set Hexadecimal Value: 7]Run this command as Administrator:
slmgr /dliAfter your operating system is activated re-run SysPrep and it should work!
-
Like Scott said, you need to alter some registry keys after an upgrade.
Also, check if it didn’t sneakily create some new user.
But overall, I’d recommend simply installing a clean image.
-
@Quazz said in Windows 10- moving from 1511 to 1607 in audit mode?:
Like Scott said, you need to alter some registry keys after an upgrade.
Also, check if it didn’t sneakily create some new user.
But overall, I’d recommend simply installing a clean image.
I’ve also started from scratch instead of updating, would be the cleaner process while it’s generating more work but it’s worth it.
-
Thanks again for all the replies. I’ve started working on this and have made some progress.
Just wanted to check- what is the ‘best practice’ for Windows activation during the whole process?
For example, should I have the Windows image activated against a MAK key during the build process, and then reactivate against my KMS server when I actually deploy the image?
Thanks
-
@mr626 I won’t speak to best practices because each situation is different. But I can say what we do in our environment.
Our reference image is created by MDT, which you might already know. It is rebuilt each quarter with all of the windows updates, and applications. This reference image is never connected to AD or activated. You have 3 days to tweak the image (if necessary) before activation is required. If we miss the window then we just rebuild the reference image with MDT and keep tweaking. In the MDT build we just use the generic WinX key to allow reference image build.
You have 3 basic ways of activating your target image (not reference).
- In the unattend.xml file used to build your target system you can enter the product key right into the unattend.xml file.
- Back in the unattend.xml file, you can use the first logon section synchronous command (assuming you have an autoadmin login setup) to execute the following command
cscript //b c:\windows\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX - You can run the previous command also in the setupcomplete.cmd batch file.
We use option 2 in our setup for activation.
-
4th option - have the FOG Client activate windows for you. There’s a field for product key for every individual host. This is only useful if you’re using MAKs, but it is very useful in that situation. This is how I managed to activate Windows at my last job.
-
Maybe I am the only one who can’t figure this out, maybe I’m not and am too stupid to use Google. I have searched all over the place and can’t find what I am looking for.
I am trying to build our first Win 10 image for deployment. I can’t for the life of me find how to edit personalization settings without activating windows. Once in audit mode it tells me that I have to activate windows to personalize my PC. How are other handling this.
I have read of the win 10 thread on this forum, but this part is stumping me.
-
@adukes40 What exactly do you want to change?
A lot of what I do is move files manually (via a specifically written script for VM preparation in audit mode) and then run defprof program which will move those changes I made on the admin account (in audit) to the default account.
-
mainly backgrounds, colors, Lock Screens, and start menu.
-
@adukes40 I don’t know about all of them, but you can make a themepack on your current computer, activate that in audit mode, then run defprof and it should transfer everything that a theme can contain (background for sure, I think colors too).
Not sure what you want to alter about the start menu, if you mean rearranaging stuff and what not, I remember people having trouble with that, not sure if defprof is able to do that for you (mine remains default, so no experience there)
-
@adukes40 said in Windows 10- moving from 1511 to 1607 in audit mode?:
mainly backgrounds, colors, Lock Screens, and start menu.
The backgrounds, and colors can be set in the admin account, and then when you sysprep the system reference your unattend.xml file with the copyto setting in the unattend.xml file to copy the settings from the admin account to default user.
As for the start menu that one is a bit tougher and we are still struggling with that one. But basically you need to either create the perfect start menu on a test computer and then export the configuration to an xml file and then have it setup to that when a new user logs into a win10 system the exported menu xml file is imported into the user’s profile. You can also set a registry key to point to this xml file, but it restricts the user from changing/customizing their own menu.
