anyweb

so to summarize, you have captured the Windows 7 wim using SCCM correct ? and when you deploy it using a task sequence Windows ends up on D: ? when using the osdpreservedriveletter=false, what drive letter does Windows end up on ? cheers niall

hi, look at your logs again, it's ok if you missed it, so did I Feature update to Windows 10 <SKU>, version 1607, <language> are the actual updates for Windows 10 1607, so it's working fine ! i.e. the Windows 10 upgrades are now known as Feature Updates... cheers niall

i havn't tried it yet but hope to do so this weekend, i'll ask Microsoft to comment in the meantime

is the computer in the collection that you've deployed the task sequence to ? did you update machine policy on that computer ?

interesting problem, are all other updates showing in Software Updates ?, have you selected Upgrades ?

hi it's seems it's failing directly after the reboot after installing windows updates Failed to set log directory. Some execution history may be lost. The system cannot find the file specified. (Error: 80070002; Source: Windows) due to this the task sequence cannot continue hence the presence of that folder, as a test, disable the install software updates sstep on your image that was captured on a vm (good practice indeed) and see does it complete as normal, if so, then you must focus on the Install Software Updates step and why it's causing you problems is this Windows 7 you are deploying ? if so have you tried using Offline Servicing to inject those updates into the captured wim file ?

I would like to know how if i can install a virtual server on my own PC. (For practice) if you are running windows 8, 8.1 or windows 10 then you can enable the HyperV feature and run virtual machines on your pc provided that it has enough ram (memory) and a virtual capable cpu (check the bios) as regards guides, there are many here build yourself a lab first and then start testing SCCM, if you need help just ask

ok great, did you notice any difference after re-deploying the task sequence (in execmgr.log on affected computers)

redeploy the ts just means re-create the deployment, not re-distribute the content

i've seen this problem before 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) to resolve either redeploy the task sequence (short term, the problem will come back), or reduce the number of deployments targeted at the computer, eg: if the computer is targeted with many updates or task sequences, reduce them drastically, and this is probably true seeing as it's windows 7 (think of the updates...), this is the long term fix lastly it can also mean that the policy for the task sequence hasn't arrived yet (the message is confusing...), and this could be due to waiting for a scehduled restart from another program or windows updates, either way to improve the situation, you must reduce the number of deployments aimed at that computer (or computers)

have you tried the R2 toolkit, didn't it work for you, if not what was the error ?

are you using copyprofile ? if so that could be the cause of your issues.

that error translates to Same as HTTP status 401 - the requested resource requires user authentication. Source: Windows Update Agent -----

hi can you attach the execmgr.log pls

no you don't but you might have this problem I've got a new version of this logic now and i might blog it soon as it requires no drivers and just re-renders the HTA

here's a start https://blogs.technet.microsoft.com/heyscriptingguy/2011/12/14/use-powershell-to-find-and-uninstall-software/

you can link it to SCCM but it will disrupt the existing setup, clients either get updates from MS, from SCCM (via the sup) or via WSUS, the recommended approach here would be to start afresh with your WSUS setup for SCCM, and yes it's fine to host it on another server with it's own database. Once you switch your clients to get updates from SCCM then the backend infrastructure (SCCM+SUP) must be ready to deliver those updates, and that won't happen with your existing WSUS infrastructure Let's see what the others say though, you may get additional advice, cheers niall

sounds like network driver issues can you attach the smsts.log ?

hi Peter, is Microsoft aware of this ?

have you seens henks post here, it explains the steps a bit clearer

drivers were present in the SUP in SCCM back in SCCM 2007 however, that Update Classification was removed in SCCM 2012 due to filling up the database with loads of duplicate info that was difficult to filter...

is ssl enabled on your WSUS server ?

yep that's exactly what you need to do, one step per detected hardware.

are you sure you followed everything in the KB, double check each step, then trigger a sync on your SUP

is your console installed locally, or remotely ? did you also upgrade the console after the upgrade ?