none
WSUS - 2019 All Computers Server Node Crash RRS feed

  • Question

  • I wanted to try out a test 2019 WSUS server. Everything seemed to go smoothly, however when I go look at All Computers, I get a system node crash.

    I looked at the possibility of it being the same as the bad BIOS name, but I do not seem to see any errors.

    The error is as follows:

    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists, 
    
    Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.
    
    
    System.InvalidCastException -- Unable to cast object of type 'System.Guid' to type 'System.String'.
    
    Source
    Microsoft.UpdateServices.BaseApi
    
    Stack Trace:
       at Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPSearchComputers(String computerTargetScopeXml)
       at Microsoft.UpdateServices.Internal.BaseApi.ComputerTarget.SearchComputerTargets(ComputerTargetScope searchScope, UpdateServer updateServer)
       at Microsoft.UpdateServices.UI.AdminApiAccess.ComputerTargetManager.GetComputerTargets(ComputerTargetScope searchScope)
       at Microsoft.UpdateServices.UI.AdminApiAccess.BulkComputerPropertiesCache.GetAndCacheComputers(ExtendedUpdateScope updateScope, ComputerTargetScope computerTargetScope)
       at Microsoft.UpdateServices.UI.SnapIn.Pages.ComputersListPage.GetListRows()

    Has anyone come across this error before?

    Thanks.

    Tuesday, November 27, 2018 1:19 PM

