So, go to IIS Manager, Click WSUS Website features view, Select MIME Types, and delete the MIME Type from there. Restart the website and check if you can Download updates now.
Post your SCCM tips and tricks, requests for help, or links others might find useful! Post not showing up?It might have been caught by the spam filter. URL shorteners cause this almost every time, but so do strings of apparent gibberish like WSUS and PXE sometimes. We don't check the modqueue very often. if your post is stuck!Resources:.(largely outdated)Chat Groups.Current Version:.Flair:. Flair is reserved for Microsoft employees and MVPs.
Please send mod mail if you qualify and would like flair set for your account.Contributing MVPs.Contributing Microsoft Employees. This originally was going to be a problem submission post, but I fixed it while typing everything out so I thought I'd post and share in case anyone else runs into this issue.
I was having an issue with SCCM (on version 1610 - Server 2012 OS) and I'm not sure how long this issue had been occurring. 0% of my updates were deploying, most of my machines were 'unknown' status, the ones that weren't were reporting in an Error state almost universally with error 0x8024401F 'Same as HTTP status 500 - an error internal to the server prevents fulfilling the request'.
Applications were deploying fine, just updates have this issue.I looked at this blog post but Directory Browsing was already enabled. I also tried disabling. No notable errors in WCM.log or WSUSCtrl.log on the server side. Wsyncmgr.log was showing that the actual sync is taking place fine, no errors.Clients have the following error line in their WUAHandler.log file: 'OnSearchComplete - Failed to end search job. Error = 0x8024401f.' Along with 'Scan failed with error = 0x8024401f'.I compared settings with another organization and I wasn't finding any differences. I do not have a domain GPO pushing out the update server name, the local client is controlling that setting(Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows UpdateSpecify intranet Microsoft update service location).
Permissions to the SCCMContentLib and SMSSIG$ directories are set identical to the other organization which is functional. I found another post that had something about duplicate MIME types, but I don't have any and I do not get a 500 error when navigating to at the C:WindowsWindowsUpdate.log file on a client, I saw the error 'WebServices WS error: There was an error communicating with the endpoint at 'This led me to go into IIS and look at the SimpleAuthWebservice component. Sure enough, I got an error when attempting to expand that component.
It stated it couldn't find the web.config file for this service at C:Program FilesUpdate ServicesWeb ServicesRootSimpleAuthWebService. I went to navigate to that directly and what do you know, the whole directory is just straight up missing (it wasn't moved nor one level up, just gone)!I tried to remove & reinstall the WSUS role, but that didn't work.
I ended up having to rip out & reinstall the IIS Role along with any associated dependent roles (WSUS, some of the.NET HTTP Activation features, etc.) Ran into some hiccups because I forgot to add back a BITS feature which was removed. After doing this, the SimpleAuthWebService component was repaired. The location was changed to 'C:Program FilesUpdate ServicesWeb ServicesSimpleAuthWebService' and the folder now existed at that location. It took a few hours to re-sync WSUS and for all the dust to settle, but updates were now reporting and deploying successfully in SCCM.