Hi folks,
I got handed a mess made by someone who quit recently that will probably make this more difficult to repair.
This is a Windows 2016 Storage Server, made by HPE, and appears to be the japanese model. From what I understand, this was never commissioned correctly, and for a long time windows update never actually worked from the beginning (though that seesm to be a longstanding bug of RTM 2016 Storage Server?). At some point in the past someone applied a servicing stack update and it started to do autoupdates normally.
Then, it looks like it got bit by the summer 2019 windows defender powershell hash bug from windows update, and SFC has been complaining ever since, and it appears no cumulative updates have successfully installed since.
The guy who quit apparently at some point deleted older CBS.persist logs in some mistaken attempt at fixing things, so that isn't helping. That seems to be why SFCfix dies with an error.
The next guy involved did try a number of number of things, trying to do a DISM restorehealth from another same model server that was delivered at the same time but that didn't seem to work (though his source settings may have not been correct, as he attempted both a network drive mapping as well as an administrative share access). He also tried MSDN ISO's (all three available japanese ISO's)(apparently we don't have access to an install CD from HPE), but those sources failed also. At that point he kicked it up to me.
At this point DISM restorehealth accessing windows update fails with an out of memory error 14 despite the machine having at least 10GB RAM free. I tried changing SVChostSplitThresholdKB to 16GB from the default 3.8GB, as well as IRPstacksize to 45, but that didn't change things.
I'm not sure why DISM sourcing from the same model machine is failing. Does the remote access require a true windows share rather than an administrative share, and does that require giving certain specific permissions, such as to the machine account from the broken machine?
I got handed a mess made by someone who quit recently that will probably make this more difficult to repair.
This is a Windows 2016 Storage Server, made by HPE, and appears to be the japanese model. From what I understand, this was never commissioned correctly, and for a long time windows update never actually worked from the beginning (though that seesm to be a longstanding bug of RTM 2016 Storage Server?). At some point in the past someone applied a servicing stack update and it started to do autoupdates normally.
Then, it looks like it got bit by the summer 2019 windows defender powershell hash bug from windows update, and SFC has been complaining ever since, and it appears no cumulative updates have successfully installed since.
The guy who quit apparently at some point deleted older CBS.persist logs in some mistaken attempt at fixing things, so that isn't helping. That seems to be why SFCfix dies with an error.
The next guy involved did try a number of number of things, trying to do a DISM restorehealth from another same model server that was delivered at the same time but that didn't seem to work (though his source settings may have not been correct, as he attempted both a network drive mapping as well as an administrative share access). He also tried MSDN ISO's (all three available japanese ISO's)(apparently we don't have access to an install CD from HPE), but those sources failed also. At that point he kicked it up to me.
At this point DISM restorehealth accessing windows update fails with an out of memory error 14 despite the machine having at least 10GB RAM free. I tried changing SVChostSplitThresholdKB to 16GB from the default 3.8GB, as well as IRPstacksize to 45, but that didn't change things.
I'm not sure why DISM sourcing from the same model machine is failing. Does the remote access require a true windows share rather than an administrative share, and does that require giving certain specific permissions, such as to the machine account from the broken machine?