anyweb

sorry to hear it guys i'll take a look at the permissions and post back.

restart the SMS_Executive component using the configuration manager service manager

hi Chris after looking at your logs your error is not the same as Par's i'll see what i can find out but please contact me as you mentioned this morning so we can decide how to troubleshoot it, do you have any possibility of doing a teamviewer session with me ?

Introduction This script has been written to allow you to automate the deployment Windows 10 version 1703 (Creators Update) using the latest available software including: Windows 10 x64 (version 1703, MSDN media) Microsoft Deployment Toolkit (MDT) build 8443 Latest available 2017 drivers for the Surface Pro 4 Windows 10 ADK (version 1703) Windows Server 2016 Note: This is fully automated, and as this does install a Windows Deployment Services server role hosting a boot image, you should modify the script accordingly and test it thoroughly in a lab first. As ADK 1703 has an issue with Secure Boot, you must temporarily disable Secure Boot on your Windows Server 2016 prior to running this script, I will amend this post if ADK 1703 is re-released. This script is tailored for one thing only, deploying Windows 10 x64 to the Microsoft Surface Pro 4 with all drivers loaded and MDT 2013 pre-configured. Download it and customize it to suit your needs for other hardware if you wish because what it does is pretty cool. This script performs the following actions:- Downloads and then Installs Windows ADK 10 (version 1703) if you have not done so already Downloads and then Installs MDT, if you have not done so already Downloads all required drivers for Microsoft Surface Pro 4 if you have not done so already Imports the Windows 10 x64 (version 1703) operating system into MDT Imports the Microsoft Surface Pro 4 drivers into MDT Creates Selection Profiles for Microsoft Surface Pro 4 and WinPE x64 Creates a Deploy Windows 10 x64 - Surface Pro 4 task sequence Edits the Deploy Windows 10 x64 - Surface Pro 4 task sequence and adds an inject drivers step for Microsoft Surface Pro 4 Sets a WMI query for hardware detection for the Surface Pro 4 on the corresponding driver step Injects the Microsoft Surface Pro 4 network drivers into the LiteTouchPE_x64.wim Creates custom CustomSettings.ini and BootStrap.ini files Disables the X86 boot wim (as it is not needed for Surface Pro 4) Changes the Selection Profile for the X64 boot wim to use the WinPE x64 selection profile Installs the Windows Deployment Service role Configures the WDS role and adds the previously created LiteTouchPE_x64.wim Starts the WDS service so that you can PXE boot (UEFI network boot). All you have to do is download the script below, modify some variables, then place certain files in the right place such as the Windows 10 x64 Enterprise (version 1703) media. Please ensure you have a working DHCP scope on your Active Directory domain controller, then PXE boot a Microsoft Surface Pro 4 and sit back and enjoy the show. Step 1. Download the script The PowerShell script will do all the hard work for you, it is in the Downloads section at the end of this guide, download it, unzip it and place it on a server that is designated to be the MDT server. Note: If you use this on Windows Server 2016 then you'll need to temporarily disable secure boot to allow ADK 1703 to install otherwise it will fail due to driver signing. Hopefully this will be fixed in an upcoming release of ADK 10 version 1703. Step 2. Configure the variables in the script Once you have downloaded and extracted the script, you need to configure certain variables interspersed throughout the script. I'll highlight the ones you need to edit. The most important of them is the $SourcePath variable (line 61) as this decides where to get the content from and where to store it. This variable should point to a valid drive letter, the folder name will be created if it does not exist. The $FolderPath variable (line 242) specifies the MDT Deployment share root folder for example E:\MDTDeploy. There are other variables to configure, for joining the Domain (lines 320-322) and then you need to configure how you actually connect to the MDT server from WinPE (lines 393-397) Step 3. Copy the Windows 10 x64 (version 1703) operating system files Mount a Microsoft Windows 10 x64 Enterprise (version 1703) ISO and copy the contents to $SourcePath\Operating Systems\Windows 10 x64\1703 as shown below Step 4. Optionally copy MDT, ADK 10, Surface Pro 4 drivers This is an optional step. If you've already downloaded the above files then place them in the source folder, otherwise the script will download them for you. Note: You do not have to do this as the script will download the content for you if it's not found. Step 5. Optionally copy your Applications to the respective folders This is an optional step. If you have apps like Office 365, copy them to their respective folders under Applications. If you do add any applications, you'll need to edit the corresponding section within the script for the CustomSettings.ini and replace the GUID for the App as shown here (line 362) Step 6. Run the script On the server that will become your MDT server, start PowerShell ISE as Administrator. Click on the green triangle to run the script. Below you can see the script in action: After the script is complete, you are ready to test deploying Windows 10 Creators Update to a Microsoft Surface Pro 4. You can see that Windows Deployment Services is installed and that the ADK 1703 version of the MDT LiteTouch_X64 boot wim is already imported. This boot image also has the Surface Pro 4 network drivers added. After opening the Deployment Workbench, you can see the Deploy Windows 10 x64 version 1703 task sequence is created The Surface Pro 4 Inject drivers step is pre-configured for you and the WMI query for the hardware is also added on the options tab and drivers specific to the Surface Pro 4 for are imported into MDT and custom selection profiles for the Surface Pro 4 are created Step 7. Sit back and watch the deployment Take a properly shutdown Surface Pro 4, and power it on using the following sequence. Hold the down volume key and then press the power button while continuing to hold down the volume key, it should PXE boot. Press enter when prompted and then it will load the MDT LitetouchPE_X64 boot wim. before prompting you for a computer name, note that it's currently set to SurfacePro4 in CustomSettings.ini contained within the script, If you have optional apps they'll be listed here along with the mandatory Office 365 ProPlus you can change that behavior in the UI itself (CustomSettings.ini on the Properties/Rules of the DeploymentShare) or automate it via the many methods available such as those that Mikael describes here click Next and off it goes, and finally it's all complete, Windows 10 Creators Update installed fully automated ! Troubleshooting If the script has issues starting WDS (and you see the error below) then restart the server, as you were asked to do at the end of the script ;-). If you cannot PXE boot, because WDS is not accepting connections (revealed by the PXE Response tab in WDS properties), then look for the following error in the scripts output: An error occurred while trying to execute the command. Error Code: 0x5 Error Description: Access is denied. If you see that error, then the user you are logged in as does not have sufficient permissions to configure WDS. To grant permissions to approve a pending computer Open Active Directory Users and Computers. Right-click the OU where you are creating prestaged computer accounts, and then select Delegate Control. On the first screen of the wizard, click Next. Change the object type to include computers. Add the computer object of the Windows Deployment Services server, and then click Next. Select Create a Custom task to delegate. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next. In the Permissions box, select the Write all Properties check box, and click Finish. You can test whether the permission change works by issuing the following after the script is complete: WDSUTIL /Set-Server /AnswerClients:All To perform these procedures, you must be a member of the Account Operators group or the Domain Administrators group, or you must have been delegated the appropriate user rights. For deployment issues, you can review the logs found in the following locations depending on what part of the OSD process you are in:- In WinPE X:\MININT\SMSOSD\OSDLOGS X:\Windows\Temp\SMSTSLOG In Windows C:\Windows\Temp\DeploymentLogs C:\MININT\SMSOSD\OSDLOGS C:\Users\Administrator\Appdata\Local\temp\SMSTSLog Summary Automating the deployment of Windows 10 Creators Update to the Microsoft Surface Pro 4 using PowerShell and MDT is easy when you know how. Downloads Download the PowerShell script contained in the ZIP file. Deploy Windows 10 Creators Update to Microsoft Surface Pro 4 with MDT - April 2017.zip

