This guide assumes that you use Microsoft Deployment Toolkit (MDT build 8443) or Microsoft System Center Configuration Manager (SCCM) capturing Windows 10.
You capture a task sequence, and the capture computer does not have Internet access. When the task sequence is running and the computer is checking for updates (pre-application installation), the installation freezes for 2 hours while searching for updates. After that, all approved updates are scrolled through and installed in seconds. But after several attempts, the process then fails and times out, and you receive error messages like the following:
Failed to download: 4816e53b-6f86-43c5-a740-0cafbe6317f5 result(4) : Cumulative Update for Windows 10 Version 1703 for x64-based Systems (KB4015583) ZTIWindowsUpdate 4/18/2017 4:15:59 PM 0 (0x0000)
Failed to download: f6df2191-75f3-445d-87b8-557ef2b3536c result(4) : Security Update for Adobe Flash Player for Windows 10 Version 1703 (for x64-based Systems) (KB4018483) ZTIWindowsUpdate 4/18/2017 4:15:59 PM 0 (0x0000)
Cause
This issue occurs when the computer is configured to use Windows Server Update Services (WSUS), but the computer tries to connect sls.update.microsoft.com for updates.
Resolution
To fix this issue, run the following command to set the download mode of Windows Update Delivery Optimization to bypass delivery optimization and use Background Intelligent Transfer Service (BITS) so that clients can use BranchCache:
If you have any questions on this guide or any feedback you would like to leave, please feel free to leave us a comment at the bottom of this page in our comments section.
We recently had put together a SCCM Build and Capture task sequence to update our images up to Windows 10 version 1709.
We copied the install.wim from the sources folder of the Windows 10 v1709 ISO and added this as our operating system capture image. We took our existing task sequence (which has lots of things in it like Office for example) and just pointed the Apply Operating System step at the new wim file.
We booted a fresh Hyper-V machine using PXE boot (using the Unknown Computers collection) and it booted straight into WinPE and found the task sequences available to the collection. So we selected the build and capture task sequence and let it run.
All seemed to be going fine; it partitioned the hard drive, applied the operating system, installed the ConfigMgr client, install the required applications and even ran through a Windows Update pass.
Then it all started to go wrong….
After rebooting itself to go into the Sysprep and capture steps, something strange started to happen. It ran through the Sysprep stage without any issue, rebooted itself back into WinPE and then started the capture phase – at which point it crashed and ended the task sequence unsuccessfully. We collected the logs and started the diagnostics head scratching. For reasons we could not explain, after the machine was Sysprep’d right at the end of the task sequence, once it had rebooted back into WinPE for the capture phase, it seemed as if the machine had lost its network connection. But how? its a virtual machine, it booted into WinPE at the first phase without any issue, its gone through the entire sequence working perfectly well – it surely cannot be a network issue – can it?
Diagnostic Investigation…
So, the investigation began. We checked the Cisco switches for all sorts of configuration checks (like IP helper, span tree etc…), we ensured the network card drivers were in the boot images and finally we hit F8 for a command prompt just as the capture step started and then, when the capture failed, we had a command prompt where we could carry out some quick checks. So, in the command prompt, we ran an ipconfig – no network connected, no IP, nothing. So, its the network connection – but it booted into WinPE using the same boot image and worked fine at the first PXE boot phase. This was driving us insane.
Always check the basics….
We started to then check that we had all the correct and up to date drivers in the boot image. We redeployed the boot image just in case, but still it kept failing at the capture phase. Then, after much Googling, we stumbled across a post about the new ADK for Windows 10 being released. So we checked our version and it had not been updated for a while so we went ahead and installed it and recreated our boot images. Once that had completed and distributed, we changed the task sequence to use the new boot image and PXE booted away. It loaded, it partitioned, it installed the OS, applications and Sysprep’d itself. Then rebooted back into WinPE – then the sight I never thought we would see – the capture step starts, then completes successfully.
Slightly infuriated with ourselves for not checking the basics first (like having the correct version of ADK!) but mostly chuffed to bits that we had finally sorted it, we deployed the new captured wim and started building a batch of new desktop computers. All of which worked perfectly!
So, the morale of story – always check the basics as most of the time, its the little things you overlook that are usually the problem.
Resources
For your information – below is the web ink for downloading the latest version (as of time of post) of the Windows 1709 ADK:
If you have started a task sequence in Configuration Manager and you hit a problem, the last thing you want to do is to have to go through the reboot process back into Windows PE.
So, if you want to just restart the task sequence without rebooting, carry out the following steps:
Press F8 to bring up the command prompt (which will also stop the computer automatically rebooting
Run the following command: X:\smsb\ini\386\TsBootShell.exe
You should now find that your task sequence has restarted.
Comments
If you have any questions or feedback on this guide, please feel free to leave us a comment below and we will try to get back to you as soon as possible.
If you are a regular user of downloaded CAB driver packs then you are probably using something like 7-Zip to extract them.
Well there is an alternative way of extracting the CAB file using a basic Windows tool.
Download your CAB file and make note of the file location. Then open a command prompt and go to the location of your CAB file:
Click to enlarge
Then type in the following command:
expand cabfilename.cab . -f:*
where:
cabfilename.cab = the name of the CAB file you want to extract
For this guide purposes we will use the Dell Latitude 5480 Windows 10 drivers:
Click to enlarge
Hit Enter and the process will start the extraction:
Click to enlarge
Once complete, it will show many files have been extracted:
Click to enlarge
You can then go and take a look in File Explorer and you should see the full extracted file structure now available to you:
Click to enlargeClick to enlarge
Video Demo
We have created a quick video demo on this process to go through the steps as above:
Comments
If you have any questions or feedback on this guide, please feel free to leave us a comment below and we will try to get back to you as soon as we can.
To inject Windows Updates into custom-built images that you are using in your Configuration Manager OSD environment, you may find that keeping them up to date is a real problem. If you are happy with the image itself and do not want to make any changes to it, why should you need to rebuild and recapture it to include all the latest Windows Updates?
One solution is to install Windows Updates during your OSD task sequence which is great, but very time consuming if your image is a few months (in some cases years!) old.
However, there is a way of injecting Windows Updates into your custom WIM files offline and then simply redistributing your WIM file to your local and remote distribution points. You used to have to install WAIK to do this, however, as Windows 10 has DISM built into it, you can now simply use your standard client Windows operating system and take advantage of a little PowerShell scripting.
Below is the guide on how to carry this out and a list of downloads that you will require.
STAGE 1 – Download required offline Windows Updates
Download the WSUS Offline Tool from the link above and extract the zip file to a directory on your computer – for this guide purposes, we will use “D:\WSUS” (although most people will use a C: drive location).
Run the “UpdateGenerator.exe” file located in the root of extracted files.
You will be presented with a program and you can select the versions of Windows, Office and Legacy products that you wish to update. Remember to include (or exclude) the x86 and x64 versions if you want to update these different architectures.
You also have the option to use a WSUS server on your local network to retrieve the Windows Updates from (this is much quicker if you have a slower internet connection). To do this, click the WSUS button at the bottom and enter the URL of your WSUS server:
If you wish to download all the available updates from Windows Update server, do not enter any information into this setting.
Once you have selected all the options that you want to download updates for, press the Start button at the bottom left. A command box will appear and will start to download all the required updates – this can take a long time depending on your selections and internet speed. These updates will be copied into the folder structure of the extracted files (“D:WSUS”).
Please note that although the first set of downloads will take a while, you can then run this process again at a later date and it will only download any newer updates required. This way you can keep an up to date repository of offline Windows Updates.
Once all your updates have been downloaded, you should then continue with the next stage of the process.
STAGE 2 – Inject Windows Updates into your WIM file
You should copy your WIM file to a location on your Windows 10 client machine, for this guide, we will use “D:\WIM”.
You then need to create a temporary directory that will be used to mount the WIM image, we will go ahead and use “D:\WIMTEMP”.
You then need to ensure that you use the correct index number by running the following command:
dism /get-wiminfo /wimfile:D:\WIM\wimname.wim
As you can see from the above image, the index we need to use for this process is “index:2” – however this can change depending on how you have created or captured your WIM file so you should always check this first before trying to mount a WIM file.
PowerShell Script
You then need to open your Windows 10 Powershell ISE program and enter the below code into the editing box:
#Add your own variables below $UpdatesPath = “D:\WIM\wsusoffline108\wsusoffline\client\w61\glb*” #Path to the offline updates folder for the image OS (in this case Windows 7 x86) $MountPath = “D:\WIM\Mounted” #Temporary image mount folder $WimFile = “D:\WIM\Original\Win7x86\Win7x86.wim” #Source of image WIM file $IndexNumber = “1” #Image Index Number #Start of WIM mount process DISM /Mount-Wim /WimFile:$WimFile /index:$IndexNumber /Mountdir:$MountPath #Start of updates injection $UpdateArray = Get-Item $UpdatesPath ForEach ($Updates in $UpdateArray) { DISM /image:$MountPath /Add-Package /Packagepath:$Updates Start-Sleep –s 10 } Write-Host “Updates Applied to Mount Image” #Start of space saving on mounted image DISM /online /Cleanup-Image /StartComponentCleanup DISM /online /Cleanup-Image /StartComponentCleanup /ResetBase DISM /online /Cleanup-Image /SPSuperseded Write-Host “Image Space Saving Completed” #Start of unmount of mounted WIM file DISM /Unmount-Wim /Mountdir:$MountPath /commit #Start of cleanup on WIM file DISM /Cleanup-Wim
Alternatively you can download the PS1 file using the button below:
You should now edit the variables at the top of the script to match your own settings, ensuring that you are using the correct directory within your earlier downloaded updates for your WIM file. So, if your WIM file is Windows 7 x64, you should go to:
D:\WSUS\client\w61-x64\glb
If your WIM file is Windows 7 x86, you should go to:
D:\WSUS\client\w61\glb
If your WIM file is Windows 8.1 or Windows 10 x64 you should go to:
D:\WSUS\client\w63-x64\glb
Once you are happy with all your variables, run the PowerShell script and this will then run through the following process:
Mounts the WIM file to your temporary location
Searches for all available updates for your WIM files
Injects all updates into your WIM file
Cleans up the image as much as possible included the WinSXS folder
Unmounts the image
Runs a WIM cleanup on the file
Completed
Your newly updated WIM file can then be redistributed using your Configuration Manager environment.
Comments
If you have any problems with this or have any questions at all, please use our comments section below.
So today we built a new custom Windows 10 image on a virtual machine and created our new SCCM capture media from the very latest version and every single time we ran the capture it failed at the Sysprep step.
Infuriated by this as we have done captures hundreds of times, we started the annoying method of going through the log files. As the capture was failing at the sysprep part we knew to take a look at the sysprep error logs first which can be found in this location on your machine:
C:\Windows\System32\Sysprep\Panther
You should see a file called something like setuperr.log – look in here and you should find the reason for the system prep failure.
Amazingly, in our case, it was the pre-installed Twitter and Candy Crush Windows Store Apps that were causing the problem. So, we uninstalled these and tried again – there you go, capture went through without any issues and worked perfectly.
Feedback
If you have any questions or comments, please feel free to leave us a message below using our comments system below.
We have been looking into getting our OSD process to automatically change the computer name to what we want it to be for a while now but never really had much luck with it.
Reading various forums and blogs, many people have said to use WSNAME and many others saying use scripts, all of which never seemed to quite work for us.
What we wanted was a three letter prefix with the serial/tag number of our machines. Most of our machines (99%) are Dell’s and we wanted to use the 7 digit asset tag with a 3 letter prefix but things like the WSNAME only seemed to work with our HP’s using the %SERIALNUM% variable. Using this method, all our Dell machines were reporting the %SERIALNUM% as blank, so instead of:
ABC6TQX8X1
It came out as just:
ABC
Not really much use!
So, we decided that we really needed to spend some time on this and get it working once and for all. After actually dedicating some time to it instead of just messing about with it for five minutes here and there, we finally got it working.
For those of you that know MDT, we used this with a mixture of Gather and Set Task Sequence Variable. Tested it, works a treat!
So, a quick how to guide for those wanting to know how to do it as we have really struggled to find a simple step by step guide to doing such a simple task.
First of all, you need to have MDT installed which you can download from here:
You also need to make sure that you have ConfigMgr integration working, please note that this guide does assume that you have MDT fully up and running to use in your Task Sequences within ConfigMgr….if you need to know how to get this to work, leave a comment at the bottom of this post and we will look at getting a guide uploaded for doing that….
Edit your selected Task Sequence and just after the “Deploy OS” step, add your “Use MDT Package” step.
Then, directly after this step, add the “Gather” step and set it to “Gather only local data (do not process rules)
Then, the final bit which applies the computer name, add “Set Task Sequence Variable” then make sure that the Task Sequence Variable is set to OSDComputerName. The value can be whatever you want it to be, the standard is:
%SERIALNUMBER%
This will set the computer name as the, you guessed it, Serial Number.
If you want to customise it slightly, just add the text before the %SERIALNUMBER%, so as an example:
ABC%SERIALNUMBER%
Save your task sequence and it should work.
Few things to remember that are very important, this part must be added AFTER the Deploy OS step, but also BEFORE the Apply Windows Settings step.
Comments
If you have any problems please use our comments system below to leave a comment and we will get back to you as soon as we can.
You may have seen our previous post about adding a local user to a machine during SCCM OSD using a “Run Command Line”. Well in this guide we will show you how to add a local user into the Administrators Group on the local machine. This means that you can add a local user and then make them a local administrator all within the SCCM OSD task sequence.
Instructions
You will need to add a “Run Command Line” step towards the end of your task sequence ensuring it is after the Windows deployment and the ConfigMgr Client installation.
Then, you should use the following command:
cmd.exe /c net localgroup "Administrators" "LocalAdmin" /add
The details for what each part of this command line mean are below:
cmd.exe /c – required to run a successful command
net localgroup – command line to make amendments to local groups
“Administrators” – the name of the local administrators group
“LocalAdmin” – the name of your local user account
/add – to add the stated user to the stated localgroup
When you have finished, your step should look something like this:
Now, when you run through your task sequence, this will run the command line and add your stated user to the local administrators group.
If you want to run this with also creating a new local user, ensure that you have this step after the create local user step or it will fail.
Comments
If you have any questions about this guide, please feel free to leave us a message below using our comments system.
If you want to add a local machine user to your deployed machine during your SCCM OSD process then you can do this using a standard “Run Command Line” step.
Guide
So, you need to add a “Run Command Line” step in your task sequence towards the end, after the Windows deployment and after the ConfigMgr Client install. You should then give it a meaningful name and use the following command line:
cmd.exe /c net user LocalAdmin Pa55w0rd# /add /comment:"Local Admin Account" /expires:never /fullname:"Local Admin Account"
Each of these parts are detailed below and can be changed to your own requirements:
cmd.exe /c – required to run a successful command
net user – run the “net user” command
LocalAdmin – name of the local admin account you want to create
Pa55w0rd# – the password of the local admin account you want to create
/add – to add the user
/comment:”Local Admin Account” – this is the description of the local account
/expires:never – means the account will never expire (note account NOT password will never expire)
/fullname:”Local Admin Account” – full name details for the local account
When you have completed this, you should have something that looks a little like this:
Now when the task sequence runs through it will run this command and add the local user. Note that this will add the user add a “Standard” user, if you want to then make this user (or any other local user) as a local administrator then take a look at our guide for this here.
Feedback
If you have any feedback about this guide, please feel free to leave us a message below using our comments section.
If you are using SCCM for your operating system deployments across different countries, then you may want to set the time zone within the task sequence.
To do this, you can take advantage of the built in Windows tool call tzutil.exe.
In this example we will set the time zone for a computer deployment based in Amsterdam, The Netherlands which is Western European Standard Time (GMT +1).
Towards the end of your task sequence and after the Apply Image and Install ConfigMgr Client steps, add a Run Command Line step. Then give it a descriptive name. Add the following code for the command line:
cmd.exe /c tzutil.exe /s “W. Europe Standard Time”
You will also need to set the Start In as C:WindowsSystem32
So, when you have completed the step, it should look like this:
If you want to use a different time zone, you can see the full list (and correct command to use) by typing the following command in a command box on any Windows machine:
tzutil.exe /l
COMMENTS
If you have any questions on this guide then please feel free to leave a message below using our comments system.
If you have recently upgraded your SCCM to version 1511, you will have had to have upgraded your ADK to the Windows 10 version. However, did you first note down your customisation and network card drivers that you had in your boot image? If not, you will now find that those tabs are missing.
So, you will end up with your previous/current boot image looking like this:
SCCM Boot Image Missing Tabs
We have simply recreated our boot images as we had everything documentated but if you are looking for a fix, then you could try this guide for help:
