anyweb

no problem if you run into any issues let me know

well you shouldn't be deploying Windows 10 with that version of the ADK or with those boot images, there are ways of doing it but they are all workarounds, you need to uninstall ADK 8.1, then reboot, install Windows ADK 1511, and update your boot images after that, then try the task sequence again... here's how to do that https://www.windows-noob.com/forums/topic/12852-how-can-i-upgrade-to-system-center-2012-r2-sp1-with-mdt-2013-update-1-integrated/

see your first error cannot find path 'DS001:\Operating Systems\Windows 10\Windows 10 Enterprise in Windows 10 Enterprise x64 install.wim' because it does not exist."

ok your failure is shown below and is repeated a few times in the log, basically dism can't inject any drivers... <![LOG[Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"]LOG]!><time="12:45:52.993-120" date="07-01-2016" component="OSDDriverClient" context="" type="1" thread="1764" file="commandline.cpp:828"> <![LOG[Process completed with exit code 50]LOG]!><time="12:45:53.072-120" date="07-01-2016" component="OSDDriverClient" context="" type="1" thread="1764" file="commandline.cpp:1124"> <![LOG[uExitCode == 0, HRESULT=80070032 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,548)]LOG]!><time="12:45:53.087-120" date="07-01-2016" component="OSDDriverClient" context="" type="0" thread="1764" file="sysprepdriverinstaller.cpp:548"> <![LOG[Dism failed with return code 50]LOG]!><time="12:45:53.087-120" date="07-01-2016" component="OSDDriverClient" context="" type="3" thread="1764" file="sysprepdriverinstaller.cpp:548"> <![LOG[AddPnPDriverToStore( pszSource, sTargetSystemDrive, sTargetSystemRoot, wProcessorArchitecture), HRESULT=80070032 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,658)]LOG]!><time="12:45:53.087-120" date="07-01-2016" component="OSDDriverClient" context="" type="0" thread="1764" file="sysprepdriverinstaller.cpp:658"> <![LOG[Failed to add driver to driver store. Code 0x80070032 it looks like you are using an unsupported combination of boot media/dism and that's why it's failing to install drivers what version of SCCM is this ? what version of the ADK have you got installed ? and what version of boot wim are you using in this task sequence ? (press f8 and do ver)

that remains to be seen, where did you post the new log ?

can you press f8 before the failure, and then capture the log after the apply drivers package step, i don't see that step referenced in your log. Also it looks like you have no network or DNS issues Error. Received 0x80072ee7 from WinHttpSendRequest.]LOG]!><time="13:17:45.470-120" date="07-01-2016" component="TSManager" context="" type="1" thread="1132" file="libsmsmessaging.cpp:9044"> <![LOG[unknown host (gethostbyname failed)]LOG] so when you press F8, wait for the failure, then do an ipconfig, do you have an ip or not ?

as regards your questions let's take them one by one correct, Jorgen blogged the process here Upgrading to 1511 is a no brainer, there were some issues listed here. Why wait with the upgrade to 1602, i'd recommend you upgrade to 1511, and then to 1602. yes you can still deploy Windows 7 even with SCCM 1602, the ADK supports it. yes i'd do that, as i've stated above, the only thing to be careful with is after updating to 1602 there's an update rollup for 1602, so be aware of issues with the client upgrade option discussed here.

disable javascript and macros and read this https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/ http://arstechnica.com/security/2016/06/meet-jigsaw-the-ransomware-that-taunts-victims-and-offers-live-support/

if you update machine policy a few times does it work ? what does execmgr.log reveal ? the error translates to

it's required if you care about deploying this task sequence to computers that don't meet the criteria (servers, low ram, low disk space...) of course if your collection queries do this then you can remove it.

that error still shows up, i set the timeout for 1 minute and waited. Fyi.

i can test and come back to you !

wouldn't it be better to have a good backup strategy in place for your current infrastructure, and if/when a problem occurs recover your site and restore the data, some links to get you started... How can I backup System Center 2012 Configuration Manager ? Restoring Backups - https://blogs.techne...or-restoration/ Backup and Recovery in Configuration Manager - http://technet.micro...BKMK_SiteBackup Support Tip: A Backup Site Server maintenance task may fail to run in ConfigMgr 2012 - http://blogs.technet...igmgr-2012.aspx How to recover a Configuration Manager 2012 site using a restored database - http://stevethompson...-a-restored-db/ SQL Server backup recommendations for Configuration Manager - http://stevethompson...ration-manager/