ok got a reply

hi i'm checking with Microsoft about this and will come back to you when they reply cheers niall

use the current version of MDT until the next release is released, as regards ADK 1703 don't use it with Server 2016 until it is fixed for the secure boot driver signing issue that occurs when you install it on Server 2016

why windows 8.1 ? the upgrade task sequence was designed for Windows 10 upgrades only so i doubt it would work for Windows 8.1, you could though do a refresh (reinstall) from Windows 7 to Windows 8.1, have you tried that ?

glad to hear it, to summarize Microsoft is aware of the issue and has produced a fix

please update the status of this thread

ok try this method https://blogs.technet.microsoft.com/brandonlinton/2015/07/30/windows-10-adk-boot-image-updates-for-configuration-manager/

that boot image is ADK 10 version 1507, ancient, are you sure you updated ADK ?

update ! Microsoft's product team knows the issue, and is preparing a mitigation.

i'm checking with Microsoft PG about your specific error any chance you could send the logs to me zipped, niall@windows-noob.com

don't forget windows-noob.com's guide here

here :), no i'm kidding, i don't think it's necessarily documented anywhere but it's based on actually having seen the problem in production, what we did to get around it is what I've mentioned above, try it and see does it improve for you

if you are NOT using eval (as in my example) then you need to add this section to the configuration.ini file [SABranchOptions] SAActive=1 CurrentBranch=1

don't use copyprofile it breaks more things than it fixes, to configure the taskbar or start menu you need to decide which is more important as it's one or the other (at least it was when i last tested it), here's how to customize the start menu

well that's up to you to test and verify, you can add pauses that timeout and continue by simply (for example) pinging localhost a certain number of times C:\Windows\System32\ping.exe -n 61 127.0.0.1

It's not supported, so don't bother trying. If you want to deploy Windows 10 then you really need to consider moving to SCCM Current Branch, you can deploy Windows 10 up to version 1511 with SCCM 2012 R2 SP1 but that's it, to deploy any later versions (such as Windows 10 LTSB version 2016) you'll need Configuration Manager Current Branch, version 1606 or later

for the next release of this guide (for SCCM 1702 or whichever release becomes the next baseline), i'll update the code then, thanks and feel free to add your contribs here or elsewhere in windows-noob, that's what it's all about

this might be enough, please test Uninstall-WindowsFeature -Name Windows-Internal-Database -Restart

WID is required, see the screenshot. You can try manually removing it and scripting that yourself but why worry you are not using it, wsus is using SQL for the DB

mystery solved, when generating the XML i add WSUS via the server manager, and as part of that process it automatically adds required features including WID, see here

good point, i see a reference to it in the wsus xml file but it still uses the SQL DB, and in my lab the wid services are not even running are they running on yours ? i'll see what i can find out in my lab...