On SQL Server 2008 the concept of Service SID was introduced to be used when installing on Windows 2008 or later.
The concept of Service SID (also known as Virtual Account) allows assigning the required permission needed for the correct functioning of the SQL Instance without using Local Groups or Domain Groups (in a cluster scenario). Instead, the permission will be assigned to the Service SID.
Just to be clear, the concept of Service SID is no from SQL Server, but form Windows Server 2008 or later, and SQL Server 2008 or later can take advantage of this feature.
The interesting part when configuring permissions or rights like “Lock Pages in Memory” or “Perform Volume Maintenance Tasks”, historically they were assigned to the SQL Service account. But now that the Service SID come into play, whom should I assign the rights? Similarly, if I want to do a backup on a network share, whom should I assign the permission on the share, so SQL Server can write the backup.
The same questions apply to any other privilege that before should be assigned to the Service account.
The answer is, that you can assign the privilege or permission to any and SQL Server will work fine. However, because the Service SID have the scope of only the computer where you installed SQL, to assign permission outside the computer you have to use the computer account, the name format is “DomainName\ComputerName$”.
In conclusion the privileges for SQL Service is the union of the privileges from the Service SID plus the privileges from the Service account.
Now that you know you can assign the privileges to both accounts, the service account or the Service SID, Which one should we use?, because the service account can be changed, the best practice is to assign the privilege to the service SID whenever possible.
To be clear on the concept of Service SID, for those who don’t have experience with it, check the following images. The account “NT Service\MSSQLServer” is the Service SID. The name of the service SID will include the instance name as part of the name, for example “NT Service\MSSQL$Denali”. In the images is shown how to add a Service SID to the privilege Lock Pages in Memory and the permissions for a folder.
The use of the service SID are extended on SQL Server 2012 and also exists the concept of Managed Service Account starting on Windows 2008, but those are concepts for other post.
http://support.microsoft.com/kb/2620201/en-us
http://msdn.microsoft.com/en-us/library/ms143504.aspx#MSA
http://blogs.technet.com/b/sqlpfeil/archive/2012/02/16/sql-amp-sids-why-we-need-it-and-what-the-hell-it-is.aspx
Windows Server 2012 incorpora una nueva funcionalidad llamada Windows-Aware Updating (CAU) que permite la orquestación automática de la instalación de actualizaciones para el sistema operativo y otras aplicaciones que ejecuten sobre los nodos de un Clúster. Esta funcionalidad está muy bien integrada con aplicaciones como Hyper-V, sin embargo, puede ser utilizado para actualizar cualquier aplicación Microsoft e incluso aplicaciones de terceros.
Está funcionalidad, que sólo puede ser utilizada en clúster Windows Server 2012, facilita la tareas de actualización de ambientes, especialmente al tomar en cuenta que es posible crear clúster de hasta 64 nodos, ya que Windows se encarga de coordinar (orquestar) todas las acciones relacionadas con la actualización, tales como el failover de los servicios, la instalación de actualizaciones y reinicio de nodos. Esto permite al administrador concentrase exclusivamente en monitorear el proceso de actualización y de esa forma poder actualizar varios ambientes simultáneamente haciendo un uso más eficiente de su tiempo.
Una vez configurado, CAU funciona de la siguiente manera:
Existen dos modos para la ejecución del proceso: desde una máquina (Windows 8 o Windows Server 2012) diferente a los nodos del clúster (remote updating mode) o desde uno de los nodos del clúster (self-updating mode).
Nota: para habilitar esta herramienta en Windows 8 es necesario descargar Remote Server Administration Tools (RSAT) for Windows 8 desde http://www.microsoft.com/en-us/download/details.aspx?id=28972
Independientemente del modo utilizado, podemos especificar el plug-in que permitirá definir el origen de las actualizaciones a instalar:
Microsoft.WindowsUpdatePlugin
Este plug-in instala por defecto las actualizaciones GDR de seguridad importantes y criticas directamente desde Windows Update, Microsoft Update,y las actualizaciones aprobadas desde el servidor Windows Server Update Services (WSUS), aunque es posible instalar actualizaciones GDR adicionales configurando parámetros adicionales del plug-in.
Microsoft.HotfixPlugin
Este plug-in instala actualizaciones LDR (antiguamente QFE) desde una carpeta en un file share SMB, y puede ser configurado para instalar actualizaciones no Microsoft, tales como actualizaciones de firmware o de BIOS.
En ambos modos e independientemente del plug-in a utilizar, CAU puede ser invocado usando una herramienta gráfica o a través de comandos PowerShell (http://technet.microsoft.com/en-us/library/hh847221.aspx)
NOTA: Para esta explicación utilizaré la herramienta gráfica que permite una visualización más sencilla del proceso. Para este ejemplo usaremos un Clúster Windows Server 2012 de tres nodos y ejecutaremos el modo self-updating.
Para iniciar la herramienta gráfica, hacemos click derecho sobre el nombre del clúster -> More Actions -> Cluster-Aware updating, tal y como se observa en la siguiente imagen.
Para visualizar las actualizaciones que serán instaladas en cada uno de los nodos, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in deseado y hacer click sobre “Generate Preview update list”. En el siguiente ejemplo, se utilizó plug-in Microsoft.WindowsUpdatePlugin para obtener la lista de actualizaciones no instaladas desde Windows Update.
En este caso, no es posible seleccionar cuales actualizaciones se desea instalar, ni en cuales nodos. Si se desea aplicar actualizaciones sobre nodos puntuales o sobre instancias específicas, es necesario utilizar el Microsoft.HotfixPlugin.
Para utilizar Microsoft.HotfixPlugin, la primera acción a ejecutar es crear una estructura de directorios que indicará cuales actualizaciones serán instaladas en cada nodo. Para esto se crea un fileshare con la siguiente estructura
\\<networkshare>\hotfixroot
DefaultHotfixConfig.xml
\CAUHotfix_All
Update1.msu
Update2.msi
Update3.msp
\<nodo 1 name>
Update4.exe
\<nodo 2 name>
Update 5
….
\<nodo x name>
UpdateY.exe
Donde:
NOTA: el archivo DefaultHotfixConfig.xml puede ser copiado desde la ruta C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating desde cualquiera de los nodos. Este archivo, sin modificaciones, permite la instalación de la mayoría de las actualizaciones no SQL Server. Para mayor información ver http://technet.microsoft.com/en-us/library/jj134213.aspx
Cuando estamos instalando actualizaciones para SQL Server, es necesario definir una estructura diferente y modificar el archivo de configuración, con el objetivo de especificar los parámetros de ejecución, tales como la instancia sobre la que se instalará la actualización. Supongamos que deseamos instalar el Service Pack en una o todas las instancias y en todos los nodos la estructura debe ser similar a la siguiente:
\SQL2012SP1
\<SQLServer2012SP1Package>.exe
Si quisiéramos instalar el Service Pack en una instancia que ejecuta sólo sobre los nodos 2 y 4 del clúster, la estructura sería similar a la siguiente
\<nodo 4 name>
Donde SQL2012SP1 es el nombre de la regla que será utilizada para definir los parámetros de ejecución de la actualización y es definida por el usuario.
NOTA: El directorio \CAUHotfix_All puede existir y estar vacío, pero en este caso se elimina para evitar instalar por error alguna actualización en todos los nodos.
En ambos casos, se debe modificar el archivo DefaultHotfixConfig.xml para agregar la regla (la sección en rojo del ejemplo) que permite especificar los parámetros de ejecución del paquete de actualización. Adicionalmente permite especificar las condiciones de éxito de instalación de la actualización.
<root>
<DefaultRules>
…
</DefaultRules>
<FolderRules>
<Folder name="SQL2012SP1">
<Template path="$update$" parameters="/ACTION=PATCH <INSTANCIA A ACTUALIZAR>
/QUIET /IAcceptSQLServerLicenseTerms"/>
<ExitConditions>
<Success>
<ExitCode code="0"/>
</Success>
<Success_RebootRequired>
<ExitCode code="3010"/>
</Success_RebootRequired>
<NotApplicable>
<ExitCode code="-2068578302"/> <!-- ERROR_PATCH_TARGET_NOT_FOUND -->
</NotApplicable>
<AlreadyInstalled>
<ExitCode code="-2068643838"/> <!-- ERROR_PATCH_ALREADY_APPLIED -->
</ AlreadyInstalled >
</ExitConditions>
</Folder>
</FolderRules>
</root>
Donde <INSTANCIA A ACTUALIZAR> puede:
NOTA: los parámetros a especificar corresponden a los parámetros de instalación de SQL Server desde el command prompt (http://msdn.microsoft.com/en-us/library/ms144259.aspx)
En cuanto a las condiciones de éxito para el CAU, existen sólo cuatro para SQL Server:
En algunos escenarios se omiten los últimos dos códigos del archivo de configuración con el objetivo de determinar ejecuciones no válidas resultado de una estructura de directorios errada, la configuración incorrecta del nombre de la(s) instancia(s) a actualizar o el intento de instalar una actualización que no aplica al ambiente, ya que la ejecución de CAU retorna un estado fallido para los nodos configurados incorrectamente.
NOTA: Cuando la estructura de directorios especifica nombres de nodos y/o se especifiquen instancias en el archivo de configuración, se debe tener especial cuidado para evitar que alguna instancia quede sin actualizar en alguno de los nodos sobre el que ella pueda ejecutar, ya que un failover a dicho nodo generará un downgrade de la instancia.
Una vez creada la estructura de directorios, y para validar que CAU instalará las actualizaciones deseadas en los nodos indicados, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in Microsoft.Hotfix, establecer los parámetros del plug-in (lo cual se describe en la segunda parte de post) y hacer click sobre “Generate Preview update list”. Veremos el ejemplo particular de dos actualizaciones de Windows con la siguiente estructura de directorios:
\\WIN-0M99J4ILA2E\UpdatesDemo\Root3
\windows8-RT-KB2792100-x64.msu
\Win20121>
\windows8-RT-KB2737084-x64.msu
\Win20122
\Win20123
Se observa que windows8-RT-KB2792100-x64.msu será instalado en todos los nodos, mientras que windows8-RT-KB2737084-x64.msu sólo será instalado en Win20121 y win20122 de acuerdo a lo especificado en la estructura de directorios.
En la segunda parte del post (Windows Aware updating y SQL Server (Parte II) – Paso a Paso) se explicará cómo configurar y ejecutar CAU para instalar un Service Pack de SQL Server 2012.
Windows Server 2012 has incorporated a new functionality called Windows-Aware Updating (CAU) that allows the automatic orchestration of the installation of updates for the operating system and other applications that are executed on the Cluster nodes. This functionality is really well integrated with applications like Hyper-V, however, can be used to update any Microsoft Application or third party applications.
This functionality, that can only be used on Windows Server 2012 Clusters, eases the task of updating environments, especially when we consider that is possible to create a 64 nodes cluster, Windows will take charge to coordinate (orchestrate) all the actions related with the updates, like the services failover, updates installation and node restart. This allows the administrator to concentrate exclusively in monitoring the process of update and in this manner updating many environments simultaneously using time more efficiently.
Once configured, CUA functions as follow:
There are 2 modes for the execution of the process: from a machine (Windows 8 or Windows Server 2012) outside of the cluster (remote updating mode) or from one of the nodes in the cluster (self-updating mode)
NOTE: to enable this tool on Windows 8 is necessary to download Remote Server Administration Tools (RSAT) for Windows 8 from http://www.microsoft.com/en-us/download/details.aspx?id=28972
Regardless the mode you are using, we can specify the plug-in that allows to define the origin of the updates to install:
This plug-in install by default the GDR security important and critical updates, directly from Windows Update, Microsoft Update, and approve updates from the Windows Server Update Services (WSUS) Server, although is possible to install additional GDR Updates configuring additional parameters in the plug-in
This plug-in install LDR Updates (previously QFE) from a folder on a file share SMB, and can be configured to install non-Microsoft updates, like updates for firmware or BIOS.
On both modes and indifferently of the plug-in you are going to use, CAU can be invoke using a graphic tool or using Power Shell (http://technet.microsoft.com/en-us/library/hh847221.aspx)
Note: for this post I will use the graphic tool, this allows a simpler visualization of the process. This example will use a Windows Server 2012 Cluster with 3 nodes and execute the Self-updating mode.
To start the graphic tool, right click on the cluster name -> More Actions -> Cluster-Aware updating, like you can see on the figure
To visualize the updates that will be install on each node, we can click on “Preview updates for this cluster”, select the desired plug-in and click on “Generate Preview update list”. In this example, we used the Microsoft.WindowsUpdatePlugin plug-in to obtain the list of updates not installed from Windows Update.
In this case, is not possible to select which updates to install, or in which nodes. If you’ll like to apply updates on a specific node or specific SQL Instances, is necessary to use the Microsoft.HotfixPlugin.
To use the Microsoft.HotfixPlugin, the first action to execute is create the structure of directories that indicates which updates are installed on each node. For this you’ll create a file share with the following structure.
Where:
NOTE: the file DefaultHotfixConfig.xml can be copied from the path C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating from any node. This file, without any change, allows the installation of most of the non-SQL Server updates. For more information http://technet.microsoft.com/en-us/library/jj134213.aspx
If you are installing updates to SQL Server, is necessary to define a different folder structure, and modify the configuration file, with the objective to specify the parameters of execution, like the SQL Instance where the updates it’s going to be applied. Let’s suppose we will like to install the Service Pack on one or all the instances, in all the nodes, the structure should be similar to:
If we’ll like to install the Service Pack on one instance that only executes on the nodes 2 and 4 of the cluster, the structur should be similar to:
Where SQL2012SP1 is the name of the rule that will be used to define the parameters of execution for the update and is defined by the user.
NOTE: the directory \CAUHotfix_All can exist and be empty, but in this case was erase to avoid the installation of any update on all the nodes by mistake.
In both cases, you need to modify the file DefaultHotfixConfig.xml to add the rule (Red section of the example) that allows the specification of the execution parameters of the update package. It also allows to specify the success conditions of the update.
Where <INSTANCIA A ACTUALIZAR> can:
NOTE: the parameters to specify match the parameters of a SQL Server installation form the command prompt (http://msdn.microsoft.com/en-us/library/ms144259.aspx)
On the success condition for CAU, there are only 4 for SQL Server:
On some scenarios you can omit the last 2 codes from the configuration file, with the objective of determine not valid executions, result of a bad folder structure, and incorrect name of the SQL Instances to update or the intent to apply an update that doesn’t apply to the environment. The CUA will return a failed state for the misconfigured nodes.
NOTE: When specifying on the folder structure and /or the name of the instances on the configuration file, you should be really careful to avoid that one of the SQL instance been outdated on a node where it can be stated, because this will cause a downgrade of the instance.
Once you have created the folder structure, and to validate that CUA will install the desired updates on all the indicated nodes, we can click on “Preview updates for this cluster”, select the plug-in Microsoft.Hotfix, establish the plug-in parameters (this is described on the second part of this post) and click on “Generate Preview update list”. Let’s see a particular example of 2 Windows Updates with the following folder structure:
As you can see the windows8-RT-KB2792100-x64.msu will be installed on all the nodes, while the windows8-RT-KB2737084-x64.msu will be installed on Win20121 and Win20122 only, as specified on the folder structure.
On the second part of the post (Windows Aware updating and SQL Server 2021 (Part II) – Step by Step) we will explain how to configure and execute CAU to install a Service Pack for SQL Server 2012.
Ya que en este punto tenemos claros los conceptos de Windows Aware Updating (CAU), en esta segunda parte revisaremos como podemos utilizar el plug-in Window.HotfixPlugin para instalar actualizaciones LDR, actualizaciones acumulativas y Service Packs, así como las opciones que provee para tener un mayor control del proceso. NOTA: CAU puede sólo puede ser utilizado a partir del Service Pack 1 de SQL Server 2012.
Como ejemplo instalaremos el Service Pack 1 de SQL Server 2012 en los nodos Win20121 y Win20122. (Este proceso es similar para cualquier acumulativa Update y Service Pack), utilizando la herramienta gráfica ya que permite una visualización más sencilla del proceso. Se usó un Clúster Windows Server 2012 de tres nodos con dos instancias SQL Server 2012 RTM que sólo ejecutan en los nodos win20121 y Win20122, y ejecutamos el modo self-updating.
Para evitar que el post sea muy largo se omiten capturas de pantalla para mostrar las versiones iniciales y finales de SQL, así como la configuración del Cluster. La idea principal es ver el proceso de CAU.
Ya que la actualización será instalada en dos de los tres nodos del clúster, utilizamos la siguiente estructura de directorios:
\\WIN-0M99J4ILA2E\UpdatesDemo\Root5
Así mismo, el archivo de configuración le agregué la siguiente sección en rojo.
<Template path="$update$" parameters="/ACTION=PATCH /allinstances
Como se describió en la primera parte del post, iniciamos la herramienta de Cluster-Aware updating.
Y hacemos click en “Configure cluster self-updating options”.
Hacemos click en Next.
Habilitamos el modo self-updating, y hacemos click en siguiente.
Luego configuramos la frecuencia de ejecución automática. Esto es útil especialmente con el plug-in Microsoft.WindowsUpdatePlugin para la instalación de actualizaciones de seguridad. El plug-in Microsoft.HotfixPlugin, al ser utilizado para la instalación de actualizaciones de no seguridad, requiere la configuración de la estructura de directorios y la descarga de instaladores por lo cual puede resultar más práctico su ejecución manual y supervisada, aunque una programación podría ser útil en algunos casos tales como la actualización de ambientes no productivos.
Configuramos aspectos de la ejecución tales como:
Tiempo máximo de ejecución en minutos (StopAfter), tras el cual se detiene todo el proceso de actualización.
Tiempo de advertencia en minutos (WarmAfter), tras el cual se genera un mensaje de advertencia, el cual pueder ser utilizdao, por ejemplo, para advertir que la ventana de mantenimiento definida para la actividad está cercano.
El orden en el que los nodos deben actualizados (NodeOrder,)
El plug-in a utilizar (CaaPluginName), en este caso Microsoft.HotfixPlugin
Parámetros adicionales requeridos por el plug-in Microsoft.HotfixPlugin
Otros valores, los cuales pueden ser consultados en http://technet.microsoft.com/en-us/library/jj134224.aspx
Establecemos las opciones para el Microsoft.HotfixPlugin tales como la raíz del fileshare que contiene la estructura de directorios y las actualizaciones a instalar.
NOTA: Para mayor información de las opciones de Microsoft.HotfixPlugin ver http://technet.microsoft.com/en-us/library/jj134213.aspx
Podemos ver un resumen de las opciones configuradas (que podemos utilizar en la opción descrita en la primera parte del post para pre visualizar las actualizaciones que serán instaladas durante la ejecución) y al hacer click en “Apply” finalizaremos la configuración de CAU.
Hacemos click en Close.
Una vez configurado el CAU, podemos iniciar la ejecución haciendo click en “Apply updates to this cluster”, lo que iniciará el wizard de ejecución.
Aquí podemos visualizar el comando PowerShell que puede ser utilizado para iniciar la actualización. Así mismo podemos visualizar las actualizaciones que serán instaladas haciendo click en “Preview the updates that will be applied to the cluster nodes”.
Antes de iniciar, y para validar que el Service Pack sólo será instalado en los nodos especificados en la estructura de directorio hacemos click en “Preview the updates that will be applied to the cluster nodes”.
Se observa que el Service Pack 1 será instalado sólo en los nodos Win20121 y Win120122, tal y como se estableció en la estructura de directorios. Para salir hacemos click en Close.
Para iniciar el proceso de actualización hacemos click en “Update”.
Una vez iniciado el proceso hacemos click en Close.
Lo que permite ver el avance del proceso hasta que este finalice.
Los failover de servicios no se registran en esta ventana, sin embargo, se realizan luego de colocar cada nodo en modo de mantenimiento. Al finalizar el proceso, las instancias se encuentran en el nodo original.
Debemos tomar en cuenta que este proceso es diferente a lo recomendado en el documento SQL Server failover cluster rolling patch and service pack process disponible en http://support.microsoft.com/kb/958734, en cuanto a que la mitad de los nodos que se actualizan no se eliminan como posibles dueño de los recursos de SQL Server, así como el momento en que se hace el failover de las instancias a los nodos actualizados. Este es una funcionalidad que nos puede ayudar a facilitar el proceso y configurando correctamente las opciones del plug-in Microsoft.HotfixPlugin podemos tener un comportamiento similar en varios aspectos al recomendado en este documento, por lo que los invito a probarlo y encontrar la configuración que mejor se adapte a sus necesidades.
Existen algunas consideraciones a tomar en cuenta cuando usamos CAU en ambientes Always On con Grupos de Disponibilidad, así como diferentes escenarios de actualización, por lo que recomiendo leer el documento Patching SQL Server Failover Cluster Instances with Cluster-Aware Updating (CAU) disponible en http://www.youtube.com/watch?v=XhVbLgf3rqE
Espero que los dos post de esta serie les hayan ayudado a entender cómo podemos utilizar esta nueva funcionalidad de Windows Server 2012 para facilitarnos un poco la vida.
Otras lecturas recomendadas:
Cluster-Aware Updating Overview
http://technet.microsoft.com/en-us/library/hh831694.aspx
Requirements and Best Practices for Cluster-Aware Updating
http://technet.microsoft.com/en-us/library/jj134234.aspx
At this point we already know the concepts for Windows Aware Updating (CAU), on this post we will check how to use the plug-in Windows.HotfixPlugin to install LDR updates, cumulative updates and Service Packs, and the options that provides to obtain a better control of the process. NOTE: CAU can only be used from SQL Server 2012 Service Pack 1 and up.
As an example we will install the Service Pack 1 of SQL Server 2012 o the nodes Win20121 and Win20122 (This process is pretty similar with any other cumulative update or service pack), using the graphic tool, this will allow a better and simpler visualization of the process. We are using a 3 nodes Windows Server 2012 Cluster with 2 SQL 2012 RTM instances, that can only start on Win20121 and Win20122, and we will use the self-updating mode.
To avoid a very long post some print screens that show the previous and later versions of SQL and the cluster configuration are omitted. The intent is to see the CAU process.
Because the update will be installed in 2 of the 3 nodes, we’ll use the following folder structure:
As described on the first post, we start the Cluster-Aware updating tool.
And click on “Configure cluster self-updating options”.
Then click on next.
Enable the self-updating mode, and click next.
Now we configure the automatic update execution frequency. This is particularly useful with the Microsoft.WindowsUpdatePlugin plug-in, to install the security updates. The Microsoft.HotfixPlugin
Plug-in, when used for the installation of non-security updates, requires the configuration of the folder structure and downloading the installers, that’s why might be more practical a manual and supervised. execution, although a schedule can be useful on some cases like the update of non-production environment.
Then click next.
Configure aspects of execution like:
Then we click next.
Establish the options for the Microsoft.HotfixPlugin like the file share root, that host the folder structure and the updates to install
NOTE: for more information on the options for the Microsoft.HotfixPlugin see http://technet.microsoft.com/en-us/library/jj134213.aspx
We can see a summary of the configured options (we can use this on the option describe don the first part of the post to check the updates that will be installed during the execution), now we click on “Apply” to finish the configuration of CAU
Click Close.
Once we have configures the CUA, we can start its execution clicking on “Apply updates to this cluster”, this will start the wizard.
Click Next.
Here we can visualize the PowerShell command that you can use to start the update. We can also see the updates that will be installed clicking on “Preview the updates that will be applied to the cluster nodes”.
Before we start, and to validate the Service Pack will only be installed on the specified nodes on the folder structure let’s click on “Preview the updates that will be applied to the cluster nodes”.
You can see that the Service Pack 1 will only be installed on the node Win20121 and Win20122, as you establish on the folder structure. Click Close.
To start the update process click on “Update”.
Once the process is started click in Close.
This allows us to see the progress of the updates until it ends.
The services failover are not log on this window, however, they are executed after putting a node on maintenance mode. After the process ends, the instances will be put in its original state.
We need to take into consideration that this process is different to the recommended on the document SQL Server failover cluster rolling patch and service pack process available on http://support.microsoft.com/kb/958734, in that the half on the nodes been updated are not automatically removed as possible owners of the SQL Server resources, as also the moment on which the failover of the instances to the updated nodes is done. This is a functionality that can help us to facilitate the process and if configured correctly, using the options of the Microsoft.HotfixPlugin plug-in we can get a similar behavior to the recommendations on the document on many aspects, so we invite you to try it and find the configuration that better suit your needs.
There are a few considerations to take into consideration when using CAU on Always ON Environments with High Availability Groups, and also many other updates scenarios, that’s why we recommend to read the document Patching SQL Server Failover Cluster Instances with Cluster-Aware Updating (CAU) available on http://www.youtube.com/watch?v=XhVbLgf3rqE
I hope this two post son this series help you to understand how to use this new functionality on Windows Server 2012.
Other Recommended Readings:
A partir de SQL Server 2008 se introdujo el concepto de utilizar Service SID cuando se instala en Windows 2008 o posterior.
El concepto de Service SID (o virtual account) permite que ya no necesitemos un grupo local o de dominio (en el caso de clusters) para asignar los permisos que requiere la instancia para poder trabajar correctamente. En su lugar, los permisos se le asignan al Service SID.
Solo para que quede más claro, el concepto de Service SID no es creado por SQL Server, sino por Windows Server 2008 o posterior y SQL 2008 o posterior puede tomar ventaja de ésta característica.
Lo interesante viene a la hora de configurar permisos o derechos como “Lock Pages In Memory” o “Perform Volume Maintenance Tasks”, históricamente le asignábamos éstos privilegios a la cuenta de servicio de SQL Server, pero ahora que existen los Service SID, ¿A quién se lo debo asignar?. Similarmente, si necesito hacer un Backup a un network share, ¿A quién le doy permisos sobre el share para que SQL Server pueda escribir el backup?
La misma pregunta aplica para cualquier otro privilegio que antes se le necesitaba dar a la cuenta de servicio.
La respuesta es que se le puede dar el privilegio o permiso a cualquiera de los 2 y SQL va a funcionar correctamente. Sin embargo, debido a que el Service SID solo vive dentro del equipo donde se instaló la instancia, para asignarle permisos fuera de ese equipo se puede hacer a través del computer account, la cual se llama “DomainName\ComputerName$”.
En resumen los privilegios del servicio de SQL son la unión de lo que tenga el Service SID más lo que tenga la cuenta de servicio.
Si bien, es posible dar el privilegio a ambas cuentas, la cuenta con la que corre el servicio y la cuenta Service SID, ¿Cuál debiéramos usar?, debido a que la que cuenta de servicio puede cambiar, el best practice es asignarle el privilegio al Service SID siempre que sea posible.
Para que el concepto de Service SID quede más claro para quienes no tengan experiencia con ellos, observen las siguientes imágenes. La cuenta “NT Service\MSSQLServer” es el Service SID. El nombre del service SID va a incluir la instancia como parte del nombre como en el ejemplo “NT Service\MSSQL$Denali”. En las imágenes se muestra como agregar el Service SID al privilegio Lock Pages In Memory y a los permisos de un folder.
El uso de Service SID se extendió aún más en SQL Server 2012 y también existen los Managed Service Account, pero esos son tema para otro post.
Referencias