Leaderboard

As a matter of interest are there any parts of the sccm install process you have not been able to powershell? I ask as around this time last year I was in a position of knowing I needed to rebuild my entire domain as we were going through a company rename but didnt yet have the new name. Ended up building a few dozen domain environments through powershell+powercli (vmware environment) including a lot of the sccm stuff so that once i did have the name+domain name i was ready to get going pretty quickly. I accept I am no powershell expert but as it took me a long time to put together if there are any smaller parts of interest I'm happy to share them, log of entire build attached. I made a lot of sacrifices in the scripts for the fact these scripts were all running remotely, e.g. i installed SQL as a scheduled task. Names/ip addresses tweaked for semi-anonymity. CleanedUpNames.Build.txt

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. You then learned about the new Windows 10 servicing features which use Servicing Plans in ConfigMgr (Current Branch). Next you integrated MDT 2013 update 2. MDT integration with ConfigMgr is useful as it provides additional functionality for operating system deployment scenarios such as Offline Language Package installation or User Driven Integration (UDI). Next you learned how to deploy Language Packs offline for Windows 10. To assist with Windows 10 servicing and for applying appropriate software updates to your Windows 10 devices, you used PowerShell to add queries to the various Windows 10 collections. Next you took a deeper look at the Windows 10 Upgrade task sequence, and learned one way of dealing with potential upgrade issues. While that method will flag a problem, such as determining the system UI language doesn't match the provided media, it won't allow you to continue with the upgrade. Next you learned how to upgrade the operating system when a language pack was installed, provided that the system UI language is from a 'list' of approved languages that you intend to support. This guide will show you how to display customized messages to a user during a task sequence, and how to set an exit code which could allow you to deliberately fail an action if necessary. All that's required is a few steps to set variables, a PowerShell script, and the serviceUI.exe executable from MDT 2013 Update 2. Step 1. Create a package On your ConfigMgr server, in the sources share, create a folder called Display Custom Message and place the DisplayCustomMessage.ps1 PowerShell script available in the downloads section of this guide, in the folder. Even though you might be deploying an X64 operating system, locate, select and copy the x86 architecture version of ServiceUI.exe from the Sources\OSD\MDT\MDT2013u2\Toolkit\Tools\x86 folder into the Display Custom Message folder as shown below. In the ConfigMgr console, Software Library, select Packages and right click, choose Create Package. Fill in the following details, Choose Do not create a program and then continue through the wizard until completion. Once the package is created, right click the package and choose Distribute Content. Distribute the package to your distribution points. Step 2. Create a custom task sequence In the ConfigMgr console, in Software Library, select Operating Systems and right click on Task Sequences, choose Create Task Sequence. select Create a new custom task sequence give the task sequence a suitable name such as Display Custom Messages with exit codes continue through that wizard until completion. Step 3. Edit the task sequence Right click on the newly created task sequence and choose edit It will appear blank, click on the Add Drop down and add a New Group called Display Custom Message Create a new Set Task Sequence Variable step called Set Title with a Task Sequence Variable called Title, with a suitable value as follows: Create a new Set Task Sequence Variable step called Set Message with a Task Sequence Variable called Message, with a suitable value as follows: Create a new Set Task Sequence Variable step called Set ReturnCode with a Task Sequence Variable called ReturnCode, with a suitable positive value as follows: Click Add and choose Run Command Line, name the step Display Custom Message and paste in the following: ServiceUI.exe -process:TSProgressUI.exe %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NoProfile -ExecutionPolicy bypass -nologo -file DisplayCustomMessage.ps1 For Package, select the Display Custom Message package created above. Copy the entire group and paste it below the first group Edit the Set Message step as below Edit the Set ReturnCode step, and choose a value that the Options tab on the Display Custom Message step is not going to expect such as 1, this will cause the next step to fail when it returns the return code. Apply your changes and exit the Task Sequence wizard. Step 4. Deploy the task sequence Right Click on the task sequence and choose Deploy Choose a suitable collection and use a purpose of Available. Step 5. Review the capabilities On a client computer that is in the collection that the task sequence was deployed to, open Software Center and select the Display Custom Message with exit codes task sequence. choose Install and after a few moments the first popup message appears ! As the ReturnCode for the first message was set to a value we expected (0 or 3010) it did not fail the task sequence. Click OK to continue... the next message appears, note the different text, and it's hinting towards what will happen Clicking OK will produce the failure Which is OK because we were expecting it, in fact, the ReturnCode we set (1) is listed in the failure message. In a real Production task sequence however, you'd take care of failures and deal with them in a professional way, I just want you to see that we can actually set the ReturnCode via the custom message. To get more proof of that refer to the SMSTS.log file, and you can see that it's setting the ReturnCode to the value we chose result ! Summary Popping up messages to users during a task sequence is sometimes necessary, and when things go wrong, you sometimes need to fail the task sequence or set a ReturnCode to do a planned action. This guide helps you do both of those things dynamically. Related Reading Task sequence steps in System Center Configuration Manager - https://technet.micr...y/mt629396.aspx If you'd like to send a notification message to users in Intune in Azure, try the following guide. Downloads You can download a Microsoft Word copy of this guide here dated 2016/05/26 How can I display custom messages to users during a task sequence in SCCM Current Branch.zip You can download the PowerShell script used above here: DisplayCustomMessage.zip\

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 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. You then learned about the new Windows 10 servicing features which use Servicing Plans in ConfigMgr (Current Branch). Next you integrated MDT 2013 update 2. MDT integration with ConfigMgr is useful as it provides additional functionality for operating system deployment scenarios such as Offline Language Package installation or User Driven Integration (UDI). Next you learned how to deploy Language Packs offline for Windows 10. To assist with Windows 10 servicing and for applying appropriate software updates to your Windows 10 devices, you used PowerShell to add queries to the various Windows 10 collections. In this post you'll take a deeper look at the Windows 10 Upgrade task sequence, and see one way of dealing with potential upgrade issues. The idea here is to keep track of any upgrade failures, capture the logs that matter, capture the computer name and hardware type. If you see repeated 'common' failures you can add those error codes to the Windows Setup compatibility scan PowerShell script. This way your users that do experience failures will not get cryptic error messages, and you'll have the logs to fix things. Step 1. Create a share to store failed upgrade log files As you'll want to keep track of potential problems, create a hidden share to store log files. On your configuration manager server, start Windows PowerShell ISE as Administrator, and run the create upgradelogs.ps1 PowerShell script available in the downloads section at the end of this guide. Step 2. Create a package On your ConfigMgr server, in the sources share, create a folder called Windows setup compatibility scan results and place the WindowsSetupCompatibilityScanResults.ps1 PowerShell script in the folder. Locate, select and copy ServiceUI.exe from the Sources\OSD\MDT\MDT2013u2\Toolkit\Tools\x86 folder as shown below. paste that into the Windows setup compatibility scan results folder. In the ConfigMgr console, Software Library, select Packages and right click, choose Create Package. Fill in the following details. Choose Do not create a program and then continue through the wizard until completion. Step 3. Distribute the package Right click the package and choose Distribute Content. Distribute the package to your distribution points. continue through that wizard until completion. Step 4. Edit the existing upgrade task sequence In a previous guide you created the Upgrade task sequence, now it's time to add additional functionality to that task sequence. In the ConfigMgr console, locate the Upgrade to Windows 10 x64 version 1511 task sequence, right click on it and choose Edit. In the Prepare for Upgrade group select the Check Readiness for Upgrade step and click on Add then select New Group, name the new group Set Variables. Create a new Set Task Sequence Variable step called Set Server as follows: Create a new Set Task Sequence Variable step called Set Share to UpgradeLogs$ as follows: Create a new Set Task Sequence Variable step called Set Domain (fill in your domain name) as follows: Create a new Set Task Sequence Variable step called Set User and enter a username that will be used to connect to the share as follows: Next create another New Group and call it Windows Setup compatibility scan Next click on Add, choose Images, then Upgrade Operating System and name the step Windows Setup compatibility scan. Select the Perform Windows Setup compatibility scan without starting upgrade option. On the Options tab, select the Continue on Error option. Click Add and choose Run Command Line, name the step Process Windows Setup compatibility results and paste in the following: ServiceUI.exe -process:TSProgressUI.exe %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NoProfile -ExecutionPolicy bypass -nologo -file WindowsSetupCompatibilityScanResults.ps1 For Package, select the Windows Setup compatibility scan results package created above. Create a New Group called Capture Windows Setup logs on failure On the Options tab, check if the following Variable WindowsSetupCompatibilityScan = Failed as shown below Next create a Connect To Network Folder step and populate it as below when prompted for Windows User Account enter the Password for the account you added in the Set User step Create a new Run Command Line step called xcopy WindowsSetupCompatibilityScan log file and paste in the following: cmd /c ECHO F | xcopy /Y C:\Windows\Temp\WindowsSetupCompatScan.Log Z:\%computername%\WindowsSetupCompatScan.log On the Options tab of this step, place a checkmark in Continue on error Create a new Run Command Line step called xcopy Windows Setup log files and paste in the following: cmd /c xcopy /C /Y C:\$WINDOWS.~BT\Sources\Panther\*.log Z:\%computername%\ On the Options tab of this step, place a checkmark in Continue on error Create a new Run Command Line step called xcopy SMSTS log files and paste in the following: cmd /c xcopy /C /Y C:\Windows\CCM\LOGS\SMSTSLOG\*.log Z:\%computername%\ On the Options tab of this step, place a checkmark in Continue on error Create a new Run Command Line step called xcopy XML log files and paste in the following: cmd /c xcopy /C /Y C:\$WINDOWS.~BT\Sources\Panther\*.xml Z:\%computername%\ On the Options tab of this step, place a checkmark in Continue on error Create a new Run Command Line step called del network connection and paste in the following: cmd.exe /c "net use * /del /yes" On the Upgrade Operating System group, click on the Options tab and set the variable WindowsSetupCompatibilityScan = OK Apply the changes and close the Task Sequence editor. Step 5. Review the new functionality Tip: To induce a failure you can temporarily disable the Check Readiness for Upgrade step and use a Virtual Machine with only 1.5GB of RAM. This does not meet the requirements as stated here and will cause the Windows Setup compatibility scan step to report a failure. Here are the system requirements for updating to Windows 10 (as of 2017/1/5) Once an Upgrade failure takes place you'll see something similar to the following:- after clicking OK the task sequence will jump to the end without any further communication to the end user. At this point (or whenever it's convenient) check the UpgradeLogs$ share for new content. For every failure that occurs, a folder matching the Computer Name will be created. In that folder you'll find log files and bunch of XML files, these files will help you to troubleshoot the actual failure The WindowsSetupCompatScan.log file is generated by the Windows Setup compatibility scan results script and sample content is below. Note that it contains information about what the error was (including friendly text about the error) and the date/time and hardware that it occurred on. In addition to that log file you have the smsts.log file from C:\Windows\CCM\Logs\SMSTSLOG folder and two relevant Windows setup log files called setupact.log and setuperr.log from the C:\$WINDOWS.~BT\Sources\Panther\ folder. The failure highlighted in setupact.log is shown below (clear as mud right ?) The PowerShell script converts knownerrorcodes into meaningful text that won't give your end users a heart attack. You can add your own known error codes and friendly text by editing the PowerShell script in this section: Well that's it ! job done, I hope this helps you with your Windows 10 Upgrade Task Sequences. Tip: You can use the MailLog functionality described in the Windows-noob OSD Guides book to be notified of failures in real time. Summary Sometimes things don't go according to plan and the Windows 10 Upgrade task sequence can fail for a variety of reasons. Rather than having the task sequence fail during an actual upgrade, it makes sense to run a compatibility scan first and to assess the results of that scan before attempting the actual upgrade. If the compatibility scan does fail, you can notify your users with a helpful message and the task sequence will automatically capture the data you need to troubleshoot and resolve the upgrade issue. This guide helps you achieve that goal. Related Reading Windows 10 known error codes - https://support.microsoft.com/en-us/kb/3107983 Windows Setup /Compat ScanOnly - https://blogs.technet.microsoft.com/mniehaus/2015/08/23/windows-10-pre-upgrade-validation-using-setup-exe/ Create a task sequence to upgrade an operating system in System Center Configuration Manager - https://technet.micr...y/mt613172.aspx Task sequence steps in System Center Configuration Manager - https://technet.micr...y/mt629396.aspx Manage operating system upgrade packages with System Center Configuration Manager - https://technet.micr...echnet.10).aspx Downloads You can download a Microsoft Word copy of this guide here dated 2016/05/14. a deeper look at the Windows 10 Upgrade task sequence.zip You can download the PowerShell scripts used above here. WindowsSetupCompatibilityScanResults.zip

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

