Leaderboard

Introduction Microsoft released the new Surface Pro and recently a new operating system, Windows 10 version 1709 (Fall Creators Update). Now you can automate the installation of it using PowerShell. This script has been written to allow you to automate the deployment Windows 10 version 1709 (Fall Creators Update) using the latest available software including: Windows 10 x64 (version 1709) Microsoft Deployment Toolkit (MDT) build 8443 Latest available 2017 drivers for the Surface Pro Windows 10 ADK (version 1709) 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. This script is tailored for one thing only, deploying Windows 10 x64 version 1709 to the Microsoft Surface Pro with all drivers loaded and MDT 2013 preconfigured. 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 1709) 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 if you have not done so already Imports the Windows 10 x64 (version 1709) operating system into MDT Imports the Microsoft Surface Pro drivers into MDT Creates Selection Profiles for Surface Pro and WinPE x64 Creates a Deploy Windows 10 X64 version 1709 task sequence Edits the Deploy Windows 10 X64 version 1709 task sequence and adds an inject drivers step for Microsoft Surface Pro Sets a WMI query for hardware detection for the Surface Pro on the corresponding driver step Injects the Microsoft Surface Pro 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) 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 1709) media. Please ensure you have a working DHCP scope on your Active Directory domain controller, then PXE boot a Microsoft Surface Pro 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 the server that is designated to be the MDT server. 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 53) 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 237) specifies the MDT Deployment share root folder for example C:\MDTDeploy. There are other variables to configure, for joining the Domain (lines 315-317) and then you need to configure how you actually connect to the MDT server from WinPE (lines 392-396) Step 3. Copy the Windows 10 x64 (version 1709) operating system files Mount a Microsoft Windows 10 x64 Enterprise (version 1709) ISO and copy the contents to $SourcePath\Operating Systems\Windows 10 x64\1709 as shown below Step 4. Optionally copy MDT, ADK 10, Surface Pro 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 automatically 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, these applications are remmed out with a #, as shown here (line 358) and here in line 294... 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 has completed. After the script is complete, you are ready to test deploying Windows 10 version 1709 (Fall Creators Update) to a Microsoft Surface Pro. You can see that Windows Deployment Services is installed and that the ADK 1709 version of the MDT LiteTouch_X64 boot wim is already imported. This boot image also has the Surface Pro network drivers added. After opening the Deployment Workbench, you can see the Deploy Windows 10 x64 version 1709 task sequence is created The Surface Pro Inject drivers step is pre-configured for you and the WMI query for the hardware is also added on the options tab drivers specific to the Surface Pro for are imported into MDT Step 7. Sit back and watch the deployment Take a properly shutdown Surface Pro , 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 before loading the boot image before prompting you for a computer name, note that it's currently set to SurfacePro in CustomSettings.ini contained within the script, 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, with your customized Company name and after a while it's all done 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 the Windows Deployment Server (MDT01) do as follows 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. Repeat the above process to grant appropriate permissions for the User who will run the PowerShell script Summary Automating the deployment of Windows 10 version 1709 (Fall Creators Update) to the Microsoft Surface Pro using PowerShell and MDT is easy when you know how. Downloads Download the PowerShell script contained in the ZIP file. Deploy Windows 10 Fall Creators Update to Microsoft Surface Pro with MDT - November 2017.zip

Create a Package with the cab file Create a run Command Line Step Select the created Package Set as Command line: DISM.EXE /online /add-package /packagepath:.\relative\Path\to\dotNetFile.cab Example: (In this case the cab file is at the root directory of the package)

I have this working in my TS OSD. I setup mine differently than what you noted above. Here is what I have: 1) Create a TS for the powershell ps1 file call 2) Create the TS for the OSD Pics: location of 2 files; data in my ps1; TS for the OSD

Another great step-by-step guide from Windows-noob, thanks. Save us so much time. In one of the other step-by-step guide (I think it was in 1606) a user asked for splitting up the different SQL logs,DB,Temp and so on to different drives, maybe it would be a good ide to include that in your SQL configuration settings. Again thanks for some really nice guides.

For the benefit of others, in the start-upgrade.ps1 I modified the logfile variable to: $Logfile = "C:\ProgramData\Windows10RequiredUpgradeStart-Upgrade-$env:USERNAME.log" In the wrapper.vbs I added strUserName to the first 'Dim', then Set oWsh = WScript.Createobject("WScript.Shell") strUserName = oWsh.ExpandEnvironmentStrings("%username%") under strComputer And just a bit further down where the path for the logfile is declared: path="C:\ProgramData\Windows10RequiredUgradeWrapper" & strUserName & ".log" Putting the logfile in the user profile would be a good approach too but I like having one place to check. Thanks again for your great work.

<!-- This component migrates user files with known extension--> <component type="Documents" context="UserAndSystem"> <displayName _locID="miguser.userdata">User Data</displayName> <role role="Data"> <rules context="System"> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.snt]", "Fixed")</script> </objectSet>

Just to confirm, I've removed "2018-04 Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4093119)" and now the 1703 Feature Update has appeared in Software Center! I'll get the CUs for each month of this year and try to find out where it's breaking.

Hello! Yes, do patch both x86 and x64. The detection should apply the correct architecture based on what' currently installed. For example, if you had Java x86 and Notepad++ x86 on an x64 machine, we would update to the latest x86 version for those apps if needed. No, we don't really pay much attention to what other competitors are doing. Instead, we focus on adding applications that would bring value to our customer base vs. just adding anything others may have that we don't currently support. Our customers can request new applications on our forum or email. We keep track of application request on this page: https://patchmypc.net/forum/index.php?board=19.0. Generally, it will only take us a few days to evaluate and add new request if the application is compatible. We do provide archived catalogs in the event you need to deploy an old version. - Justin

After a hour of testing I found out that you must add double quotes around "%msgdesc" to get the full description. Example of how my command line works: "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy bypass -file "D:\scripts\Dcreation.ps1" -message "%msgdesc"