anyweb

until i write a new post for windows 10, this should help https://www.windows-noob.com/forums/topic/3251-customising-windows-7-deployments-part-4/

if you use teamviewer i'm happy to remote in and help out, let me know

hi Gerard and welcome to windows-noob !

did you see my new blog post here, as regards your current failure message i'd need to see the entire output from the script, can you post it please ? (copy/paste save as a txt file and attach)

Introduction In a previous post I showed you how you can deploy Windows 10 x64 (version 1507) to the Microsoft Surface Pro 4 using MDT 2013 Update 1. This script has been updated with the following changes: Windows 10 x64 (version 1511, updated February 2016 media) Microsoft Deployment Toolkit (MDT) 2013 Update 2 Latest available 2016 drivers for the Surface Pro 4 Windows 10 ADK (version 1511) Note: Microsoft has released two versions of Windows 10 x64 (version 1511). The first release was the original and released in November 2015, the second release was an updated release in February 2016. For this guide I've used the February 2016 release available on the Microsoft Volume License Site. The script does care which release you use, as the previous release of Windows 10 x64 version 1511 shows up as Technical Preview wheras the February release does not. Note: This is fully automated, and as this does install a Windoes 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 to the Microsoft Surface Pro 4 with all drivers loaded and MDT 2013 Update 2 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 1511) if you have not done so already Downloads and then Installs MDT 2013 Update 2 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 1511) 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 1511) 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 (running Windows Server 2012 R2) that is designated to be the MDT 2013 server. I've tested it on Windows Server 2012R2 only, if you run it on a different operating system and have issues then please post your results below. 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 59) 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 239) specifies the MDT Deployment share root folder for example E:\MDTDeploy. There are other variables to configure, for joining the Domain (lines 316-318) 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 1511) operating system files Mount a Microsoft Windows 10 x64 Enterprise (version 1511) ISO and copy the contents to $SourcePath\Operating System Images\ as shown below Step 4. Optionally copy MDT 2013 Update 2, 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. 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 358) Step 6. Run the script On the server that is to be 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 a Microsoft Surface Pro 4 installation. After running the script you can see that WDS is installed and that the LiteTouch_X64 boot wim is imported into WDS. After opening the Deployment Workbench, you can see the Deploy Windows 10 x64 - Surface Pro 4 task sequence is created The Surface Pro 4 drivers step is configured and the WMI query for the hardware is also added and drivers specific to the Surface Pro 4 are imported and custom selection profiles 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, before installing the Applications.. and finally it's all complete ! 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: setting PXE response policy... Windows Deployment Services Management Utility [Version 6.3.9600.16384] © 2013 Microsoft Corporation. All rights reserved. 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 resolve, make sure to Delegate permission in Active Directory for the User you are running this as, and allow that user Full Control of Computer Objects in that OU. You can test whether the permission change works by issuing the following after the script is complete: WDSUTIL /Set-Server /AnswerClients:All 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:\windows\temp\SMSTSLOGIn Windows C:\Windows\Temp\DeploymentLogs C:\MININT\SMSOSD\OSDLOGS C:\Users\Administrator\Appdata\Local\temp\SMSTSLog Summary Automating the deployment of Windows 10 x64 Enterprise to the Microsoft Surface Pro 4 is possible and script-able with PowerShell and MDT 2013 Update 2. Related Reading How can I deploy Windows 10 x64 to the Microsoft Surface Pro 4 using MDT 2013 Update 1 - https://www.windows-noob.com/forums/topic/13190-how-can-i-deploy-windows-10-x64-to-the-microsoft-surface-pro-4-using-mdt-2013-update-1/ Downloads Download the PowerShell script - Deploy Microsoft Surface Pro 4 with MDT 2013 Update 2 - April 2016.zip You can download a Microsoft Word copy of this guide here - How can I use PowerShell to deploy Windows 10 x64 to the Microsoft Surface Pro 4 using MDT 2013 Update 2.zip

looks like your errors are network related, are you doing this on a VM or ?