Hi All, Finally Managed to resolve the issue. As the CM was not able to find the CurrentSiteVersion, I did a search on registry to see if the current site version is available anywhere and the result was none. So I had to manually add the site version on registry in the following path HKLM\Software\Microsoft\SMS\Setup\Full version Please note when you add the version entry, you have to match it with the format same as in the hman log as the 'about' information in the console shows only 5.0.8xxx.xxxx (you need to add additional '0' after 5.0 (eg:5.00.8412.1000) Once you done this, restart sms_executive service and the updates will be available instantly in updates and servicing node. Happy imaging!!!

no problem I want this to work as well as it possibly can so any feedback and ideas are welcome, I think i'll put together another blog post with the remove computer from collection and update machine policy steps added (time willing)

I appreciate the assistance Niall! Everything has been working great so far! If anyone runs to issues upgrading to 1802, reach out to anyweb and he should be able to get you squared away! Thanks again, Mark

Importing a Start Menu with COPYPROFILE has been deprecated. https://blogs.technet.microsoft.com/yongrhee/2018/03/12/windows-10-using-copyprofile-for-the-start-menu-has-been-deprecated/ I would stay clear from using COPYPROFILE anyways. You can still configure the Default profile by injecting registry settings into C:\Users\Default\NTUser.dat or you can use provisioning packages.

In the event someone else comes across this, I managed to figure it out. The base MDT + SCCM Task sequence conditions on the Restore user State step was missing the condition Folder - %StateStore%\USMT exists by default. Once I added that condition, it then started running that step and the Refresh scenario is now working.

Hi Niall, I did a complete reinstallation of everything again using your exact IP addresses, usernames, domain names and it all worked flawlessly! The only snag I hit was I had to install the SCCM under the niall renamed sql account as it kept giving a login failed when logged in as user CM01\Administrator . Thanks for a great guide, next stop deployment land.

Why not use Installed Software, ProductName = iTunes ? I'd feel more confident about that vs. the two different ARP ones. Are you sure you HAVE iTunes older than v12? Can you look at a box you *know* has an older version? maybe it's not called exactly 'iTunes'; but is instead called something like ... 'Apple i Tunes The Media Player' or something... not 'iTunes'

Green Field implentation ? what on earth is that ? and please tell me you are not installing SCCM on a production domain controller, have you had any training with SCCM ?

Thanks! I didn't realise that this was a pre-release feature! Cheers, Pär

Good question, so i'll pin this topic ! You first need to consent to use Pre-Release features as shown here.. (in Administration, Hierarchy settings) Once done Turn on the Run Task Sequence step Then, close the ConfigMgr console, and open it again, and the new step will appear

Fantastic ! amazing what diffrence a set of quotes makes :-) Cheers and Thank you !!

