locked
SCCM 1806 Software updates task hangs during OSD RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    3
    Sign in to vote

    As the title says, TS gets stuck at Software updates task.

    Seems to be some kind of communication issue, but I haven't figured out solution and running out ideas.

    It finds correctly, what updates are required, some even downloads nicely to ccm cache folder, but at some point it just gets stuck at "Downloading x of y updates".

    In ContentTransferManager.log and in LocationServices.log I see that the location requests go out nicely. The client also receives answers until some point, then it stops. Can't see any errors anywhere.

    Example from logs, where it doesn't receive any response for location requests, won't copy full logs here.

    Contentransfermanager.log :
    --------------------------------
    Starting CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C}. ContentTransferManager 24.09.2018 11:32:48 6820 (0x1AA4)
    Created CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C} for user S-1-5-18 ContentTransferManager 24.09.2018 11:32:48 6820 (0x1AA4)
    CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C} entered phase CCM_DOWNLOADSTATUS_WAITING_CONTENTLOCATIONS ContentTransferManager 24.09.2018 11:32:48 6172 (0x181C)
    Queued location request '{A37615FA-B928-4578-B926-1E4DDE57BA15}' for CTM job '{980E40A9-C2A7-4A4A-B0EC-579967A91C2C}'. ContentTransferManager 24.09.2018 11:32:48 6172 (0x181C)
    Starting CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683}. ContentTransferManager 24.09.2018 11:32:49 6820 (0x1AA4)
    Created CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683} for user S-1-5-18 ContentTransferManager 24.09.2018 11:32:49 6820 (0x1AA4)
    CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683} entered phase CCM_DOWNLOADSTATUS_WAITING_CONTENTLOCATIONS ContentTransferManager 24.09.2018 11:32:49 4144 (0x1030)
    Queued location request '{BADD25DA-598B-4C17-A372-C14AA8D7F68F}' for CTM job '{A3AA13F4-B1D7-45DE-B563-C8BA17E27683}'. ContentTransferManager 24.09.2018 11:32:49 4144 (0x1030)
    ---------------------

    LocationServices.log :
    --------------------
    Created and Sent Location Request '{A37615FA-B928-4578-B926-1E4DDE57BA15}' for package 27eeda63-dfc2-4c3d-afae-18da1ab92191 LocationServices 24.09.2018 11:32:48 6172 (0x181C)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:48 6820 (0x1AA4)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:49 6820 (0x1AA4)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:49 4144 (0x1030)
    Created and Sent Location Request '{BADD25DA-598B-4C17-A372-C14AA8D7F68F}' for package 81efc5cc-ce6c-4089-a5ad-f2badfcbb8e0 LocationServices 24.09.2018 11:32:49 4144 (0x1030)
    ----------------------

    Thought something was wrong with data on DPs, so tried to delete/redistribute content of Update deployment packages, but no help. I have also read, that client peer cache can cause problems, when content is being looked from computers, which are switched off. Client peer cache isn't activated though, so this isn't the case.

    EDIT:
    When I kill TSInstallSWUpdate.exe process, I can continue.. and after OSD finishes, later via Software Center I can install the same updates.

    smsts.log (patiently waiting)
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:19:09.972-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:20:09.973-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:21:09.973-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:22:09.974-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:23:09.974-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:24:09.975-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">



    • Edited by Riho K Monday, September 24, 2018 1:39 PM
    Monday, September 24, 2018 9:10 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Riho K,

    I have no more ideas from the above log fragments.
    Some even downloads nicely to ccm cache folder, but at some point it just gets stuck at "Downloading x of y updates"
    Whether all the updates that will be installed have been successfully distributed to the distribution point.
    Or we could review the
    UpdateDeployment.log, UpdatesHandler.log, WUAHandler.log, and WindowsUpdate.log
    for more relevant information.

    Timeout scan is now configurable
    We added a new task sequence variable to allow a configurable timeout for scan. Variable name is SMSTSSoftwareUpdateScanTimeout, default is 30 minutes. Value is set in seconds so an hour is 60×60=3600

    New Option for full scan 
    There’s a new checkbox added to the Install Updates step – ‘Evaluate software updates from cached scan results’
    If the checkbox is on we use cached results, if the checkbox is off we do a full scan
    Task Sequences that are upgraded will have this option checked on – this is parity with the existing behavior.

    Best regards,

    Yuxiang

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Edited by Yuxiang Shi Wednesday, September 26, 2018 7:08 AM
    Wednesday, September 26, 2018 6:57 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello Yuxiang,

    Thanks for answer!

    Although this feature is from 1606, "Evaluate software updates from cached scan results" was checked indeed, I will deploy while it is unchecked to see, if it solves my problem.


    • Edited by Riho K Wednesday, September 26, 2018 10:10 AM
    Wednesday, September 26, 2018 10:06 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello Yuxiang,

    Thanks for answer!

    Although this feature is from 1606, "Evaluate software updates from cached scan results" was checked indeed, I will deploy while it is unchecked to see, if it solves my problem.


    Nope, it didn't. Right now as workaround I have disabled Software Updates and it is installing updates after OS has been deployed.

    I think that rules out also problems with DP-s, as if there would be problem with content, it would be broken no matter whether I try to install updates during OSD or via Software Center.

    Wednesday, September 26, 2018 12:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I ran into this very same issue after the upgrade which we did maybe 2 weeks ago. It's hit and miss on TS deployments so far. Once this happens we have to do a hard shutdown on the system. The TS progress of the device is stuck in that status on the deployment and the "_SMSTasksequence" folder and possibly an EFI folder left on the root of C: have to be manually removed.







    • Edited by MrRobot13 Wednesday, October 3, 2018 3:19 PM
    Wednesday, October 3, 2018 12:40 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Any more updates on this issue? I'm experiencing this same issue in 1806 when attempting to do a build and capture. We've applied the 1806 HotFix and it's still occurring. The task sequence will hang indefinitely and the SMSTS log fills with "Waiting for job status notification" when it's attempting to download and install updates of Office 2016. The build and capture is for Windows 10 1709 which has the September Cumulative update injected into it via offline servicing.

    I'm going to test a build and capture with 1803 to see if that makes a difference.

    Edit:

    I tested a build and capture with 1803, and the install updates step worked fine. This issue appears to be a bug between Windows 10 1709 and SCCM 1806.

    Thanks!!

    Dennis



    • Edited by dvolpe233 Tuesday, October 16, 2018 4:14 PM
    Tuesday, October 16, 2018 3:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I tested a build and capture with 1803, and the install updates step worked fine. This issue appears to be a bug between Windows 10 1709 and SCCM 1806.

    Thanks!!

    Dennis

    Isn't it wonderful that the latest version of Windows 10 we're implementing right now in my environment is 1709. I've been so hesitant to upgrade as we were running SCCM 1710 and upgraded to 1806 for the integrated 3rd party patching feature.

    It would be nice to gain something without breaking another. Is that too much to ask for these days? >_<


    • Edited by MrRobot13 Tuesday, October 16, 2018 10:28 PM
    Tuesday, October 16, 2018 10:27 PM
  • Question
    Sign in to vote
    2
    Sign in to vote

    Been doing some more testing here. If I use 1709 image, which has cumulative Update injected into it, it hangs during OSD Software updates trying to download Office and Skype for Business updates.

    But when I use clean image (10.0.16299.15), works fine - downloads updates and installs them without problems.



    • Edited by Riho K Wednesday, October 17, 2018 8:57 AM
    Wednesday, October 17, 2018 8:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Been doing some more testing here. If I use 1709 image, which has cumulative Update injected into it, it hangs during OSD Software updates trying to download Office and Skype for Business updates.

    But when I use clean image (10.0.16299.15), works fine - downloads updates and installs them without problems.

    Awesome! Thanks for sharing your findings!

    I was curious if the issue comes about after the September cumulative update of 1709 being injected or any cumulative would cause this issue with 1709 when attempting OSD/SoftwareUpdates with SCCM 1806. Testing this theory can be troublesome due to the issue not always showing its face 100% of the deployments.

    Wednesday, October 17, 2018 2:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I'm seeing similar issue at the customer site I'm currently working at:

    SCCM 1806 (not installed the 1806 Hotfix rollup yet). 

    Windows 10 1709 ADK (which is backwards compatible)

    Using HTTPs for all communication.

    Windows 10 1709 built and captured using MDT, September CU and Office updates installed as part of build and capture.

    Have tried offline servicing the October CU into the wim but this hasn't made any difference.

    Issue is intermittant and other content comes down ok to machines. 

    The DP seems fine.

    Friday, October 19, 2018 11:44 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We were having the same issue, OSD TS hanging at Software Updates for 60 min. In our case it ware relaled to Peer Caching. We disabled peer caching in the Client Settings and our problem was fixed. 

    You might take a look at the setting: Client Settings > Client Cache Settings, “Enable Configuration Manager client in full OS to share content”.

    Monday, October 22, 2018 2:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Are there more insights?

    We have the exact same issue in CB 1806 using a W10 1709 captured image and about 20% to 30% of our installations hang forever at downloading 1 of 18 updates (0% complete).

    When replacing the captured image with a W10 1709 original media image, the issue is for sure no longer there. Also when we use the captured image, but disable the (Symantec) antivirus client installation, the issue also is no longer there. Though this last workaround still needs more testing.

    Also when we use the captured image and it hangs at downloading 1 of 18 updates (0% complete), we do see sometimes some or all updates were successfully downloaded and even are applied, but the GUI progress indicator does not move and continues to hang at downloading 1 of 18 updates (0% complete).

    Finally, when we use the captured image and the OSD is forcefully failed, while in the full OS, all applicable W10 1709 updates are correctly scanned and installed.

    Any help to get our captured W10 1709 image working reliably with CB 1806 would be greatly appreciated!

    Friday, October 26, 2018 3:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Ours is SCCM 1802 and 1803 or 1709 W10 machines in environment inconsistently the machines are unable to execute the downloaded content of updates, no error reported in the Updates deployment log of the machines..,

    However when I check the windowsupdate.log there was an error related to the proxy, the data store .edb file has some metadata only downloaded not all and hence I felt its due to wsus unable provide the content.

    Kamala kannan.c| Please remember to click “Mark as Answer” or Vote as Helpful if its helpful for you. |Disclaimer: This posting is provided with no warranties and confers no rights

    • Proposed as answer by Ryan Dallas Tuesday, August 11, 2020 10:08 AM
    • Unproposed as answer by Ryan Dallas Tuesday, August 11, 2020 10:08 AM
    Sunday, October 28, 2018 1:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Been doing some more testing here. If I use 1709 image, which has cumulative Update injected into it, it hangs during OSD Software updates trying to download Office and Skype for Business updates.

    But when I use clean image (10.0.16299.15), works fine - downloads updates and installs them without problems.



    Same experience here, still no solution.
    Wednesday, November 21, 2018 9:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I tested a build and capture with 1803, and the install updates step worked fine. This issue appears to be a bug between Windows 10 1709 and SCCM 1806.

    Thanks!!

    Dennis

    Good to know, thank you Dennis. Unfortunately we are not able to just switch to another release than 1709. 

    There is one point that I don't get: In our case, the issue just exist during Build & Capture. The "normal" OSD-Tasksequence works fine (inclusive updates). The main difference between the Build & Capt and OSD is, that during OSD the machine is joined to the domain.

    EDIT: The issue now also exist in the "normal" OSD-Tasksequence...
    • Edited by -M4rt1n- Thursday, November 22, 2018 10:32 AM
    Wednesday, November 21, 2018 10:03 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have exactly the same problem during OS instalaltion and also when I pushing monthly updates.

    About 60% of my computers can't install updates or showing wrong information in Software Center. The strange thing is that many times In Software Center, updates stuck on downloading or waiting to install but in the logs, I see that everything has been installed without any problems. It's not related to a specific computer. One month I can install monthly updates without any problem but next month it's not working on the same computer or vice versa.  

    Fully patched  SCCM 1806 and Win10 1709. 

    Thursday, December 6, 2018 9:36 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Interesting... in our case it works in full OS via Software Center. Here, the issue just exist during tasksequence.

    I opened a case at Microsoft and they confirmed that this is a bug. As a workaround, you can use an old agent. I tried with 5.00.8634.1010 and it actually worked. The updates are installed successfully during tasksequence. Unfortunately, the task "Prepare OS" in the Build and Capture Tasksequence fails when using the old client.

    Will go on working on that with Microsoft...

    Thursday, December 6, 2018 12:24 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Can you be more specific ? A bug combination of CB 1806 and Win 1709 ? Could you possibly send me the case number ?

    I have quite a few issues with this but during full os, imo it started with the 1806 upgrade which I did a few weeks ago. Default OSD Build is 1803 since last summer so i can't comment on the OSD issues.

    ---

    If anyone sees this in full os, can you fire up wmi explorer and check 

    ROOT\ccm\ContentTransferManager:CCM_CTM_JobStateEx4

    I see jobs there with status RequestedLocations or DownloadingData. Usually the files are downloaded to the ccmcache but ctm doesn't continue.

    There is also a reddit discussion about this.


    Thursday, December 6, 2018 1:04 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Interesting... in our case it works in full OS via Software Center. Here, the issue just exist during tasksequence.

    I opened a case at Microsoft and they confirmed that this is a bug. As a workaround, you can use an old agent. I tried with 5.00.8634.1010 and it actually worked. The updates are installed successfully during tasksequence. Unfortunately, the task "Prepare OS" in the Build and Capture Tasksequence fails when using the old client.

    Will go on working on that with Microsoft...

    I'm actually preparing a new image with Windows 1809 but it will take few weeks if not moths to test and upgrade few hundredes clients so your workaround is much appreciated :-)

    Where did You get the old agent 5.00.8634.1010?


    Thursday, December 6, 2018 9:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Can you be more specific ? A bug combination of CB 1806 and Win 1709 ? Could you possibly send me the case number ?

    I have quite a few issues with this but during full os, imo it started with the 1806 upgrade which I did a few weeks ago. Default OSD Build is 1803 since last summer so i can't comment on the OSD issues.

    ---

    If anyone sees this in full os, can you fire up wmi explorer and check 

    ROOT\ccm\ContentTransferManager:CCM_CTM_JobStateEx4

    I see jobs there with status RequestedLocations or DownloadingData. Usually the files are downloaded to the ccmcache but ctm doesn't continue.

    There is also a reddit discussion about this.


    I have exactly the same problem as in your reddit link and described here.
    Friday, December 7, 2018 8:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have exactly the same problem as in your reddit link and described here.

    That makes me feel a little less alone but still doomed. 1709 is my

    Largest install base with 1500 clients. This will kill me if it persists.

    Did you check the wmi classes I posted above ?

    Friday, December 7, 2018 10:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    >> Can you be more specific ?
    >> A bug combination of CB 1806 and Win 1709 ?

    Yes... at least, this is what I understood.


    Saturday, December 8, 2018 3:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Where did You get the old agent 5.00.8634.1010?

    "Stole" it from a client that wasn't updated yet (C:\Windows\ccmsetup)
    Saturday, December 8, 2018 3:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    >> Can you be more specific ?
    >> A bug combination of CB 1806 and Win 1709 ?

    Yes... at least, this is what I understood.



    Could you give me your case number ?

    Tuesday, December 11, 2018 8:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We are experiencing the same issue.  SCCM version 1806, deploying Win 10 1709 that has updates applied.  During OSD task sequences, it will hang at "Downloading X of Y updates".  As a work around, we followed Riho K's advice, uploaded a new 1709 image with no updates applied, and our task sequences are no longer getting stuck downloading updates.  We will use this work around until Microsoft acknowledges and addresses the issue.
    • Proposed as answer by saragmartin Tuesday, December 11, 2018 8:34 PM
    • Edited by saragmartin Tuesday, December 11, 2018 8:34 PM
    Tuesday, December 11, 2018 8:34 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    We have the same problem (SCCM 1806, W10 1709). As a workaround we use the 1802 agent which can be extracted from the full source from VLSC.

    MS Case Number 118112819392658

    We know that there are cases from other customers too.

    We also have issues with the regular patching process via SCCM. Clients are either not downloading the updates (stuck at 0%) or do update but there is no refresh in Software Center.


    • Edited by chchris Thursday, December 13, 2018 11:23 AM
    Thursday, December 13, 2018 11:22 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We also have issues with the regular patching process via SCCM. Clients are either not downloading the updates (stuck at 0%) or do update but there is no refresh in Software Center.

    Essentially the same for me. My Case number is 118113019402101

    Friday, December 14, 2018 11:01 AM
  • Question
    Sign in to vote
    0
    Sign in to vote


    Could you give me your case number ?

    118112319376678
    Friday, December 14, 2018 11:34 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

              did any of you have any luck with solving your case?

    I am running SCCM 1810 with Windows 10 1809 and having similar issues.

    Thursday, January 3, 2019 3:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

              did any of you have any luck with solving your case?

    I am running SCCM 1810 with Windows 10 1809 and having similar issues.

    I've found a solution on Twitter for software updates during OSD.  You have to re-deploy your updates again.

    https://twitter.com/SimonDettling/status/1073131695602327552

    https://t1m.nl/2018/12/13/step-install-updates-timeout-during-osd/

     
    Thursday, January 3, 2019 11:48 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

              did any of you have any luck with solving your case?

    I am running SCCM 1810 with Windows 10 1809 and having similar issues.


    We are using the old Agent (1804). This way, the updates are installed successfully. I was hoping that the bug will be fixed with 1810, but what I understand from your post, it isn't... :-(
    Thursday, January 3, 2019 12:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    ive tried that - no success for me.
    Thursday, January 3, 2019 10:19 PM
  • Question
    Sign in to vote
    2
    Sign in to vote

    yer, i saw those posts - i havent gone back an agent version yet... i figure with an issue this big, MS must be working on solving it.

    (after having written that, i realise how stupid my comment is.... MS dont really care about fixing bugs... especially for on prem software)

    Thursday, January 3, 2019 10:22 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Microsoft just informed us that it won't be fixed in 1810. They plan to fix it in 1902. 
    Tuesday, January 15, 2019 3:44 PM
  • Question
    Sign in to vote
    2
    Sign in to vote
    I believe I am having the same problem. CASE 119012519593571 . CM1806 and WIN10 1709  We've updated our reference image in December and since we've noticed SC Statuses all messed up post image. Now, Updates start installing, appear to get stuck (IF you are looking at SC). Any Package/Application that comes down in the meantime get stuck "Waiting For Content", however, the content seems to fully come down but the tmp folders are not released. If you look at the UpdatesHandler.log the updates actually succeed in the expected time but there is a "Failed to notify job manager of the update progress. Error = 0x87d00275". Eventually the the job is canceled and Software Center status are resolved for the updates. Pending Apps/Packages do not always install after this.   Currently working with MS and running through some troubleshooting steps. For anyone who is still following, what antivirus are you all using? We use Symantec.  
    Friday, January 25, 2019 7:39 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I wish anybody luck with their cases, mine has be absolutely useless. Agent suggestions boiled down to downgrade the client, which is a challenge when you can't be sure the files will be staged properly, or upgrade windows to a newer build which is even worse.

    Anyhow, I have performed about 400 agent downgrades and can confirm the issue does happen with a lower agent version. I'm currently deploying 5.00.8634.1813.

    I think I finally have all the bits in place to perform a large scale downgrade on intranet / internet connected devices, my workflow:

    • Use a Task Sequence to download the agent bits and stage them to a directory
    • I let the TS bits download to _SMSTASKSEQUENCE instead of ccmcache, hoping this will somehow bypass the contenttransfermanager issue, initial tests look promising
    • Use a scheduled Task to uninstall / reinstall the client

    my ccmsetup command line arguments:

    • Source:"pathtofiles"
    • SMSMP=https://blabla (don't use /MP because this will reach out to a dp and ignore the /source option)
    • CCMHOSTNAME (I use ibcm but this should work for cmg as well)
    • SMSSITECODE=FOO (if the client is internet connected you need to specify the sitecode to assign)

    In one of my last phone calls with the MS Agent he confirmed that there is an issue logged with the product group, but he wasn't able to tell me the exact scope (TS download issues / post ts, like me) etc.

    Since there is no way for a mortal to obtain the status of an issue logged with the product group this is useless as well.

    Lessons learned:

    • Get you lab up
    • Get yourself good knowledge of the ccmsetup parameters
    • Get your powershell skills up
    • Hold up on that automatic client upgrade after a site upgrade
    • Be prepared to dig yourself out of the hole, because PSS won't
    Monday, January 28, 2019 8:20 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    It sounds exaclty like my problem. I dont think it's releated to any specific AV. We are using McAfee but I've ran some tests with Windows Defender and got same results.
    Monday, January 28, 2019 1:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Forgot to mention i run defender as well.
    Monday, January 28, 2019 1:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Reviewing

    (https://support.microsoft.com/en-in/help/327453/recommended-antivirus-exclusions-for-configuration-manager-2012-and-cu)  .  We were missing CCM\ServiceData in our exclusions. Retesting with this in place.  Friday, I ran through a successful test with NO AV.  If it is AV,  something must have changed with the way the client interacts with Post Sept 1709 CU OS.  I've already looked at Wireshark with the conversation between the client/MP/DP  .  The conversation resets on the client but there is nothing on the MP or DP side to signify that there is problem with the communication between server/client.  I'm convinced that the issue resides on the client side as suggested. I've upgraded to 1806 prior to the problem ever existing.   It's an understatement when I say I am not readily prepared to downgrade 25k clients to the previous version.

    Monday, January 28, 2019 6:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Reviewing

    We were missing CCM\ServiceData in our exclusions. Retesting with this in place. 

    I have that excluded since last year or something. I don't think this is av related.

    It's an understatement when I say I am not readily prepared to downgrade 25k clients to the previous version.

    Your client count is whole different beast.

    Despite having all the bits in place I'm also reluctant to pull the trigger. I might continue downgrading affected clients a bit longer.

    Tuesday, January 29, 2019 8:52 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This problem is reported as a bug as of last week. I have an open case with Microsoft since the release of SCCM 1806. This issue still persist in SCCM 1810. The problem is with the SCCM Agent. The problem is the SCCM Client and the WSUS Agent doesn't sync properly.

    I was told it's a bug and that it will be fixed in 1902.

    You can refer any open case to: 119010219502736

    For your information, when a case is categorise as a bug, you don't get billed for it.

    Tuesday, January 29, 2019 4:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    This issue is still being investigated internally at Microsoft. There is NOT a pending fix for 1902. Until we know and understand root cause, we cannot produce a fix. If we discover root cause and create a fix before 1902 is released, we will do our best in getting the fix into 1902. Until then we do not have a timeline for a fix.
    Tuesday, January 29, 2019 6:05 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    And what exactly is being investigated ?

    • The download stuck in TS issue
    • and/or the post TS issues (Softwarecenter, Contenttransfermanager)
    Wednesday, January 30, 2019 6:25 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yea,  I have more confirmed issues from my techs. I have witnessed many different scenarios but I was able to replicate one fairly easy by forcing updates down via SCCM, waiting for them to start installing, while installing assign an application then refresh machine policies/appeval .  After updating our AV I have run a couple of successful tests but the issue appears to still be present.
    Wednesday, January 30, 2019 4:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    As the title says, TS gets stuck at Software updates task.

    Seems to be some kind of communication issue, but I haven't figured out solution and running out ideas.

    It finds correctly, what updates are required, some even downloads nicely to ccm cache folder, but at some point it just gets stuck at "Downloading x of y updates".

    In ContentTransferManager.log and in LocationServices.log I see that the location requests go out nicely. The client also receives answers until some point, then it stops. Can't see any errors anywhere.

    Example from logs, where it doesn't receive any response for location requests, won't copy full logs here.

    Contentransfermanager.log :
    --------------------------------
    Starting CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C}. ContentTransferManager 24.09.2018 11:32:48 6820 (0x1AA4)
    Created CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C} for user S-1-5-18 ContentTransferManager 24.09.2018 11:32:48 6820 (0x1AA4)
    CTM job {980E40A9-C2A7-4A4A-B0EC-579967A91C2C} entered phase CCM_DOWNLOADSTATUS_WAITING_CONTENTLOCATIONS ContentTransferManager 24.09.2018 11:32:48 6172 (0x181C)
    Queued location request '{A37615FA-B928-4578-B926-1E4DDE57BA15}' for CTM job '{980E40A9-C2A7-4A4A-B0EC-579967A91C2C}'. ContentTransferManager 24.09.2018 11:32:48 6172 (0x181C)
    Starting CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683}. ContentTransferManager 24.09.2018 11:32:49 6820 (0x1AA4)
    Created CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683} for user S-1-5-18 ContentTransferManager 24.09.2018 11:32:49 6820 (0x1AA4)
    CTM job {A3AA13F4-B1D7-45DE-B563-C8BA17E27683} entered phase CCM_DOWNLOADSTATUS_WAITING_CONTENTLOCATIONS ContentTransferManager 24.09.2018 11:32:49 4144 (0x1030)
    Queued location request '{BADD25DA-598B-4C17-A372-C14AA8D7F68F}' for CTM job '{A3AA13F4-B1D7-45DE-B563-C8BA17E27683}'. ContentTransferManager 24.09.2018 11:32:49 4144 (0x1030)
    ---------------------

    LocationServices.log :
    --------------------
    Created and Sent Location Request '{A37615FA-B928-4578-B926-1E4DDE57BA15}' for package 27eeda63-dfc2-4c3d-afae-18da1ab92191 LocationServices 24.09.2018 11:32:48 6172 (0x181C)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:48 6820 (0x1AA4)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:49 6820 (0x1AA4)
    Current AD site of machine is MY AD SITE LocationServices 24.09.2018 11:32:49 4144 (0x1030)
    Created and Sent Location Request '{BADD25DA-598B-4C17-A372-C14AA8D7F68F}' for package 81efc5cc-ce6c-4089-a5ad-f2badfcbb8e0 LocationServices 24.09.2018 11:32:49 4144 (0x1030)
    ----------------------

    Thought something was wrong with data on DPs, so tried to delete/redistribute content of Update deployment packages, but no help. I have also read, that client peer cache can cause problems, when content is being looked from computers, which are switched off. Client peer cache isn't activated though, so this isn't the case.

    EDIT:
    When I kill TSInstallSWUpdate.exe process, I can continue.. and after OSD finishes, later via Software Center I can install the same updates.

    smsts.log (patiently waiting)
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:19:09.972-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:20:09.973-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:21:09.973-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:22:09.974-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:23:09.974-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">
    <![LOG[Waiting for job status notification ...]LOG]!><time="12:24:09.975-180" date="09-24-2018" component="InstallSWUpdate" context="" type="1" thread="6848" file="installswupdate.cpp:1127">



    When you mentioned that Peer cache wasn't activated, how did you check?   I noticed that by default, under boundary group options, "Allow peer downloads in this boundary group" is checked. has anyone unchecked this?

    Wednesday, January 30, 2019 5:43 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    When you mentioned that Peer cache wasn't activated, how did you check?   I noticed that by default, under boundary group options, "Allow peer downloads in this boundary group" is checked. has anyone unchecked this?
    This doesn't do anything unless you have peer cache configured in your client settings.
    Wednesday, January 30, 2019 9:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all, just to add to this.

    At one client - windows 10 1809 and SCCM 18010 with hotfiix - updates are working fine in the TS

    At another client - windows 10 1809 and SCCM 18010 with hotfiix - updates fail within the TS, but work in the full OS

    At yet another client, Windows 2012 R2 and Windows server 2016 patches, SCCM 1806.

    If i build 100 servers, it will work on approx 60% of them every time, but they are always different servers. (going through a testing scenario so doing rebuilds very regularly)

    I've tried to compare logs from all 3 sites, but where it doesn't work, nothing actually "goes wrong" as such, smsts.log just says "waiting for windows update agent" - and it apparently never gets a response.

    at the site where its intermittent, same thing between the ones that work and don't work - the smsts.log stops getting information back, even though the other logs (Updateshandler, deployment etc etc) show the required updates being listed.

    Thats at least what im seeing.... other guys in my team are seeing the same at their clients. We've spent alot of time trying to resolve this now, trying different things - but havent found anything yet.... i think its fairly safe to say its a big - and a massive one at that.


    Saturday, February 2, 2019 12:49 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Is there an official Microsoft page that details the bug?
    Monday, February 4, 2019 7:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Is there a page tracking or explaining the bug? We want to open a case, and would like to reference it.
    Monday, February 4, 2019 7:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I don't know any official page but you can reference to the existing cases:
    119012519593571
    118112819392658
    118113019402101
    119010219502736
    118112319376678
    Wednesday, February 6, 2019 2:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We were informed that our issue 118112819392658 will be fixed in 1902, maybe backported to 1810. We were also told that there are multiple issues, not all the cases listed here have the same root cause.
    Thursday, February 14, 2019 8:08 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks chris, looking forward to it :-)
    Thursday, February 14, 2019 8:32 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Was informed yesterday as well.
    Thursday, February 14, 2019 8:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    thanks for the update chris - i sure hope it is fixed - is causing massive hassle for the current project im working on.

    Bring on 1902.

    Thursday, February 14, 2019 11:28 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Update which fixes this issue in SCCM 1810 was released this weekend: https://support.microsoft.com/en-us/help/4490575/update-installations-stop-responding-in-configuration-manager-1810
    • Proposed as answer by Lexi28 Monday, February 25, 2019 9:18 AM
    • Unproposed as answer by Lexi28 Monday, February 25, 2019 9:18 AM
    Monday, February 25, 2019 9:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Update which fixes this issue in SCCM 1810 was released this weekend: https://support.microsoft.com/en-us/help/4490575/update-installations-stop-responding-in-configuration-manager-1810
    Good news. Now I have to decide if I want to upgrade to 1810 or wait for 1902. The later one should be released very soon.

    • Edited by binary-lab Tuesday, February 26, 2019 1:04 PM typo
    Monday, February 25, 2019 6:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    So is anyone going to upgrade from 1806 to 1810 ? It tripple upgrade time, base release + 2 hotfixes. With a third hotfix for another issue.

    https://www.prajwaldesai.com/sccm-1810-hotfix-kb4490575/

    Monday, March 4, 2019 1:47 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    We are already on 1810 and adding the OSD hotfix to our PROD environment tonight. We should know tomorrow if it has resolved the issue.

    Daniel Ratliff | http://www.PotentEngineer.com | @PotentEngineer

    Monday, March 4, 2019 1:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We are already on 1810 and adding the OSD hotfix to our PROD environment tonight. We should know tomorrow if it has resolved the issue.

    Daniel Ratliff | http://www.PotentEngineer.com | @PotentEngineer


    Thanks for the offer. Are you going to deploy the new client that fast or are you part of the osd crowd ?
    Monday, March 4, 2019 2:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Just OSD for me. We never saw this issue on machines already deployed. We will install the hotfix and update the SCCM client in OSD as well.

    Daniel Ratliff | http://www.PotentEngineer.com | @PotentEngineer

    Monday, March 4, 2019 3:05 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    So i now have 1810 + all hotfixes on at 7 client sites.

    Update the boot wims and client package.

    All the sites that previously were not working are still not working.

    Some of the sites that were working are also now not working (for software updates in OSD)

    So my experience so far has been that the patches make it worse - not better!

    Monday, March 4, 2019 8:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    So i now have 1810 + all hotfixes on at 7 client sites.

    Update the boot wims and client package.

    All the sites that previously were not working are still not working.

    Some of the sites that were working are also now not working (for software updates in OSD)

    So my experience so far has been that the patches make it worse - not better!

    Wow, great stuff. Makes me really keen to upgrade. Does any client of yours experience the problem with regular patching ?

    Looks like you are not alone:

    https://reddit.com/r/SCCM/comments/ax7ufl/sccm_1810_osd_install_software_updates_task/

    Monday, March 4, 2019 9:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Our upgrade last night was a success. We added the hotfix to our client install in OSD and all of our builds today are now patching successfully. We did not have to redeploy the SUG or make any other changes. 

    Daniel Ratliff | http://www.PotentEngineer.com | @PotentEngineer

    Tuesday, March 5, 2019 7:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Oh, i haven't even watched this topic any more after i found the workaround.

    Great to see, that it is getting attention from the developers. Gonna upgrade/patch our environment also.

    Tuesday, March 5, 2019 7:44 PM