Checklist for Windows 2012 Cluster installations -- SQL Server cluster installation taking forever

Failover Cluster Manager will hang unless following KB is installed (on Windows Server 2012)
https://support.microsoft.com/en-us/kb/2803748

If you can't use VMware/Hyper-V mounts, transfer SQL Server installation medias to C:\temp\ as ISO file and mount them as Z: or anything else as chosen cluster disks letter to avoid errors

SQL Server installation needs be started from cmd by using switches listed in KB: https://support.microsoft.com/en-us/kb/953748 if Windows Cluster has errors in it

• Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster on first node
• Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode on second node

When the installer is started, it will take VERY LONG time (HOURS) to process any operation unless admin shares are enabled

To enable admin shares do following

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
Change the value of LocalAccountTokenFilterPolicy to 1

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
Change the value of AutoShareWks to 1 
Change the value of AutoShareServer to 1

Patching SQL Servers with SCCM (Microsoft System Center Configuration Manager)

I've been looking from Google opinions about whether to do or not do SQL Server patching with SCCM. I've only found one topic from SQL Server Central (http://www.sqlservercentral.com/Forums/Topic1589012-1550-1.aspx -- might require userid to see) with one answer 'I do not recommend'.

This was not the answer which I was looking for so I went ahead together with our company's SCCM guys and made some test patching of SQL Server's (2008/2008 R2 and 2012 -versions). Those patch runs executed without any hassle and issues.

I'll agree that this process is missing the part where the application connection is tested afterwards and no backup is taken before patching. These are though things that can be tackled by regular backup schedule. Application connection testing would require end-to-end monitoring, but usually rebooting the application server(s) will re-establish the db connection and would end to errors if the connection is not working.

So if you're like me and trying to find courage from Google to start patching SQL Server by using SCCM I can assure you that it's not a big of deal and the trade off is quite huge. No more time on moving the Service Pack's into servers and executing them manually. We got several (tens -- not hundreds) of internal SQL Server's back into shape in a day.