<![LOG[Error. Received 0x80072efd from WinHttpSendRequest.]LOG]!><time="19:20:49.336+480" date="06-25-2016" component="TSPxe" context="" type="1" thread="1104" file="libsmsmessaging.cpp:9044"> <![LOG[connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,812)]LOG]!><time="19:20:50.355+480" date="06-25-2016" component="TSPxe" context="" type="0" thread="1104" file="libsmsmessaging.cpp:812"> <![LOG[socket 'connect' failed; 8007274d]LOG]!><time="19:20:50.355+480" date="06-25-2016" component="TSPxe" context="" type="3" thread="1104" file="libsmsmessaging.cpp:812"> <![LOG[hr, HRESULT=80072efd (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9093)]LOG]!><time="19:20:50.355+480" date="06-25-2016" component="TSPxe" context="" type="0" thread="1104" file="libsmsmessaging.cpp:9093"> <![LOG[sending with winhttp failed; 80072efd] you have DNS and/or networking issues, when it fails can you press F8 and type ipconfig, do you get a valid ip address ? can you ping the FQDN of your management point ?

Prioritizing local MP http://CSD10.csd.local. SMSPXE 6/23/2016 8:33:10 AM 3404 (0x0D4C) RequestMPKeyInformation: Send() failed. SMSPXE 6/23/2016 8:33:10 AM 3404 (0x0D4C) still having issues contacting the Management point, take a look at this post to see does it help you resolve your problem https://www.windows-noob.com/forums/topic/7281-management-point-pxe-boot-error-80004005-after-sp1-upgrade/

so are both architecture boot images distributed, and enabled for PXE and attached to the task sequence you are testing ?

have you tried reinstalling the Management Point role ?

how did you create the media ? what version of SCCM are you using ? what version of Windows 10 are you deploying ? what boot image are you using and can you attach the smsts.log ?

if the computers are installed with MDT then why would you create task sequence in Configmgr ? you can always install an MDT created image using Configmgr, then after the image is laid down you can run another script or package to uninstall the configmgr client agent and all associated things (such as certificates), the question is why do you want to do this ?

can you attach the entire smsts.log so we can see what additional actions occur during the ts.

thank you for buying the book i hope you like it ! so do you want to separate apps by architecture in order to target operating systems with different architecture ? you can use deployment types to define what software gets installed on what architecture, look at the Requirements tab and select an os with a specific architecture, that way the software will only install if the requirements are met (eg: is x64) you can of course then target (deploy) that app to a specific collection containing only the architecture matching the requirement,.

hi, even though SQL Server 2016 was shipped June 1st 2016, it is not supported yet for SCCM Current Branch, so you'd be advised to use SQL Server 2014 until it does become supported...

can you attach the smsts.log file ?

although this example is for Windows 8.1 it's the exact same method for Windows 10 (unless you are talking about the Upgrade task sequence which i cover here)

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. Next you learned 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. You saw how easy it was to apply an Update Rollup containing a hotfix for 1602. In this post you'll return to Windows 10 servicing, and learn a method of dealing with an installed language pack (which would cause the servicing plan to fail otherwise). Windows 10 servicing using Servicing Plans currently (as of June 12th, 2016) only works if the System UI language matches the Windows 10 upgrade edition you are updating. To get around this problem you have to do the following: Determine the language pack installed Copy a special file to those systems that match a particular language pack Make sure the correct language pack referenced in that file is available on a network share Target those systems with a servicing plan (already completed in this part) Step 1. Create some Collections You'll need to identify what language pack is installed (set as the System UI), to do that you can create collections based on a few things namely: Windows 10, for example Windows 10 Enterprise The Build number, for example 10240 Language pack installed as the System UI, or LocaleID, for example Swedish is 1053 and that can be done via queries such as the following: select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0" and SMS_G_System_OPERATING_SYSTEM.BuildNumber = "10240" and SMS_G_System_OPERATING_SYSTEM.OSLanguage = "1053" In the query above, the values looked for are: SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0" SMS_G_System_OPERATING_SYSTEM.BuildNumber = "10240" SMS_G_System_OPERATING_SYSTEM.OSLanguage = "1053" Assuming you are deploying Windows 10 Enterprise, the only two values you'll need to think about are the build number and language (locale ID). You can see a full list of locale IDs here. Remember that Windows 10 servicing is all about moving from one build to the next build number eg: build 10240 > 10586 so you need to create collection of devices that are running the build you want to service. Note: The script mentioned below depends on a limiting collection called All Workstations which was created in this post. If you haven't run that script yet, please do so otherwise you'll see errors. You could create the collections manually by manipulating the query used above or use a PowerShell script to do the hard work for you. In the downloads section of this guide you'll see a script called CreateServicingPlan_LP_DeviceCollections.ps1. Download it, open it in Windows PowerShell ISE and edit any variables prior to running it. This script will create collections for the following languages and for Windows 10 Enterprise version 1507, build 10240: Danish Finnish German Norwegian Swedish and you can easily edit it to create more collections with the corresponding queries. Below is an example output when the script runs. after the script has run, you'll see the new Device Collections have been created and populated with the correct devices Step 2. Create a text file for each language pack In order to workaround the Servicing Plan language pack problem, you need to create a file that points to a network share containing the language pack you intend to support. The file will should be named setupconfig.ini and it should contain valid data such as below: [CommandLines] /InstallLangPacks \\<server>\<share> Both <server> and <share> must be valid values and unique for the language pack in question, so if you intend to support the Swedish Language Pack you'd place the Swedish Language Pack in a share and adjust the setupconfig.ini file for machines with the Swedish language pack installed as follows: [CommandLines] /InstallLangPacks \\CM01\Sources\OSD\OS\LP\1511\x64\Swedish Note: If you followed the following post, you will already have the language packs copied to the share mentioned in the setupconfig.ini example above. The <share> you specify in the text file must contain a sub-folder matching the language pack as shown below and in that folder, the corresponding lp.cab file for the version of Windows you are updating to (in this example, version 1511) is present Repeat the above exercise for each language you intend to support, this will mean you could have several setupconfig.ini files in their own respective folders like so: \\cm01\Sources\OSD\OS\LP\setupconfig ini files\swedish \\cm01\Sources\OSD\OS\LP\setupconfig ini files\danish \\cm01\Sources\OSD\OS\LP\setupconfig ini files\finnish \\cm01\Sources\OSD\OS\LP\setupconfig ini files\norwegian \\cm01\Sources\OSD\OS\LP\setupconfig ini files\german Step 3. Copy setupconfig.ini to computers with the appropriate language pack You need to the modified setupconfig.ini (with valid information pointing to the correct server and share containing the appropriate language pack) to computers you intend to service with the appropriate language pack installed. Now that you've got the collections created that should be easy enough. The file needs to be copied to the following destination on these computers: %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\ if the destination doesn't exist, you must create it. You can create a package/program to copy the appropriate file to all computers with the matching language package installed. To do that, do as folllows: In the ConfigMgr console click on Software Library, then click on Application Management, Packages. Right click and choose Create Package. Fill in the following details: Name: Swedish Language Pack - SetupConfig.ini Source Folder: \\cm01\Sources\OSD\OS\LP\setupconfig ini files\swedish when prompted to create a program, choose Standard Program use the following settings for the program Name: copy SetupConfig.ini Command line: cmd.exe /c echo d | xcopy /c /y "Setupconfig.ini" "%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\" Run: Hidden Program can run: Whether or not a user is logged on as per the screenshot: for requirements change it to Windows 10 x64 as shown here: and continue through the wizard until completion Now that the package is created, you need to distribute the content, right click on the package and choose Distribute Content. add one or more distribution points and continue through that wizard until completion. And in order to get the file on the computers, you must deploy the package, so go ahead, right click on the package and choose Deploy. In the Deploy wizard, for collection choose the collection that matches the language pack the setupconfig.ini file was created for, in this example, Swedish, so use SUM - Windows 10 x64 (1507) Swedish LP for Deployment Settings, use a purpose of Required for Schedule, click on New and choose As soon as possible and continue through the Deploy Software Wizard until completion. Tip: You can use Configuration Items to verify the existence of the file prior to running the Servicing Plan and create collections based on compliance. This would ensure that the ini file is present on the device prior to the servicing plan running. Step 4. Review the upgrade on Windows 10 devices with language packs installed 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. Everything should be in place for the update. But first, you might want to check that the setupconfig.ini file is where it should be on the client. and once the policy is received by the client the update shows up in Software Center notice the update warning text... and off it goes... during the upgrade, the setupact.log log file will reveal information about the language pack involved and where it expects to find it (taken from the setupconfig.ini file) and the computer will restart and then the upgrade will being in earnest and after a while it's done after logging in you can see the new version of Windows 10 and the language is still in place after servicing, result ! Summary With workarounds in place you can now upgrade your Windows 10 devices to the latest version of Windows 10 using servicing plans created in System Center Configuration Manager 1602 (Current Branch) even if your computers have language packs installed. Previously you'd need to use the Upgrade Task Sequence to deal with that scenario. Related Reading How can I use servicing plans in System Center Configuration Manager (Current Branch) to upgrade Windows 10 devices ? Locale IDs - https://technet.microsoft.com/en-us/library/cc287874(v=office.12).aspx#Locale A deeper look at the Upgrade task sequence in System Center Configuration Manager (Current Branch) How can I deal with languages in the Upgrade Task sequence using System Center Configuration Manager (Current Branch) Downloads You can download a Microsoft Word copy of this guide here dated 2016/06/12 And here's the PowerShell script used to create the collections. CreateServicingPlan_LP_DeviceCollections.zip