Microsoft launched KB3194721 (for SqlServer 2012) and KB3194718 (for SqlServer 2014) this month though WSUS channel. If you choose to deploy them though WSUS, just as I did, you may face a bug on a cluster based SqlServer.
On the server with SqlServer installed as cluster, these patches just act as cancelled or failed. For digging the problem, I download the package from Microsoft Download Site and try to install them manually. The first step is decompressing. Files are placed on the largest drive (I dunno it based on the total or free space). In my case, one disk drive for a database role is chosen. Then the upgrading procedure starts, with a bug that is:
If the owner of this instance role of cluster is the same computer, the role will be automatically stopped during update process, and will be started later. But while the role is set to stop, the disk drive is offline with it. So, if that drive is the largest, sadly, the update procedure fails — source files of update package are missing.
Even you run these packages manually, not from WSUS, it’s still not possible to choose the folder to decompress. If some drive of database role of cluster is larger than all server self-owned disks, you may want to STOP THE NODE in cluster as a workaround.
In one datacenter of my company, there was a strange problem last month of VMware vSphere.
Here is our structure:
SqlServer instance for vSphere is installed dedicated on cluster server. SqlServer version is 2012 Enterprise and Windows is 2012R2 Standard
vCenter is installed on another server.
After we applied July patches from Microsoft and restart the vCenter server, nearly all services from VMware cannot start. In event viewer, one event said:
The VMware Inventory Service service terminated with the following service-specific error:
As the request from VMware support, I uninstalled all updates related and reboot but it won’t help. I thought there may be some error related to the database connection. I ran the connection test from ODBC setup window, test finished succeeded. So I collected and submitted the log file generated from vCenter server command line. You know it’s really huge.
2 weeks later, I got an email from the high level engineers of VMware. By digging the log, they found that the vCenter cannot connect to SqlServer and the tcp service port is specified. At that moment, thanks to documentation I wrote :), I found that tcp service port is different than it should be. When I checked the SqlServer, I found the reason really weird: the TCP port of this instances is modified, automatically and silently. Due to I really used vSphere client just before upgrading Windows, I’m quite sure this issue is related to at least one of the patch which applied on the database cluster, launched by Microsoft in July 2016. And after a search, there is another instance of SqlServer which has the port changed. Due to the port changed and our firewall policy is set based tcp port, the client, vCenter in this issue, cannot connect to this SqlServer instance. After the port setting changed back and instance restarted, vCenter is back to normal.
Don’t ask me why ODBC test passed without any problem. If you know the answer, I’m listening as well.
When you need to move the SQL Server instance to another server, you can use SQL Alias to get avoid of changing connection string for softwares which use this database.
All you need is setting up SQL Alias on the computers running your softwares. Nothing need to be done with the SQL Server if it’s installed other than the computers running applications.
The tool for setting up SQL Alias is included with Windows. You just need to run cliconfg.exe to set. Be careful the typing — it’s not config.
If your Windows is x64 based, you may need to choose the right version of that tool. The x64 version is C:\Windows\system32\cliconfg.exe and the x86 version can be located as C:\Windows\syswow64\cliconfg.exe. If you don’t know which is the right one, set up both of them.
If you wanna deploy Sharepoint 2010 with a SqlServer 2008 R2 ON ANOTHER SERVER, make sure that the domain account which will be used as Sharepoint Service has the dbcreator and securityadmin permission in the target SqlServer.
If securityadmin is not selected, you may have trouble to setup a search service application. All you need is delete the deployed search service application, add permission to SqlServer and re-create a new search service application.