Installed successfully, many thanks!

there are TWO branches of SCCM, current branch (which is what you are using) and Technical Preview (which is what is in this video) Current Branch is for production environments, and Technical Preview is for labs, you cannot get TP updates in a Current Branch release

Try running this PowerShell command for any users that've logged onto your reference PC: Get-AppXPackage -User username | Remove-AppxPackage This will remove windows store apps that're preventing sysprep from running

I do see this part of the execmgr.log at the time of clicking Install for my OSD: OnOptionalExecutionRequests attempted for package IVP00330 optional program * [QueueRequest: false RunOnCompletion : true QuietMode: true SDKCallerId: (null)] execmgr 10/17/2016 9:36:08 AM 496 (0x01F0) Validating package IVP00330 program * in the chain. The content request ID is {00000000-0000-0000-0000-000000000000} execmgr 10/17/2016 9:36:08 AM 496 (0x01F0) Creating an optional execution request for package IVP00330 program * execmgr 10/17/2016 9:36:08 AM 496 (0x01F0) Content is not available on the DP for this program. The program cannot be run now. execmgr 10/17/2016 9:36:10 AM 496 (0x01F0) OnOptionalExecutionRequests failed for program * : 0x87d01106 execmgr 10/17/2016 9:36:10 AM 496 (0x01F0) OR OnOptionalExecutionRequests attempted for package IVP002B9 optional program * [QueueRequest: false RunOnCompletion : true QuietMode: true SDKCallerId: (null)] execmgr 10/17/2016 9:42:07 AM 3908 (0x0F44) Validating package IVP002B9 program * in the chain. The content request ID is {00000000-0000-0000-0000-000000000000} execmgr 10/17/2016 9:42:07 AM 3908 (0x0F44) Creating an optional execution request for package IVP002B9 program * execmgr 10/17/2016 9:42:07 AM 3908 (0x0F44) Content is not available on the DP for this program. The program cannot be run now. execmgr 10/17/2016 9:42:09 AM 3908 (0x0F44) OnOptionalExecutionRequests failed for program * : 0x87d01106 execmgr 10/17/2016 9:42:09 AM 3908 (0x0F44) I have validated that the DPs for this client had all the packages that are part of this Task Sequence (which is ID: IVP00330 or IVP002B9, two different tests seen here). I have tested this same Task Sequence with an older SCCM client and the image works. It seems like I cannot install my Windows 10 Task Sequence or Windows 7 while using client 5.00.8412.1307. If I PXE or Media boot the computer, I can image with no issues.

