Most of my SQL Servers are on 2016 SP2. The security group have identified that I need a later security update applied and as SP2 is out of support this year I planned to just patch it up to SP3. The problem is I have never actually patched SQL Server and was wondering what a good process would be to follow when applying the service pack. I have seen some online, all roughly the same, but just need some opinions on the best way to go about it. Some questions I have, from looking at these processes online are: - I'm assuming the SQL Server instance will need to be restarted. Is this done automatically when installing the patch? - Does all activity on the instance need to be stopped? I.e., do all application services communicating with the instance need to be shut down? - Should the SQL Agent be stopped as well?

Some SQL Server updates have happened outside the maintenance window, which have caused the server to be rebooted. How can I stop this from happening again in future? Below is what I can see when looking at the Windows Update Settings:

I have some SQL Server machines that cannot connect to any external sites. I have been using PowerShell more and more when managing databases, so I definitely need this module to be installed so that I can use my PowerShell routines. It has been proven difficult to install the SQL Server module on those offline machines. When I try to install the module: the `SqlServer` module asks for the NuGet module package: I then get this ocean of red letters and the following error message as you can see on the picture below: WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''. WARNING: Unable to download the list of available providers. Check your internet connection. PackageManagement\Get-PackageProvider : Unable to find package provider 'NuGet'. It may not be imported yet. Try 'Get-PackageProvider -ListAvailable'. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7415 char:30 + ... tProvider = PackageManagement\Get-PackageProvider -Name $script:NuGet ... What is the workaround for this PowerShell module installation?

We have a SQL Server: Microsoft SQL Server 2017 (RTM-CU14-GDR) (KB4494352) - 14.0.3103.1 (X64) Mar 22 2019 22:33:11 Enterprise Edition (64-bit) on Windows Server 2016 Datacenter 10.0 (Build 14393: ) (Hypervisor) Tried to install "Cumulative Update Package 18 for SQL Server 2017 - KB4527377" https://www.microsoft.com/en-us/download/details.aspx?id=56128 Setup was doing something for 15 min, installing and updating files, stopping / starting services, it looked like its going to succeed, but in the end it showed this: Action required: Use the following information to resolve the error, and then try the setup process again. Feature failure reason: An error occurred during the setup process of the feature. Error details: Error installing SQL Server Database Engine Services Instance Features The User Log directory in the registry is not valid. Verify DefaultLog key under the instance hive points to a valid directory. Error code: 0x851A0044 Visit https://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.3257.3&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068 to get help on troubleshooting. What's preventing CU18 from installing ?

Checking SQL Server 2014 build versions to identify the right update for my server I got a little confused as what update to use. Did some research and found out I should Apply the latest Service Pack and Cumulative Update. Ok, but one question remained: I currently have SP2 installed and there's a CU for SP2 with the release date of July 29, 2019, but SP3 has been released October 30, 2018. The way I see it, the CU15-CU18 for SP2 shouldn't exist. (I know I'm wrong, but I don't know why) What's there in a service pack that one might not want to install it but will install other CUs that were released after the most recent SP?

My change request to patch 3 SQL instances on the same server was denied because of one instance - they say a server reboot is fine, but not a few hours downtime. Seeing as each instance is standalone, should it not be fine to patch 2 instances and leave the third? I see there is a 'shared components' feature - what is this exactly, is this down for all instances during the patching, and does it matter? How can I assuage the fears of my colleagues that the third instance will still be working - the business are not willing for it to go down even for a couple of hours in the evening.

My SQL server farm has been neglected with patching OS level & SQL server level (because they are critical systems, outages are hard to come by). An option is to patch the secondary nodes of our AOAG clusters up to the latest patch one month, then the next month the business agree to schedule a fail over out of hours.. I can then patch the new secondary (old primary). This will mean the nodes wont be on the same patch level for a month.. is this “a no no”?

I have always thought that all the changes in the CU's are rolled up into the next services pack. I recently was looking at changes in SQL 2016 SP2, and SQL 2016 CU15 for SP1. I was surprised to see that none of the KB in SP1CU15 was mentioned in the SP2. What am I missing?

While applying cumulative updates to sql server 2016 SP1, there are a bunch of services and applications that need to be stopped for the update to go on. Among those is the very core of the virtual machine, the VMware Tools core service. Is it safe to stop all the instances of this application in order to go on with the updates? What could be a safe way of doing it?

Microsoft released SQL Server 2017 CU10 KB4342123 (14.0.3037.1) yesterday. I tried looking through the Hotfixes included list, but didn't see any reference to the recently released security update for the remote code execution vulnerability hotfix KB4293805 CVE-2018-8273 (14.0.3035.2). How can we determine if SQL Server 2017 CU10 includes the security hotfix KB4293805 CVE-2018-8273 or not? Is the higher version number of CU10 enough to determine that? NOTE: I've already installed the CVE-2018-8273 fix onto CU9.