Blog

  • Windows Server 2016 Updates taking HOURS???

    I know this is a SharePoint blog but I know many of you (like me) are in charge of installing patches/updates on the SharePoint servers. With Office Online Server, Microsoft Identity Manager, Workflow Manager and all of the SharePoint Farm Servers, I manage a total of 12 servers for Production and 3 development servers. ALL are running Windows Server 2016.

    These updates take many MANY hours (say between 4-8 hours depending on other updates included). This is not good for production servers to be down for this long even when we run them after hours. This happens with or without utilizing WSUS (Windows Server Update Services). In the process of updating the servers, I also am forced to restart 2-3 times which is also frustrating.

    After days of research and not finding any answers, I decided to open a Microsoft ticket to see if they had any tips to make it go faster. As it turns out, there is a known issue and they provided a workaround. Wow, it would’ve been nice to have known this before! I spent hours every month patching these servers. When I researched before, I saw many upset server admins who were also frustrated so I hope I’m able to help someone with this issue. The workaround provided is temporary as supposedly they are to release a fix early next year but it needs to be ran before EVERY patching session until then. Updates still take a little while but this fix has cut my patching to less than half the time as before. I was able to complete some servers in 1.5 hours which is so much better than before.

    The Microsoft tech also said to check services to ensure Windows Modules Installer is running as well.
    Below is what he said to do:

    This is currently a known issue when the patches apply to the server are considered express.cab, as the one below:

    2019-08-19 14:54:50, Info                  CBS    Extracting all files from cabinet \\?\C:\Windows\SoftwareDistribution\Download\02376742ab3107e647f54bce4ee442a5\Windows10.0-KB4512495-x64-express.cab

    The workaround provided by the product group is rename SoftwareDistribution, and Catroot2:

    Run the below commands to rename the SoftwareDistribution and Catroot2: 

    net stop wuauserv

    net stop bits

    net stop appidsvc

    net stop trustedinstaller

    ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

    ren C:\Windows\Logs\CBS\cbs.log cbs_prev.log

    net stop cryptsvc

    ren C:\Windows\System32\catroot2 catroot2.old

    Enable services again:

    net start bits

    net start wuauserv

    net start appidsvc

    net start cryptsvc


    Note: When I ran these commands this month, it could not rename the files since they were already renamed. He said I can still run the commands to ensure services are started. He also mentioned that in WSUS, I can ensure that express updates are not ran (I don’t run our WSUS server but I did forward this information to them as well).

  • Chrome and Firefox Office Online Server: We couldn’t find the file you wanted. It’s possible the file was renamed, moved or deleted.

    Are you getting Office Online Server/Web Apps errors on Chrome or Firefox but not Internet Explorer?

    We got LOADs of different errors. Some are shown below.

    Your connection is not secure

    The website tried to negotiate an inadequate level of security.

    WebappURL.domain.com uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site.

    Error code: NS_ERROR_NET_INADEQUATE_SECURITY

    or

    Office Online Server: We couldn’t find the file you wanted. It’s possible the file was renamed, moved or deleted.

    We had such a weird issue as we recently installed patches on our Office Online Server and rebuilt the farm as always. Tested in IE and it was working but then we started receiving tickets about no files loading in Chrome or Firefox. Checked the health status of the farm servers, checked the XML link which was working properly, checked the certificates were set on each server and the checked the bindings on the SharePoint servers. Everything was correct and it was running seamlessly on IE. So what could be the problem?

    After almost a full day of research, I decided to go ahead and rebuild the farm and re-do the bindings. After setting the certificates in IIS on each OOS server, it was doing the SAME THING! Then I realized I had forgotten to restart the servers. It says in powershell after you set the certificate that you must restart the servers. DOH! Restarting the servers fixed the issue. It turns out that Firefox and Chrome have a setting that detects the proper certificate and it didn’t pass their checks until the server was never restarted after setting the certificates.

  • Deleted Extended SharePoint Web Application in IIS

    Let’s say someone accidentally deleted an extended Web Application via IIS Manager rather than Central Administration. You’ll find out you’re going to have a bad time. I tried extending said web application using the same name as before and was presented with the error  “The IIS Web Site you have selected is in use by SharePoint. You must select another port or hostname.”

    To fix this issue you can go to Central Administration > Application Management. Select the Web Application that was extended. Click on the Delete dropdown and select Remove SharePoint from IIS Web Site. In the following window, choose the site you want to delete from the dropdown and under Delete IIS web sites select Yes. This will completely remove the files associated with the extended web application allowing you to extend it again using the same name.