hi guys, i know many people have requested to be able to download the guides here in PDF or Word DOC format so with help from a reader (Brian Thorp) we have just that ! now you can download the entire 18 part guide to using Configuration Manager 2012 in both PDF and WORD format and use whichever you want while on the go, Download the ZIP The windows-noob.com CM12 Guides in PDF and WORD format.zip a big thanks goes to Brian for compiling it all together so that you lot can have it remotely cheers ! niall

In Part 1 of this series we created our new LAB, we got the System Center 2012 Configuration Manager ISO and extracted it, then copied it to our Active Directory server. We then created the System Management container in AD, delegated permissions to the container, extended the Schema for Configuration Manager. We then opened TCP ports 1433 and 4022 for SQL replication between sites, installed some prerequisites like .NET Framework 4.0, added some features and then downloaded and installed SQL Server 2008 R2 SP1 CU6. We then configured SQL Server using SQL Server Management Studio for security and memory configurations prior to running the Configuration Manager 2012 setup to assess server readiness. Finally we installed a central administration site (CAS). In Part 2 we setup our Primary server with SQL Server 2008 R2 SP1 CU6. We then installed Configuration Manager 2012 on our primary server (P01) and verified that it was replicating to our central administration site (CAS) server. Then we configured Discovery methods for our Hierarchy and then configure Boundaries and Boundary Groups. In Part 3 we configured Discovery methods and configured boundaries and created a boundary group, we then configured them for Automatic Site Assignment and Content Location. In Part 4 we added the Application Catalog roles to our Hierarchy. We then configured Custom Client Device Settings and then deployed those settings to the All Systems collection on site P01. After that we created Custom Client User Settings and deployed them to the All Users collection in order to allow users to define their own User and Device affinity settings. In Part 5 we installed the WSUS server role (it is required for the Software Update Point role). We then installed the Software Update Point role on our CAS and Primary servers and we configured the SUP to support ConfigMgr Client Agent deployment which is a recommended Best Practice method of deploying the Configuration Manager Client Agent. In Part 6 we prepared our server for the Endpoint Protection Point role, and installed that role before configuring custom client device settings and custom antimalware policies. We then deployed those custom client device settings and custom antimalware policies to our newly created Endpoint Protection collections. Now we will add operating system deployment ability to our hierarchy, starting by adding Windows 7 X64. We will use the Build and Capture process to capture a WIM image which we can later deploy to targetted computers using network boot (PXE). PXE boot requires specific settings on our distribution points and the boot images used to deliver the operating system WIM images must also be enabled for PXE support. To get an overview of the Operating System Deployment process please review the following on Technet, and to see what's new is Operating System Deployment in Configuration Manager please see the following from Technet. Step 1. Enable PXE support on the distribution point Perform the following on the CAS server as SMSadmin In the ConfigMgr console, click on Administration, Site Configuration, Servers and Site System Roles, select our Primary Server (P01) as it is the site server hosting our distribution point role. double click on the Distribution Point role listed, select the PXE tab and place a checkmark in Enable PXE support for Clients, answer Yes when prompted about firewall ports (UDP ports 67, 68, 69 and 4011 ). next place a checkmark in the following options Allow this distribution point to respond to incoming PXE requests Enable unknown computer support Require a password when computers use PXE These options allow this distribution point to respond to incoming PXE requests and allow unknown computers to be supported, this is important as it allows you to do bare-metal deployments on unknown computers. That said, you should always think about the what-if scenarios, what-if someone PXE boots their computer by accident and sees the F12 menu, do you want them to automatically gain access to any deployed task sequences or protect yourself from possible damage, if in doubt, enable the password option for added security. When you choose to enable unknown computer support, you'll get a warning popup about required task sequences, take note of the warning and add a PXE password. Adding the PXE password does not prevent systems from being imaged but it does provide one additional layer of protection to stop systems getting imaged by unauthorised users. In addition, if you plan on using User Device Affinity select your UDA settings from the drop down menu. Note: If you want to do Zero Touch deployments then having a PXE password will involve someone having to be present at the computer in order to enter the password (in other words it won't be zero touch anymore...). Having this PXE password prompt is for your security, you do not want to be the one who has to explain to your CTO that all your servers have been imaged with Windows 7. By clicking on Apply you will add PXE support to the distribution point on the Primary server P01. If windows deployment services are not installed on the primary server then that service will be automatically added to that server as part of this configuration. If you have a primary server with multiple partitions and want the windows deployment services RemoteInstall folder to be on a specific drive then you'll need to manually install it prior to enabling this option. Tip: Monitor distrmgr.log on the P01 server to review installation of windows deployment services to support PXE boot on the distribution point on P01. See the screenshot below. Step 2. Distribute both boot images Perform the following on the CAS server as SMSadmin PXE support requires boot images on our distribution points, therefore we need both of our boot images distributed to the distribution points. On the CAS browse to the Software Library workspace, expand Operating System Deployment and locate the boot images. Right click on the X64 boot image and select Distribute Content. the Distribute Content wizard appears click Next and in the drop down Add menu select Distribution Point, select the distribution point listed (P01) continue through the Distribute Content wizard to completion. You can review the distrmgr.log file on CAS to see where it mentions that it is sending the boot image to our Primary server. Note: Don't forget to repeat the above process for both the 32 bit and 64 bit boot images, we need both Architecture boot images (x86 and x64) distributed to our distribution points. Step 3. Enable PXE support on both boot images Perform the following on the CAS server as SMSadmin In order for our computers to boot over the network we must also enable PXE boot support on our boot images. Failure to do so will mean that windows deployment services (which answers the initial PXE requests from the client computers) will fail to find any boot images and PXE boot will fail. On the CAS browse to the Software Library workspace, expand Operating System Deployment and locate the boot images. Right click on the X64 boot image and select properties. Select the Data Source tab and enable the following option Deploy this boot image from the PXE service point. while you are there, select the Customization tab and enable command prompt support (this gives us the ability to troubleshoot deploying images by pressing F8 during deployment, having this functionality will bring up a command prompt once the F8 key is detected, this will allow you to browse the computer in question and locate the SMSTS log files for troubleshooting.) Click Apply when ready, and answer Yes to the distribute images prompt. you will see an update distribution points wizard appear, click Next through the wizard until completion. This takes some time to complete, therefore give yourself some time to complete this task. Note: Don't forget to repeat the above process for the both the 32 bit boot image and the 64 bit boot image. We need both Architecture boot images (x86 and x64) distributed to our distribution points with the PXE options enabled on them. Tip: you can open the SMSProv.log file in CMTrace to review the progress of the boot image changes being made, infact in that log file you can even see that the CMtrace tool itself is now being copied into our boot images by default. Step 4. Enable the Network Access Account. Perform the following on the CAS server as SMSadmin The Network access account is needed during operating system deployment in WinPE to access content on the network which is referenced by the task sequence. This account might also be used during operating system deployment when the computer installing the operating system does not yet have a computer account on the domain. In the ConfigMgr console, select Site Configuration, then click on Sites and right click on our Primary site P01, choose Configure Site Components, Software Distribution (alternatively in the ribbon click on Settings, Configure Site Components, Software Distribution) Click on the Network Access Account tab to specify your Network Access Account user, choose new user, input the user credentials and test the connection (point it to the primary server as a connection test as that's where it will be getting content from) click apply and you are done. Step 5. Add the Windows 7 X64 operating system Perform the following on the CAS server as SMSadmin In System Center 2012 Configuration Manager RTM we use the Setup.exe method of deploying Windows which involves using the entire operating system image media (operating system installer). There are changes to this method in Service Pack 1, however this guide was written when RTM was the only version available, if you are using SP1 then read this post. In this step we will use the Build and Capture process based on an operating system installer image (Setup.exe), this is applicable for Configuration Manager 2012 RTM. In the Operating System Deployment section of the Software Library workspace, select Operating System Installers and right click, choose Add Operating System Installer point to the path where you have previously extracted your Windows 7 X64 files (I mounted the en_windows_7_enterprise_with_sp1_x64_dvd_u_677651.iso and extracted it to \\cas\sources\os\OS_Media\Windows7x64SP1) fill in some details about the image and click next through to completion of the wizard. Step 6. Distribute the Windows 7 X64 operating system Perform the following on the CAS server as SMSadmin In order to access any content it needs to be on a distribution point (which is essentially a network share). Right click on our newly added Operating System installer image and choose Distribute Content, add the P01 distribution point in the Add drop down menu, and continue through the wizard until completion Step 7. Create some folders and collections Perform the following on the CAS server as SMSadmin In order to simplify our operating system deployment process we will create some folders and collections in the following format, one Folder with two or more collections limited to All Systems within. Operating System Deployment (Folder) |___Windows 7 (Folder) |__________________Build Windows 7 (Collection) |__________________Deploy Windows 7 (Collection) The collections do not need any membership queries and will be empty, below is a sample of what to create in Assets and Compliance workspace, Device Collections. You can create them all manually in a couple of minutes or use a powershell script. In Addition to the above, browse to Software Library, Operating System Deployment and select the Task Sequences node, create a similar set of Folder names to further categorize your task sequences, this is optional but recommended as it will make it easier to work with task sequences in the future. Step 8. Create a Build and Capture Task Sequence Perform the following on the CAS server as SMSadmin Navigate to the Windows 7 Build folder in Task Sequences and Right click, choose Create Task Sequence choose Build and Capture a reference operating system from the choices fill in some details about the image, make sure to select a 64 bit boot image when build and capturing a 64 bit image, it is fine to deploy a 64 bit boot image with a 32 bit boot image but for the capture process you need to select a 64 bit boot image. for the Install Windows step, select our previously added operating system installer image and specify a local administrator password Note: [update] if you are completing this guide using Configuration Manager 2012 SP1 then this option is not available, instead, select the WIM file from a previously captured WIM image or point to the Install.WIM file on the Windows media. Please see this post for details for the Configure Network step, choose Workgroup and enter a workgroup name for the Install Configuration Manager step select the built in Configuration Manager client package, for installation properties fill in the FQDN of our primary site so that it knows where the Management Point is if you want to install applications or windows updates. SMSMP=P01.server2008r2.lab.local Tip: you could create a Configuration Manager Client Package from Defintion if you want to have control over the abilit to access this content directly from a distribution point. The built in package does not give you this flexibility as all options are greyed out. however in this example we will not be installing any windows updates or applications until later in the series, so go ahead and click through the next three screens without selecting anything Install Software Updates Install Applications System Preparation and then fill in some properties about the image you are about to capture At this point you are ready to PXE boot your computer. fill in the Capture image settings and make sure that the user specified has appropriate access to the share specified otherwise the capture will fail continue the wizard through to completion. Step 8a. Edit the task sequence Tip: The steps below are for Configuration Manager 2012 SP1 and later otherwise Windows may install on D: Edit the task sequence by right clicking and choose Edit Note: make sure the step occurs before the Apply Operating System Step The step should be a Set Task Sequence Variable step called Set OSDPreserveDriveLetter and set the variable OSDPreserveDriveLetter to false as in the screenshot below when done editing, click Apply and Ok to close the Task Sequence Step 9. Deploy the Task Sequence Perform the following on the CAS server as SMSadmin Locate our newly created task sequence, right click and choose Deploy select the Build Windows 7 collection and click ok to the message (we will add our client in the next step) for Deployment Settings keep the deployment as Available (optional) and make sure to select Make available to boot media and PXE, that makes it three places that you need to select a PXE option:- * on the PXE tab of the distribution point properties * on the Data Source tab of the boot image *on the Deployment Settings of the task sequence deployment continue through the rest of the task sequence deployment wizard until completion. Step 10. Import computer into the Build Windows 7 collection Perform the following on the CAS server as SMSadmin Next you need to import a computer into our Build Windows 7 collection so that it will have the Build Windows 7 task sequence made available to it. To do this click on devices in Assets and Compliance, and in the ribbon click on Import Computer Information. select the second option, import single computer enter the name and MAC address for this computer (for name you can call it whatever you want, for MAC address use the MAC address of the Network card used to PXE boot the computer.) review your data in the Data Preview for the Choose Target Collection step enter the Build Windows 7 collection and then click through the rest of the wizard until completion. The above creates a Direct Membership query in the membership rules tab of the Build Windows 7 collection. Refresh the collection so that you can see the imported computer before continuing, if it doesnt appear ty to update membership then refresh. . Step 11. PXE boot our computer Perform the following on the virtual machine used for build an capture On your virtual machine, PXE boot and you should see the standard F12 menu for PXE boot. You did set the network card as the first boot device didn't you ? ;-) If you don't see any PXE messages then check bios boot order on your Virtual Machine (use Legacy Network cards in HyperV) and reveiw the SMSPXE.LOG. Tip: To troubleshoot PXE issues open the SMSPXE.log file located on D:\Program Files\SMS_CCM\SMSPXE.LOG on your Primary server P01 using CMTrace to get a live scrolling view of whats happening. Notice that the PXE boot screen gives you a lof of information which can help with your troubleshooting, such as the Client IP address and ip address of your DHCP server. Press F12 when prompted... enter your PXE password select your Build and Capture Task sequence and off it goes, time for a well deserved break while Configuration Manager automatically does it's thing and captures your master Windows 7 image. Tip: if you want your Organization name listed instead of IT Organization change it in Computer Agent section of the Default Client Device Settings. and that's it, the image gets deployed too our virtual machine and finally captured to our network share that we specified in the task sequence in a later part of this series we will deploy the captured image using a separate task sequence, and customize it to work with different hardware, add some applications and windows updates. In the next part, we will learn how to Deploy Applications

This list of guides (think of it as a living index) will be updated by me whenever I write a new guide for the new versions of System Center Configuration Manager (Current Branch) or System Center Configuration Manager (Technical Preview) and how they incorporate with Microsoft Intune. These guides are broken down into three different sections: System Center Configuration Manager (Current Branch) System Center Configuration Manager (Technical Preview) Setting up PKI in a lab on Windows Server 2016 The Current Branch release is meant for your production deployments and the Technical Preview releases are for testing new upcoming features in the product, and are aimed at Lab use only. The PKI guides are added in case you want to experiment with any roles requiring certificates using SCCM. If you are looking for some of my other guides then please check below: Microsoft Intune (standalone) in Azure step by step guides are here Microsoft Intune (hybrid) guides look here (over 61,103 views as of July 2017) Configuration Manager 2012 guides then look here (over 1 million views as of July 2017) Configuration Manager 2007 guides then look here (over 948388 views as of July 2017) Microsoft Deployment Toolkit guides are here SMS 2003 guides are here (over 10423 views as of July 2017) cheers niall System Center Configuration Manager (Current Branch) Installation - How can I install System Center Configuration Manager (Current Branch) Configuring Discovery - How can I configure discovery for System Center Configuration Manager (Current Branch) Configuring Boundaries - How can I configure boundaries in System Center Configuration Manager (Current Branch) Using Updates and Servicing in Offline mode - How can I use Updates and Servicing in Offline mode in System Center Configuration Manager (Current Branch) Using Updates and Servicing in Online mode - How can I use Updates and Servicing in Online mode in System Center Configuration Manager (Current Branch) Setting up the Software Update Point - How can I setup Software Updates in System Center Configuration Manager (Current Branch) Installing the Client agent - How can I configure client settings and install the ConfigMgr client agent in System Center Configuration Manager Current Branch Upgrading to System Center Configuration Manager (Current Branch) version 1602 from System Center Configuration Manager (Current Branch) version 1511 How can I use the Upgrade Task Sequence in System Center Configuration Manager (Current Branch) ? How can I use servicing plans in System Center Configuration Manager (Current Branch) to upgrade Windows 10 devices ? How can I deploy Windows 10 with MDT 2013 Update 2 integrated with System Center Configuration Manager (Current Branch) Setting up PKI in a lab on Windows Server 2016 Part 1 - Introduction and server setup Part 2 - Install and do initial configuration on the Standalone Offline Root CA Part 3 - Prepare the HTTP Web server for CDP and AIA Publication Part 4 - Post configuration on the Standalone Offline Root CA Part 5 - Installing the Enterprise Issuing CA Part 6 - Perform post installation tasks on the Issuing CA Part 7 - Install and configure the OCSP Responder role service Part 8 - Configure AutoEnroll and Verify PKI health

Hi The problem was the fact that the SCCM 2007 agent was still installed. After uninstalling the agent I managed to take a capture, thanks for your help in this.

SD, Although the errors aren't exactly the same, I had issues with adding a '12 client where a '07 was previously installed. I too wasn't able to assign a site code. Check the client's registry to make sure it's not getting an old site code. HKEY LOCAL MACHINE/Software/Microsoft/SMS/Mobile Client, Key Name: Assigned Site Code. If it's pointing to the old site, delete it and try reassigned the client through the client's CCM GUI.

Double check that you have all the IIS-Pre Reqs installed! got the same problem when i left out ASAPI Filters and something else.