All replies

  • Hello, 
     
    Have you tried remove the wsus file and re-open the console? The file is under C:\Users\Administrator\AppData\Roaming\Microsoft\MMC. Change the administrator in the path to your logging in account.
     
    If issue persists, we need to find out which client cause the issue. How many clients are there in the WSUS? Try navigate to each node under all computers to find out where it is.
     
    Hope my answer could help you.
     
    Best Regards,
    Ray

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 29, 2018 8:36 AM
  • Hi Guys,

    did you find a solution for this problem? Having the exact same behavior. Our configuration is 2 WSUS Servers, 1 streaming down from Microsoft, the other one on another site streaming down from the 1st one.

    I already tried deleting the C:\Users\Administrator\AppData\Roaming\Microsoft\MMC\wsus file, no effect. From further researches I came across with the problem that another one had. Based on this information I deleted all the computers from the WID manually, after that it worked first. After synchronizing our 2nd server, where it obviously also syncs the computers from this site, it crashes again. And it also only crashes when I try to open a computer node which is from this side. So it has to do with an entry in the database.

    Any ideas how to identify that one?

    Thanks and regards

    Friday, December 7, 2018 12:45 PM
  • Check out Sterling T's response on the thread below. It's about 2/3rds down the page.

    https://social.technet.microsoft.com/Forums/ie/en-US/90dc15d3-c498-42b8-b36a-bd29be35cf99/wsus-console-unexpected-error-when-choosing-all-computers-folder?forum=winserverwsus


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Tuesday, December 11, 2018 5:00 PM
  • I have the same issue I have upgraded the upstream server from 2016 to 2019 and 4 of our 5 downstreams to 2019 as well. The downstreams are fine they will let me view the all computers, no problem.

    I run Adams WSUS script daily which works fine (keeps WSUS like a fine tuned engine btw, but you already know that if you use it). I did a -dirtydbcheck on the upstream and it confirmed it was and ran the processes and it ended with its manual sync which pulled through a load of windows feature updates around 255(we have a few languages and versions of windows) and expired 64GB of old feature updates. Unfortunately this did not fix the issue.

    I've followed Sterling T as suggested but his fix is when there is a specific bad symbol which this error does not specify I've looked through the data on the table Sterling T points you too and cannot see anything else out of the ordinary.

    Everything else works fine, sync, update approval/decline, just viewing All Computers or below does not, however viewing just Computers does work?

    Any other ideas of what to look for in the DB for dodgy computer entries?


    • Edited by BenatDSI Friday, December 14, 2018 12:18 PM adding info about updates
    Friday, December 14, 2018 12:10 PM
  •  I did a -dirtydbcheck on the upstream and it confirmed it was and ran the processes and it ended with its manual sync which pulled through a load of windows feature updates around 255(we have a few languages and versions of windows) and expired 64GB of old feature updates. Unfortunately this did not fix the issue.

    https://www.ajtek.ca/wam/release-notes/

    DirtyDatabaseCheck is currently deprecated (it may come back in a future version...)



    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Saturday, December 15, 2018 1:20 AM
  • Hi,

    thanks for the hint. Unfortunately this didn't help.

    Regards

    Chris

    Monday, December 17, 2018 9:26 AM
  • Hi,

    thank you for your reply. I cleaned up a lot now. Deleted old computers and a couple of updates (65GB).

    Again removed all the computers and let everyone resync with the WSUS.

    The whole procedure without any changes to the issue.

    The problem only occours when I open a computer node from the replica server on the mainserver and the all computers view on the main server.

    Regards

    Chris

    Monday, December 17, 2018 9:30 AM
  • I'm confident that it is something to do with a bad BIOS name/version or something of the sort (Sterling's findings). Your best bet to try to troubleshoot would be to split half of the computers off to a different group and try loading both groups. If 1 works and the other doesn't, you then know that the problem system is in there. Half them again, and do it again until you come down to the problem system. You already know it happens on the replica server, so you've already eliminated systems on your upstream.

    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Monday, December 17, 2018 1:09 PM
  • Ok obviously I didn't add information that it works when I open the WSUS console on the replica server. Sorry, just read my own answer now and this was not pointed our clearly.
    Monday, December 17, 2018 5:22 PM
  • Try on BOTH WSUS servers:

    * Make the following "Advanced Settings" for WSUS Application Pool in IIS:
        - Queue Length: 25000 from 1000
        - Limit Interval (minutes): 15 from 5
        - "Service Unavailable" Response: TcpLevel from HttpLevel
    * (Stop IIS first) Edit the web.config ( C:\Program Files\Update Services\WebServices\ClientWebService\web.config ) for WSUS:
        - Replace <httpRuntime maxRequestLength="4096" /> with <httpRuntime maxRequestLength="204800" executionTimeout="7200"/>
    * Adjust the private memory limit.
        - If you have WSUS Automated Maintenance (WAM), from the WAM Shell run:
            .\Clean-WSUS.ps1 -SetApplicationPoolMemory 4096
        - If you don't have WAM, edit the pool's configuration directly to change it to 4194304 (4GB)

    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Monday, December 17, 2018 5:36 PM
  • I have tried this change to the upstream in my environment (not on any downstreams as they work fine when viewing the 'All Computers') and it didn't make a difference. I'm wondering if it's something in the Windows Server 2019 side as the error states it cannot convert GUID's to Strings. the only place I can see GUID's in the DB is on the dbo.tbComputerTarget table.
    • Edited by BenatDSI Tuesday, December 18, 2018 4:58 PM
    Tuesday, December 18, 2018 4:58 PM
  • We have this exact same issues on a 2019 server with a downstream 2016 server.  Any computers that are synced from the 2016 server to the 2019 server make WSUS crash with the error:

    System.InvalidCastException -- Unable to cast object of type 'System.Guid' to type 'System.String'.

    I believe this is the same issue: https://social.technet.microsoft.com/Forums/en-US/693ac0f5-83c1-4629-b5ea-0dcbea01da1d/wsus-2019-downstreamserver-bug-downstream-computers-not-available-on-upstream?forum=winserverwsus

    Wednesday, December 19, 2018 8:46 AM
  • I have the same issue, is there a hotfix or something else?
    Wednesday, January 16, 2019 7:23 AM
  • After some Research, i modified an entry of the table tbComputerTarget.

    I removed the ParentServerTargetID value, i set it to NULL. If i do that, the error disappears .. has someone any ideas?

    Wednesday, January 16, 2019 1:53 PM
  • The same Question from me. Is there already a fix for that?
    Wednesday, February 13, 2019 8:04 PM
  • Of course there is no fix.  Server 2019 is a joke and Microsoft don't seem to care about fixing bugs anymore.
    Thursday, February 14, 2019 7:54 AM
  • I have updated my final downstream server to 2019 and still get the same error when viewing any computers on the upstream. I can approve updates fine. Just cant do anything in the computer section.
    • Edited by BenatDSI Thursday, February 14, 2019 11:04 AM
    Thursday, February 14, 2019 11:04 AM
  • Same here!

    There is another entry because of the same problem here: https://social.technet.microsoft.com/Forums/de-DE/693ac0f5-83c1-4629-b5ea-0dcbea01da1d/wsus-2019-downstreamserver-bug-downstream-computers-not-available-on-upstream?forum=winserverwsus

    is there no solution or a response from microsoft?

    Tuesday, February 26, 2019 3:39 PM
  • There is no solution or response from Microsoft about this.

    I think the only way we will be able to get this resolved is by raising a support ticket with Microsoft.

    This will cost money, but should be refunded once they acknowledge that there is a bug.

    I'm not able to raise this with Microsoft myself.

    There are currently 2 other posts about this issue on these forums:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/20a9214a-7ea1-44e9-aa44-5450971c523f/server-2019-support-and-requirements?forum=winserverwsus

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/693ac0f5-83c1-4629-b5ea-0dcbea01da1d/wsus-2019-downstreamserver-bug-downstream-computers-not-available-on-upstream?forum=winserverwsus

    Wednesday, February 27, 2019 10:39 AM
  • I opened a ticket with Microsoft on Monday with this exact issue. I will update everyone once they determine the issue. The tech was digging into the database for about an hour then said she needed to do some testing and would need to get back to me. More to come.
    Wednesday, February 27, 2019 3:24 PM
  • Its terrible how poorly WSUS performs.

    I treat WSUS servers as totally disposable.  Gen them up, make policy and approve updates

    There is no amount of time or money I'd be willing to spend on fixing something related to a WSUS server

    Friday, March 1, 2019 6:51 AM
  • Hey everyone, Microsoft resolved the issue today. I'm no SQL guy so you'll need to excuse my ignorance... but here goes... Before I get started though, I run Server 2019 with WSUS on a SQL 2017 Express instance. All clients were connected to 08 R2 boxes but I started having problems so I just built new servers. Then shortly after turning on the new GPO's to point everything to new servers my upstream server would crash with "Reset Server Node" anytime I would try to open the main computers group or any computer group from my downstream servers. So running reports was impossible.

    Annnd, the fix...

    Within the table tbComputerTarget there is a column labeled ParentServerTargetID - Everything in that column should be NULL. In my case, about 150 machines had either a 186 or 176 value. She said it's a bug from the recent WSUS uplift I performed. When the clients checked into the new server they received some invalid values. 

    Here are the commands she ran to fix it within SQL managment studio.

    Select * from tbComputerTarget

    ^Execute that.

    Then type and execute this...

    update tbComputerTarget set ParentServerTargetID = NULL where ParentServerTargetID = 186

    Then obliviously if there is a different value such as 176 just replace 186 with 176 or whatever your numerical value is.

    I hope this helps.

    • Proposed as answer by Dport76 Monday, March 4, 2019 6:38 PM
    • Unproposed as answer by Dport76 Tuesday, March 5, 2019 1:17 PM
    Monday, March 4, 2019 6:38 PM
  • OK I have tried this on my upstream server and it worked yesterday, I've come back to it today and the problem has reoccurred and the column I nulled has values back in it. Not sure how, maybe the overnight syncs from the downstreams have put values back in?

    Little bit more tweaking required.


    Ben Armitage

    Tuesday, March 5, 2019 12:32 PM
  • This "workaround" seems to be only provisoric. I hope MS hasn't reclaimed that as the final fix. I suggest that we must wait for it.
    Tuesday, March 5, 2019 1:00 PM
  • damned, just checked mine as well and the problem is back. 

    I will reach back out to Microsoft and update you all when I know more! 

    Tuesday, March 5, 2019 1:17 PM
  • I spoke with Microsoft again yesterday. They have no idea how to fix it and are supposed to reach back out once they know.
    Wednesday, March 6, 2019 1:01 PM
  • We also have this issue on windows server 2019 WSUS. Many parts of the WSUS console now give errors and it's become unusable. Please MS bring out fix for this asap.
    Thursday, March 7, 2019 8:27 AM
  • I just followed up with Microsoft this morning - still no solution. Ill update when I know.
    Friday, March 8, 2019 2:02 PM
  • Hello all together,

    we have exactly the same issue. 

    We installed WSUS on a clean Windows Server 2019 Installation, everything has worked fine until we added a downstream WSUS Server, which is also running Windows Server 2019.

    The mentioned workaround:

    update tbComputerTarget set ParentServerTargetID = NULL where ParentServerTargetID = xxx

    works but it isn't an acceptable solution for us because it helps only temporaely. 

    I opened a Microsoft case today, hope this helps that they fix this bug. 

    Best Regards

    Michael

    Tuesday, March 12, 2019 10:49 AM
  • Just a quick note to everyone - I heard from Microsoft yesterday, and they still have no solution. 
    Wednesday, March 13, 2019 3:42 PM
  • I am running into the same issue. However, this problem only arises when I click on 'Unassigned Computers' and not on the 'All Computers' option.

    It doesn't matter if I try to restart the Application Pool in IIS or change any set the Private Memory Limit to '0' (Unlimited), nothing works. This is an actual break. Please address this issue in the next round of Windows Updates. It's March 2019 and the problem is still occurring.

    Thursday, March 14, 2019 6:20 PM
  • Also seeing this issue in WSUS after upgrade from Server 2016 to Server 2019.
    Thursday, March 21, 2019 12:44 AM
  • I heard from Microsoft a few days ago. They are acknowledging that this is a bug. Here was the response from the tech.

    "I was just calling in to give you an update about this issue, that this issue has been identified as a known bug on OS level.

     

    It will be the issue with WSUS server on Server 2016 and mostly on Server 2019 machines. As of now, that is the only workaround we have to manually change the value of ParentServerTargetID to Null in the DB.

     

    I will give you an update about the next workaround as soon as I have an update on it.

     

    Thank you for your patience and cooperation."

    I will update this thread once they tell me a solution.


    • Edited by Dport76 Monday, April 1, 2019 2:10 PM
    Monday, April 1, 2019 2:09 PM
  • I also have an MS case open about this issue. I get the same response. They're working on it.
    Tuesday, April 2, 2019 3:55 PM
  • Hello all together,

    we also got the answer from Microsoft that we have to wait for an update.
    Under Server 2016 we didn't had this problem at all, only seen on Windows Server 2019!

    A bit better workaround is to create a sql script (text file .sql).

    update tbComputerTarget set ParentServerTargetID = NULL where ParentServerTargetID is NOT NULL

    And create a batch script (text file .sql).

    sqlcmd -S <connection to the WSUS db server> -d <name of WSUS db> -i <path to the sql script>

    i.e.

    sqlcmd -S localhost\WSUS -d SUSDB -i C:\Scripts\WSUS.sql

    The batch (.cmd) script can be executed every few minutes by a scheduled task.

    Best Regards

    Michael

    Remember this is only a workaround, without any warranty use it at your own risk.


    • Edited by Michael EC Wednesday, April 3, 2019 8:12 AM
    • Proposed as answer by MAPrice Monday, May 6, 2019 8:42 PM
    Wednesday, April 3, 2019 8:08 AM
  • Any update to this? I'm now experiencing same situation, complicated that we run WSUS on Server core, so SSMS connectivity is a bit of a problem. But, thanks to all to contributed - I'm at least running on the workaround. 

    • Edited by MAPrice Monday, May 6, 2019 8:42 PM
    Monday, May 6, 2019 8:18 PM
  • I have the same issue. Gets really old when I have to manipulate the database if I want to work with WSUS every day.
    Friday, May 10, 2019 3:58 PM
  • I hope they fix this soon….
    Monday, May 27, 2019 3:05 PM
  • Any update on this?

    Server 2019. Using WSUS. Happens right after setting up a downstream server. Everything synchs and looks great. Then you get the error when viewing Computers. Goes back to normal when you delete the downstream server.

    Wednesday, June 26, 2019 9:02 PM
  • Same, added 2019 server as main WSUS and downstream is 2016. Opening the computer list crashes and have to reset the node. We've removed the downstream server but this will cause our network to slow down come large update times. Hopefully MS fixes very soon, very frustrating.
    Tuesday, July 2, 2019 1:42 PM
  • Any news about?

    Somebody who know when Microsoft will release the fix? I don't want to apply a workaround to a production environment...

    Tuesday, July 16, 2019 3:04 PM
  • I have opened a ticket to Microsoft, it seems a fix is planned for 2019.08. Fingers crossed...
    Monday, July 22, 2019 10:07 AM
  • Thanks Andrea, hopefully so... :)
    Thursday, August 8, 2019 8:10 PM
  • I have opened a ticket to Microsoft, it seems a fix is planned for 2019.08. Fingers crossed...
    Update is out. Looks good so far!
    Tuesday, August 13, 2019 8:20 PM
  • Thank you for this!
    Wednesday, August 14, 2019 4:12 PM
  • Hi

    Do you know the KB number for this update?

    Thursday, August 15, 2019 2:24 PM
  • KB4511553 

    https://support.microsoft.com/en-us/help/4511553

    Fixes: 
    Addresses an issue with a Windows Server Update Services (WSUS) console user interface (UI) exception that occurs when you expand the Computers directory



    Friday, August 16, 2019 1:09 PM