Jeff May-Stahl

I have found other posts with the same issue but no resolutions. It seems that the Feb and March CUs broke something, preventing upgrade to 1709. Upgrading to 1703 seems to be working. On my systems, removing the latest CU fails. I'm not sure if they are unable to be removed in general or if it is just my environment.

Interestingly, the upgrade does work when run via command line manually from the package folder that sccm downloads to the machine.

It seems to work with 10586.1358 but not the machines that are 10586.1478

Yes. They were updated earlier this month.

Windows 10 1511 Having the same issues with 1607 machines. Going to 1709 with both.

The SP4 logs are more indicative of most of our machines. The setupact log just stops after the errors as in the screen shot I posted (Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (409): Finished reading Device Inventory. 0 Devices). In both SMSTS logs it just sits at the executing command line, the device says running action:Upgrading Operating System and SCCM says in progress. And it will sit there for days until the device is restarted and the deployment is deleted. The desktop setupact log does look different but the smsts and device acted the same and it never upgraded. It worked on about 150 machines, now it doesnt work on any. I tried checking Ignore any compatability messages, tried using the dynamically update windows. No change.

This seems to be where its getting held up

Ok, Here are the logs from a SP4 and a Desktop. Thank you! 1511DesktopLogs.zip 1511SP4Logs.zip

My upgrade task sequence to go from 1511 and 1607 to 1709 was working perfectly. Now it just hangs forever (days) when it starts the upgrade the task os step. There are no errors in the SMSTS log, it just stops at the executing command line step. Setupact and Setuperr logs show some errors but I could use some help figuring out what happened to make this stop working!

I am running into this same issue while trying to upgrade 1511 to 1709 via task sequence. Worked fine on all my 1511 desktops but will not work on any of my Surface Pros or VMs. Acutally will not run on any 1607 machines either. Just hangs forever.

I have been upgrading systems from 1511 to 1709 with a task sequence and it was working fine until I got the mobile devices. This task sequence was tested to work on the Surface Pros fine. I upgraded all the desktops with no problems. But now when deployed to 64 Surface Pros only 4 were successful. The rest just got stuck "in progress" at the executing command line step "Executing command line: "C:\_SMSTaskSequence\Packages\P010001A\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable"

I tried reenabling GPO and pointing to this server but it still gives the Group Policy Settings overwritten by higher authority (Domain Controller) error

I am using SCCM 1710 and attempting to use servicing plans for the first time and am totally frustrated. The client never downloads the update and results in an error 0x87D00692 - Group Policy conflict. The UpdatesDeployment and WUAHandler logs show essentially the same error which I have attached a screenshot of. At first, when I saw this, it would say that WSUS was pointing to my old server which made sense. I have since disabled all group policy having to do with Windows Update as I want SCCM to control updates but I am still getting the errors showing a Group Policy conflict. rsop and GPResults both don't show anything to do with Updates. I am at a loss. Do I just re-enable the GPO and set it to point at my new server? (WUAHandler log on the server shows the same errors)

I am setting up SCCM CB for software updates and have a question. I have set up several baselines and also some ADRs. I was wondering though, after I did it, what the best practice is with Windows 10 updates. I did not include the Cumulative Updates in the baseline, assuming they'll get done through the ADRs but now I am wondering if I should. What is the rule of thumb here? Thanks!

1702 is installed on a new server, new hierarchy. What is the best practice to upgrade the clients? The new sccm is discovering everything, I created a pre-production test collection and set the client to upgrade that collection but it is not working.