i'm updating it now and will post a new blog post shortly, but in the mean time look for the line that contains this string "$SourcePath\Operating Systems\$OStoDeploy" and change it to "$SourcePath\Operating System Images\$OStoDeploy" then run it again, should work and depending on the version of Windows 10 you are deploying (1507 or 1511) read the change below, the above script was only tested with Windows 10 x64 - 1507, therefore if you use Windows 10 x64 - 1511 (original november release) it would fail, the below will resolve that. # use this line for Windows 10 1507 # import-mdttasksequence -path "DS001:\Task Sequences\$OStoDeploy" -Name "Deploy $OStoDeploy - Surface Pro 4" -Template "Client.xml" -Comments "(c) windows-noob.com" -ID "001" -Version "1.0" -OperatingSystemPath "DS001:\Operating Systems\$OSToDeploy\Windows 10 Enterprise in Windows 10 x64 install.wim" -FullName "windows-noob" -OrgName "windows-noob.com" -HomePage "http://www.windows-noob.com"-AdminPassword "P@ssw0rd" -Verbose # Use this line for Windows 10 1511 import-mdttasksequence -path "DS001:\Task Sequences\$OStoDeploy" -Name "Deploy $OStoDeploy - Surface Pro 4" -Template "Client.xml" -Comments "(c) windows-noob.com" -ID "001" -Version "1.0" -OperatingSystemPath "DS001:\Operating Systems\$OSToDeploy\Windows 10 Enterprise Technical Preview in Windows 10 x64 install.wim" -FullName "windows-noob" -OrgName "windows-noob.com" -HomePage "http://www.windows-noob.com"-AdminPassword "P@ssw0rd" -Verbose If however you are using the Windows 10 x64 - 1511 media that was updated to February 2016 (availabe on Microsofts volume license site) then use the first import statement and rem out the second, like so. # use this line for Windows 10 1507, or updated Windows 10 1511 media from Feb 2016 import-mdttasksequence -path "DS001:\Task Sequences\$OStoDeploy" -Name "Deploy $OStoDeploy - Surface Pro 4" -Template "Client.xml" -Comments "(c) windows-noob.com" -ID "001" -Version "1.0" -OperatingSystemPath "DS001:\Operating Systems\$OSToDeploy\Windows 10 Enterprise in Windows 10 x64 install.wim" -FullName "windows-noob" -OrgName "windows-noob.com" -HomePage "http://www.windows-noob.com"-AdminPassword "P@ssw0rd" -Verbose # Use this line for original Windows 10 1511 media # import-mdttasksequence -path "DS001:\Task Sequences\$OStoDeploy" -Name "Deploy $OStoDeploy - Surface Pro 4" -Template "Client.xml" -Comments "(c) windows-noob.com" -ID "001" -Version "1.0" -OperatingSystemPath "DS001:\Operating Systems\$OSToDeploy\Windows 10 Enterprise Technical Preview in Windows 10 x64 install.wim" -FullName "windows-noob" -OrgName "windows-noob.com" -HomePage "http://www.windows-noob.com"-AdminPassword "P@ssw0rd" -Verbose

the script creates the TS.XML via MDT, you don't need to create it, you must however supply the Windows 10 media as explained in this guide.

it worked fine when i created it, can you post some of the errors you get...

coming soon...the error you are seeing is well known, and involves a ccmrepair to resolve, can you post your smsts.log so we can verify

i would reinstall WDS as a start, see what happens

can you a/ describe exactly what you are trying to do and b/ attach any relevant logs

yup here you go How can I password Protect a Task Sequence ? Password Protecting a Task Sequence

