SCCM upgrade from 1709 to 1903/1909 X64 en-us

Question

SCCM upgrade from 1709 to 1903/1909 X64 en-us

karthik palani 661

Hi All,

I have SCCM CB 2006 in which we are trying to upgrade 1709/1809 machines using Windows 10 feature updates.
Seems after deploying 1903/1909 consumer edition on 1709 machine, it trigger the status as compliant in SCCM. But no installation started on the end-user machine

Validated wuahandler, updatesdeployment, updateshandler, updatesstore etc... unable to find any error message. All looks fine

No download happen in ccmcache. Is there anything i need to verify to upgrade 1709/1809 machines. Please advice

Reza-Ameri 17,341 Reputation points Volunteer Moderator

2021-05-02T17:52:42.047+00:00

There shouldn't be any issue.
Verify you have deploy all other required updates and you may check log files in the client side.

3 answers

Your answer

Reza-Ameri 17,341 Reputation points Volunteer Moderator

2021-05-02T17:52:42.047+00:00

There shouldn't be any issue.
Verify you have deploy all other required updates and you may check log files in the client side.

Answer 1

Amandayou-MSFT 11,156

Hi @karthik palani ,

After deploying the feature update, there might be seven steps to troubleshoot the common issues.

Step 1: We could check Policyagent.log. When policy is received, the following entry is logged in PolicyAgent.log:

We could check if Deployment Unique Id on the console is consistent with policy id displayed in PolicyAgent.log.

Step 2: Software update would be checked if it is required by client, kindly check UpdatesStore.log. UpdateStore.log would record updates as missing if they are required. If it is not required or has been installed by client, there is no record in this log.

Step 3: If the update is required, the content could be detected before downloading. We could refer to UpdatesDeploymentAgent.log.

Step 4: The content could be downloaded. we could refer to UpdatesHandler.log, CAS.log, and ContentTransferManager.log.

Step 5: After the download is completed, detection could be followed before installation. We could refer to UpdatesHandler.log,ScanAgent.log, UpdateStore.log, WindowsUpdate.log and WUAHandler.log.

Step 6: Software update could be installed. We could refer to Windowsupdate.log and UpdatesDeployment.log.

Step 7: After the updates are installed, Updates Deployment Agent checks whether any updates require a reboot, and then it notifies the user if client settings are configured to allow such notification. We could refer to UpdatesDeployment.log and UpdateStore.log.

Here is an article about some detailed log screenshots.
Using log files to track the software update deployment process

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Amandayou-MSFT 11,156 Reputation points

2021-05-07T09:18:47.707+00:00

Hi,

Just checking in to see if there is any update. May we know the current status of the question? If there is any other assistance we can provide, please feel free to let us know, we will do our best to help you.

Thanks and regards,
Amanda
karthik palani 661 Reputation points

2021-05-07T14:45:24.65+00:00

Thanks Amanda for your followup

No still the issue persist, i dont see any error in wuahandler and other updates logs. I found an warning message in policyagent.log in all user machines

I followed the steps mentioned in http://blog.configmatt.com/2018/03/resolving-issues-with-user-policy.html and restarted the server too but still upgrade package is not starting to install. Even tried reinstalling the sccm client, any other suggestions please
Amandayou-MSFT 11,156 Reputation points

2021-05-10T09:34:01.15+00:00

Hi,

Thanks for your reply.

I research Microsoft Learn, it says we increased the values of MaxFieldLength and MaxRequestBytes on the IIS server from the default of 16384 to 32768 (may vary according to ticket size) and this fixed the issue. And we could try to configure it again.

Detailed information could be referred to this article:
https://learn.microsoft.com/en-us/archive/blogs/ashishsingh/windows-authentication-for-accounts-with-large-kerberos-tickets-may-not-work-despite-having-maxtokensize-in-place
karthik palani 661 Reputation points

2021-05-12T12:13:49.13+00:00

Yes i increased the IIS value as mentioned above, not sure still i am getting the warning and no OS upgrade is happening

I deployed business edition/consumer edition also. All logs are fine except Policy agent warning message as shown above

In IIS log, i can see 401 error for most of the client machine IP's. Should i need to reinstall MP and try. Let me know if u cud suggest something please
Rahul Jindal 10,911 Reputation points

2021-05-12T12:38:13.15+00:00

You didn't respond to what I asked - "Consumer edition would mean that the devices are running home edition? Are you managing them as workgroup devices?"

Also, if you are experiencing the same thing with Business edition then it is possible that the feature update is not being scanned as applicable. What is the compliance status being reported to ConfigMgr for the devices in question?
karthik palani 661 Reputation points

2021-05-12T15:51:40.66+00:00

Hi Rahul,

Sorry missed the point, the device are running Windows 10 v1709 Pro and all are domain joined.

I deployed consumer because it says 400 required and business edition is only 50. I tried both Rahul, still the same
karthik palani 661 Reputation points

2021-05-12T15:53:29.32+00:00

Also it shows compliant in SCCM status
Rahul Jindal 10,911 Reputation points

2021-05-12T16:17:54.573+00:00

Thanks for the answer to my query. Compliant doesn't always mean that the update is installed. It can also mean that the update is not required. Please see if that is the case here. Also, please check for update scan status against these devices. There are built in reports that you can run to gather all of this.

Answer 2

Rahul Jindal 10,911

Consumer edition would mean that the devices are running home edition? Are you managing them as workgroup devices?

Answer 3

karthik palani 661

Dear All,

Thanks for your support

Issue seems to be in co-management settings. Under workload, update policies are pointed to PILOT INTUNE which offloaded the update feature to MDM.

After changing back to configuration manager, Issue got fixed

Amandayou-MSFT 11,156 Reputation points

2021-05-19T01:25:39.377+00:00

Hi,

Thank you very much for the update and we're glad the problem is solved now. If you have any questions in future, we warmly welcome you to post in this forum again.

Have a nice day!

Regards,
Amanda

Share via

SCCM upgrade from 1709 to 1903/1909 X64 en-us

3 answers

Your answer