you could make it hidden (as you've found) or use a password on the task sequence itself, or use devel mode

have you seen this ? https://www.windows-noob.com/forums/topic/11016-how-can-i-sync-the-bios-date-in-winpe-to-avoid-pxe-boot-failure-with-system-center-2012-r2-configuration-manager/#entry41925

where[s your log file ?

Introduction At the start of this series of step by step guides you installed System Center Configuration Manager (Current Branch), then you configured discovery methods. Next you configured boundaries to get an understanding of how automatic site assignment and content location works. After that you learned how to update ConfigMgr with new features and fixes using a new ability called Updates and Servicing and you learned how to configure ConfigMgr to use Updates and Servicing in one of these two modes: Online mode Offline mode To prepare your environment for Windows 10 servicing (this guide) you learned how to setup Software Updates using an automated method (via a PowerShell script) or manually using the ConfigMgr console. Next you used a PowerShell script to prepare some device collections, then you configured client settings for your enterprise and finally you'll deployed the ConfigMgr client agent using the software updates method which is the least intensive method of deploying the Configuration Manager client agent. As System Center Configuration Manager (current branch) is being delivered as a service now, version 1602 was made available (March 11th, 2016) and you used Updates and Servicing to do an in-place upgrade to that version as explained here. Next you learned about how to use the Upgrade task sequence to upgrade your Windows 7, Windows 8 (and 8.1) and even your Windows 10 devices to a later build of Windows 10. In this guide you'll take a look at the new Windows 10 servicing features in ConfigMgr (Current Branch). A short introduction to Windows 10 servicing Windows 10 servicing is a broad category (discussed at length here on Technet) which includes different options for applying updates and upgrades to Windows 10 devices using a variety of different methods available. In this guide we are primarily interested in looking at Windows 10 servicing options within ConfigMgr (Current Branch) so that will be the focus. In a nutshell there are three Windows 10 servicing options we need to consider: Current Branch Current Branch for Business Long Term Servicing Branch Each branch has its' own properties. If you are using Current Branch, then updates and upgrades are made available as soon as they are released from Microsoft and the key benefits are that it makes new features available to users as soon as possible. Current Branch for Business allows more time (4 to 8 months depending on your Defer Updates and Upgrades preferences) to 'wait and see' how those updates (and upgrades) can impact your environment. The key benefit here is it provides additional time to test new feature upgrades before deployment which is useful in a business scenario. Long Term Servicing Branch is aimed at low-change configurations (Operational Technology for example) where changing functionality can impact production. This is all neatly explained in the following table from Technet. Note: Make sure to read the following post so that you understand the implications of enabling CBB using various methods (registry or gpo). Familiarizing yourself with the Windows 10 servicing dashboard Note: All screenshots taken here were from System Center Configuration Manager version 1602 (Current Branch). As ConfigMgr (Current Branch) is evolving at a fast rate based on UserVoice and production development it is very likely that abilities and even UI elements shown here will change in later versions of the product. In order to populate information on the dashboard and test Windows 10 Servicing, this lab already contains two Windows 10 computers, one is version 1507 and the other is version 1511. In the ConfigMgr console select Software Library and expand Windows 10 Servicing. A dashboard similar to the below screenshot should appear. The first thing you'll notice in the tiles displayed are the two doughnuts which contain visual clues about the versions and branches of Windows 10 in your organization. Note: You will notice similar colors used throughout the tiles in the dashboard, however they don't necessarily match up between different tiles. This behavior will more than likely change in a later release of ConfigMgr (a bug has been raised and Microsoft is working on it). Windows 10 Usage Within the first tile is a doughnut called Windows 10 Usage. This tile should give you an estimate of the different Windows 10 build versions encountered by ConfigMgr in your organization. If you have any Windows 10 Insider Preview versions, they'll be listed as Other. Windows 10 Rings Within the second tile is a doughnut called Windows 10 Rings. This tile is used to give you an overview of the Windows 10 Branches in use and their readiness state, however instead of referring to those branches as explained in the table above, they have alias's. The following Table should clear that up: Release Ready : Current Branch Business Ready : Current Branch for Business Long Term Servicing Branch : Long Term Servicing Branch In addition to the two doughnuts in the first two tiles you have another two tiles which allow you to Create Servicing plan and monitor Alerts along with a big tile reminding you to Please define servicing plan for Windows 10. Note: Creating a servicing plan directly from within the dashboard will create a basic servicing plan which only prompts you for name, collection, deployment package, and readiness state (along with associated limitations for the last two). All other values will be default. If you want custom options, create the servicing plan directly from the ConfigMgr console. Windows 10 Build To see more information you either need a large resolution monitor or simply scroll down to reveal the Windows 10 Build tile which is a graph that plots out the versions of Windows 10, their readiness state and an approximate EOL. What you can see from the above is that Windows 10 version 1507 is classified as Business Ready (Current Branch for Business) from the date it was released, and from approximately March 2016 Windows 10 version 1511 takes over that spot (while Windows 10 1507 heads into EOL). In fact, Windows 10 version 1511 was declared Current Branch for Business on the 8th of April 2016. Ok so now that you've seen the dashboard, let's get on with the business of creating a servicing plan. Step 1. Synchronize Software Updates Before you create your servicing plan, make sure that the data you are using is up to date. To do that you need to synchronize with Microsoft Update. To perform a sync do as follows: In the ConfigMgr console select the Software Library workspace, select Software Updates, right click on All Software Updates and choose Synchronize Software Updates. Answer Yes to the popup. Using CMTrace, monitor the sync progress in <ConfigMgr Installation Path>\Logs\Wsyncmgr.log. Look for the Sync succeeded. Setting sync alert to canceled state on site <your_site_code> text in the log file to notify you of a successful sync. Step 2. Creating a servicing plan Servicing plans are akin to Automatic Deployment Rules (ADR) in Software Updates in that they can automatically download, and deploy updates to a collection based on the settings you define in the rule. Servicing plans however allow you to define what Windows 10 branches are in user in your environment and then monitor them in the servicing dashboard. From version 1602 onward, servicing plans are also tied so that you can manage the behavior for high-risk deployments. Note: Servicing plans are designed to upgrade Windows 10 versions from one build to another build only. They are not designed for upgrading Windows 7 or Windows 8.1 to Windows 10. If you need to upgrade your Windows 7 or Windows 8.1 computers to Windows 10 use the Upgrade Task Sequence instead. In this example you will create a servicing plan for Windows 10 Current Branch (this is because at the time of writing there were no upgrades available for Current Branch for Business). In the ConfigMgr console select Software Library and expand Windows 10 Servicing. Select Servicing Plans and in the ribbon click on Create Servicing Plan. When the wizard appears, give the Servicing Plan a suitable name like SUM: Servicing Plan for Windows 10 (The SUM prefix allows you to clearly see that the deployment is for software updates in the monitoring console later.) Next, point it to your target collection, this collection should contain Windows 10 computers that are suitable for this servicing plan (i.e. Current Branch as defined by not setting the Defer Upgrades setting). Note: In production you'd want to create a hierarchy of test collections prior to releasing upgrades to the masses, this is in order to verify that your critical applications are not affected by the upgrade. How you populate those collections is up to you. Next you get to choose which Deployment Ring you'd like to use. The Deployment Ring refers to the Windows readiness state that applies to this servicing plan, and once again you get to choose between Release Ready (Current Branch) or Business Ready (Current Branch for Business). Depending on which state you choose, you will see different results in the console, so it's a good idea to use the Preview button on the Upgrades screen particularly when moving the days (to wait) slider. This servicing plan is aimed at Current Branch computers so select the first option. Note: Even though Windows 10 version 1511 was declared as Current Branch for Business (CBB) on April 8th, 2016, that information has not yet trickled down to ConfigMgr as of 2016/4/10 therefore if you select the Business Ready deployment ring and 0 days, you will not see any suitable upgrades listed. On the Upgrades screen select the three checkboxes and set the search criteria to Language=English Required=>=1 Title= Upgrade to Windows 10 Enterprise Note: Make sure to select the right version (SKU) of Windows 10 for your deployment, if your clients are running Windows 10 Enterprise, then you should select the Enterprise version of the upgrade. Next, click on the Preview button, this will show what updates the wizard found that match your criteria For the Deployment Schedule screen set the Software Available Time to be at least 4 hours after the rule has run in order for the actual software update deployment packages to reach the destination distribution points. In a slow wan, increase that time. For Installation Deadline, the deadline is the displayed deadline time plus a random amount of time up to 2 hours, this is to reduce the load generated by all computers in the collection downloading the updates at the same time. On the User Experience screen, for User Notifications select Display in Software Center and show all notifications. For Deadline behavior, place a checkmark in Software Update Installation and System Restarts. On the Deployment Package screen choose Create a new deployment package and fill in the details as appropriate Next add the Distribution Points you want the package distributed to select where to download the content from and click through to the completion screen. Step 3. Review additional servicing plan properties Now that the servicing plan is created, highlight it in the console, right click and choose Properties. Select the Evaluation Schedule tab, as you can see by default it's set to run after every SUP sync, if you want to change that behavior modify it here. You can also review the Download Settings for the client in the Download Settings tab. In Deployment Settings set the amount of detail to Only success and error messages Step 4. Run the servicing plan and monitor Now everything is in place, you could sit back and wait for things to happen or kick off a test run. To trigger the servicing plan into running you need to initiate a SUP sync (as specified by the Evaluation Schedule), or right click on the Servicing Plan and choose Run Now. click OK to the message Using CMTrace, monitor the download progress in <ConfigMgr Installation Path>\Logs\PatchDownloader.log. If you are connecting to the console using terminal services check C:\Users\<username>\AppData\Local\Temp\2\PatchDownloader.log. You can even determine how much of the download is remaining based on the percent complete value as shown in this screenshot below: Note: Each Upgrade selected for download contains two architectures (X86 and X64) and their associated files. It is currently not possible to decide which Architecture to download. Using CMTrace, you can review the servicing plan progress in <ConfigMgr Installation Path>\Logs\RuleEngine.log After the download has completed successfully the Servicing Plan will be deployed (and the content distributed to the distribution points) and then show up in the ConfigMgr console in the Monitoring workspace, under Deployments. You can also review Software Update Groups where the servicing plan will be listed along with its' Deployment. Step 5. Review the Upgrade process on your Windows 10 devices Note: Ensure that one or more applicable Windows devices are in the collection used when creating the servicing plan. Also note that if you are just testing the servicing plan, and you used the settings above that it may take up to 4 hours to show up on the client, adjust the servicing plan as necessary and choose Run Now again to re-deploy it with the new settings.. Now everything is in place for the Windows 10 servicing to begin. For this section you can review what happens on a Windows 10 version 1507 client. The first thing the client will see is a familiar notification in the systray informing the user that Software Changes are required. clicking on that shows you these options and before long it starts downloading and then installing the Upgrade as the Servicing Plan was configured for all notifications, the user will be notified of the pending restart at which time Windows will get updated after everything is complete, log in to Windows to see this... note the new version after the upgrade ? Job done! After confirming the success of the upgrade methodology, you can hop back to the ConfigMgr console and review the Windows 10 Servicing Dashboard. Notice the Deploy Now button, that allows you to further deploy the same Servicing Plan to more collections. Note: Occasionally Microsoft re-releases the Windows 10 upgrade media to the VLSC and Windows Update with newer versions of the media (for example adding Cumulative Updates to the media), and when they do so they currently expire the available media, meaning that new content has to be downloaded and evaluated by your servicing plans. This behavior may change in the future but for now, be aware of it. until next time, adios ! Summary Upgrading Windows 10 devices to a later release of Windows 10 is made easier with servicing plans defined at a schedule that suits you. While servicing plans won't take care of earlier versions of Windows such as Windows 7 or Windows 8.1, you can upgrade those devices with the upgrade task sequence method instead. Client side language packs are important to keep in mind as Servicing Plans do not deal with languages on the client side (if any are installed). Also, servicing plans cannot handle drivers or pre and post setup upgrade steps, for that use the upgrade task sequence method instead. A significant amount of functionality has improved and changed between the ConfigMgr 1511 and ConfigMgr 1602 Current Branch releases based on feedback from UserVoice and connect.microsoft.com. I strongly expect the next release of ConfigMgr will be even more fine tuned and feature rich particularly in the area of Windows 10 servicing. Related Reading Plan for Windows 10 deployment - https://technet.microsoft.com/itpro/windows/plan/index Windows 10 servicing options for updates and upgrades - https://technet.microsoft.com/itpro/windows/manage/introduction-to-windows-10-servicing Manage Windows as a service using System Center Configuration Manager - https://technet.microsoft.com/en-us/library/mt627931.aspx Windows 10 1511 is now a Current Branch for Business (CBB) release - http://blogs.technet.com/b/windowsitpro/archive/2016/04/08/windows-10-1511-is-now-a-current-branch-for-business-cbb-release.aspx Windows 10 release information - https://technet.microsoft.com/en-us/windows/mt679505.aspx?ocid=wc-ext-aka Downloads You can download a Microsoft Word copy of this guide here dated 2016/04/10 How can I use servicing plans in System Center Configuration Manager (Current Branch) to upgrade Windows 10 devices.zip

Microsoft has announced that Windows 10 version 1511 has been officially declared as Current Branch for Business. Michael Niehaus stated:- "each new Windows 10 feature update is initially considered a Current Branch (CB) release, to be used by organizations for initial pilot deployments. The feature update will later be declared as Current Branch for Business (CBB), once we have received feedback and confirmation from organizations, OEMs, and partners, confirming that the feature update is ready for broad deployment." So what does that mean for those of us who are actively deploying Windows 10 in the Enterprise already ? Not a whole lot as long as you are running Windows 10 version 1511 already. For devices already running Windows 10 version 1511, deployed before the CBB declaration, no action is required other than standard monthly servicing. With the installation of the March cumulative update (KB3140768) or any later cumulative update, the device is already running the equivalent of what was declared as CBB. What about those of us who have Windows 10 1507 devices deployed in the Enterprise ? I've highlighted some points in bold below:- For devices being serviced using Windows Update for Business and configured to “Defer upgrades,” Windows 10 1511 will begin to deploy as soon as the updated media has been published. (Note that the deferral policies that specify an additional number of months to defer the feature update are not supported for devices running Windows 10 1507.) For devices being serviced using Windows Server Updates Services, the updates to the existing Windows 10 1511 feature updates will need to be re-approved once the new updated media is received (unless you have an automatic update rule configured for the “Upgrades” category). For those using the System Center Configuration Manager Windows 10 servicing plans to keep Windows 10 devices up to date, the updated media will be detected as “business ready,” causing servicing plans based on that “business ready” designation to begin to be evaluated. For devices that will be upgraded using System Center Configuration Manager or Microsoft Deployment Toolkit task sequences, you may want to switch to the latest media (downloaded from the Volume Licensing Service Center) instead of the current Windows 10 1511 media. Alternatively, you can inject the March cumulative update (KB3140768) into your existing media. (a guide for the upgrade task sequence along with injecting updates is here) Microsoft has also updated the Release Information page available at http://aka.ms/win10releaseinfo to reflect the updated status of Windows 10 1511. cheers niall

hi sorry for the delay in responding, you need to modify the post install line here and replace the server name CM01 with the server name you are installing SCCM on, assuming it also hosts SQL as we do in this guide, I've updated the guide to point this out, thanks for alerting me

Gabe Aul announced that there's a new insider preview available on the fast ring, and here’s what’s new in Build 14316 Run native Bash on Ubuntu on Windows: In this build, you can natively run Bash in Windows as announced last week at Build 2016. To do this, you first need to turn on Developer Mode via Settings > Update & security > For developers. Then search for “Windows Features” and choose “Turn Windows features on or off” and enable Windows Subsystem for Linux (Beta). To get Bash installed, open Command Prompt and type “bash”. For more details, see this blog post. to see a guide explaining what to do see here > https://msdn.microsoft.com/en-us/commandline/wsl/install_guide# and for more info about this release see the original blog post here > https://blogs.windows.com/windowsexperience/2016/04/06/announcing-windows-10-insider-preview-build-14316/

here's a way around it https://www.windows-noob.com/forums/topic/7772-how-can-i-change-a-hkcu-setting-within-windows-during-an-osd-deployment/

pause the computer after scanstate to see what is working (or not working)

Microsoft is reaching out to Linux developers in a way that the company never has before. "The Bash shell is coming to Windows. Yes, the real Bash is coming to Windows," said Microsoft's Kevin Gallo on stage at today's Build 2016 keynote. The announcement received an uproarious applause from the crowd. The new functionality will be enabled as part of this summer's Anniversary Update to Windows 10. "This is not a VM. This is not cross-compiled tools. This is native," he said. "We've partnered with Canonical to offer this great experience, which you'll be able to download right from the Windows Store." Third-party tools have enabled this sort of thing for years, but a direct partnership between Microsoft and Canonical should offer even more flexibility and convenience for developers who prefer using these binaries and tools. for the full story read more @ the Verge

just disable the Windows 7 deployment, or delete it altogether or remove the computer from the collection that it is deployed to

where is the warning.hta file placed ? try hard coding the path to it eg: C:\Windows\temp\warning.hta