PFE LatinAmerica & ISS

Obtendo Pastas Utilizando o WebService Lists.ASMX do SharePoint 2010

2013-05-24T02:01:53Z

Lendo um post no fórum do MSDN com o título Recuperar ID de pasta na Biblioteca usando Web Services fiquei curioso com o problema reportado, que era conseguir consultar uma pasta do SharePoint passando o nome dela e retornando o ID, utilizando o webservice Lists.ASMX.

Este post tem um exemplo de como implementar esta necessidade.

Leia o resto deste post »

Editando o E-mail da Tarefa Atribuída do Processo de Aprovação do Workflow do SharePoint 2010

2013-05-24T01:56:00Z

O workflow do SharePoint 2010 é muito rico em detalhes que muitas vezes são inexplorados. Um deles é o processo de aprovação, que nos permite customizar a interação do usuário com as tarefas de workflow de uma forma mais rica.

Neste post vou mostrar como editar o e-mail de tarefa atribuída que o workflow envia, mas o conteúdo deste post pode ser utilizado em outras customizações desta atividade.

Leia o resto deste post »

Crear una Topología de Búsqueda en SharePoint 2013

2013-05-10T18:33:00Z

Como ustedes deben recordar en SharePoint 2010 usted podía utilizar la interfaz gráfica para crear o re configurar su topología de Búsqueda empresarial, utilizando la administración de la aplicación de servicio de Búsqueda. En dicha interfaz gráfica usted puede crear, editar o remover cualquiera de los siguientes componentes:

Componente de Administración
Componente de Rastreo (Crawl)
Bases de datos de rastreo
Componente de Consultas (Query)
Particiones del índice.

Y era muy fácil para los administradores utilizar cualquiera de los servidores de la graja y de esta forma configurar la mejor topología de Búsqueda empresarial basados en sus requerimientos de negocio.

Una de las cosas que las personas más me comentan es que utilizar la interfaz gráfica para configurar la topología es realmente fácil, pero si uno comete algún error configurando algún parámetro o tiene algún otro problema en la granja, y al finalizar de configurar la topología empresarial de Búsqueda, y hacer clic en el botón de aplicar los cambios, luego de un buen rato aparece un error y las mayoría de los cambios realizados no se mantienen.

El anterior problema es una buena razón para configurar su topología empresarial de Búsqueda con Power Shell, porque usted tiene toda la flexibilidad de crear y re configurar los componentes, y esto puede ayudar a identificar problemas en su granja o topología antes de que finalice de configurar en su totalidad esta.

También es importante mencionar que algunos administradores de SharePoint le temen administrar SharePoint con Power Shell, por qué piensas que están pasándose al lado de desarrollo y ellos solo quieren ser profesionales de infraestructura. Pero lo que deben saber es que Microsoft está invirtiendo en utilizar Power Shell en la mayoría de sus productos con el fin de ofrecer una sola forma de administrarlos a todos y facilitar y flexibilizar las tareas de infraestructura. Yo espero que este blog ayude a aquellos administradores a quitarse ese concepto de la mente.

Es de saber para las personas que ya están trabajando con SharePoint 2013, que la única vía para configurar la topología de búsqueda es atreves de Power Shell y sus cmdlets disponibles para crear los nuevo y poderosos componentes del nuevo servicio empresarial de Búsqueda de SharePoint 2013.

El propósito de esta entrada de blog es mostrar algunos ejemplos de cómo crear una topología de Búsqueda empresarial en SharePoint 2013, obviamente utilizando Power Shell, pero no solo mencionando que cmdlets utilizar, sino también como podrían automatizar esta labor y así poder repetir estos pasos las veces que sean necesarias y utilizarlos en otras implementaciones de SharePoint 2013, y adicionalmente ayudar a los administradores de SharePoint a perder ese miedo en utilizar Power Shell para administrar SharePoint.

Todos los cmdlets utilizados en esta entrada de blog están basados en el siguiente documento de TechNet:

Manage search components in SharePoint Server 2013

http://technet.microsoft.com/en-us/library/jj862354.aspx

Si usted no ha leído el anterior documento, yo recomiendo que lo haga o lo tome como referencia para la lectura de esta entrada.

A continuación voy a resumir los pasos para crea una nueva topología de Búsqueda en SharePoint 2013, y los cuales son mencionados en el anterior documento:

Iniciar la instancia de servicio de búsqueda: Recuerde que si quiere habilitar un servidor para que sea utilizado en la topología de Búsqueda debe antes iniciar el servicio de búsqueda en dicho servidor.
Obtener la referencia de la topología de búsqueda activa: Existen 2 opciones, la primera es crear una topología de búsqueda vacía, o la segunda es clonar la actual topología de búsqueda y modificarla, en este caso vamos a asumir que vamos a utilizar la actual topología para modificarla.
Clonar la topología de búsqueda activa: Como se mencionó anteriormente vamos a clonar la topología para después modificarla.
Adicionar o remover componentes de búsqueda: Cuando clonamos la topología podemos modificarla adicionándole o removiéndole componentes de tal forma que creemos la nueva deseada.
Activar la nueva topología de búsqueda: Finalmente después de terminar de modificar la topología debemos definir esta como activa.

Como se puede ver existen varios pasos a realizar y por lo tanto varios comandos de Power Shell deben ser ejecutados, por esta razón he creado las siguientes funciones que nos permitirán facilitar la creación de la topología de búsqueda.

GetOrStartSearchServiceInstance

La siguiente función permite identificar si un servidor tiene el servicio de búsqueda indicado, si no es así lo inicia.

function GetOrStartSearchServiceInstance($Server)

{

$startInstance = $false

$serverIns = Get-SPEnterpriseSearchServiceInstance -Identity $Server

if($serverIns -ne $null)

{

if($serverIns.Status -ne "Online")

{

$startInstance = $true

}

else

{

$startInstance = $true

}

if($startInstance)

{

$serverIns = Start-SPEnterpriseSearchServiceInstance -Identity $serverIns

}

return $serverIns

}

En este caso la forma de llamar esta función será:

GetOrStartSearchServiceInstance -Server “<server name>”

Como pudo ver en el documento de TechNet, para adicionar y remover un componente de búsqueda se utilizan los siguientes cmdlets:

Remove-SPEnterpriseSearchComponent: Remueve un componente especifico de la topología de búsqueda.
New-SPEnterpriseSearch<SearchComponent>Component: Donde <SerachComponente> puede ser Admin, AnalyticsProcessing, ContentProcessing, Crawl and QueryProcessing. Y sirven para crear un componente de la topología de búsqueda.

En el caso de New-SPEnterpriseSearch<SearchComponent>Component, si usted entra en detalle a ver que parámetros acepta, es posible para todos los cmdlets proveer 2 parámetros básicos los cuales son la topología y la instancia de servicio (es decir el servidor), es por esto que he creado la siguiente función la cual permite crear cualquiera de los componentes anteriormente mencionados en la cantidad de servidores necesarios.

Set-SPSearchComponents

Esta función necesita los siguientes parámetros:

ServerType: Es una cadena de caracteres que define el tipo de componente a crear, el cual puede ser: Admin, AnalyticsProcessing, ContentProcessing, Crawl or QueryProcessing.
ServersStringArray: Es una cadena de caracteres que contenga el nombre de los servidores donde se desea habilitar el tipo de componente de búsqueda, estos deben estar separados por coma.
Topology: Debe ser una variable de referencia a la topología de búsqueda que se quiera modificar.

function Set-SPSearchComponents($ServerType, $ServersStringArray, $Topology)

{

#Check if is a valid type of search component

$validTypes = ("Admin", "AnalyticsProcessing", "ContentProcessing", "Crawl", "QueryProcessing")

if($validTypes.Contains($ServerType) -ne $true)

{

throw "ServerType is not valid."

}

#Check server by server is need to Remove or Add

$ServerType += "Component"

$currentServers = Get-SPEnterpriseSearchComponent -SearchTopology $Topology | ?{$_.GetType().Name -eq $ServerType}

#Remove components

foreach($component in $currentServers)

{

Remove-SPEnterpriseSearchComponent -Identity $component -SearchTopology $Topology #-Confirm $true

}

#Add Components

foreach($server in $ServersStringArray.Split(","))

{

#Check in search service instance is started, otherwise start it

$serIns = GetOrStartSearchServiceInstance -Server $server

switch($ServerType)

{

"AdminComponent" {New-SPEnterpriseSearchAdminComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"AnalyticsProcessingComponent" {New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"ContentProcessingComponent" {New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"CrawlComponent" {New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"QueryProcessingComponent" {New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

}

#Show in the output the search components of the topology to see the modificatios made on.

Get-SPEnterpriseSearchComponent -SearchTopology $Topology

}

Un ejemplo para invocar esta función podria ser el siguiente:

Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray “server1,server3” -Topology $newTop

Finalmente para dar un gran ejemplo de cómo crear totalmente una topología empresarial de Búsqueda en SharePoint 2013, he creado la siguiente función, la cual hace uso de las anteriores.

New-SPSearchTopology

Para usar esta función se deben proveer los siguientes parámetros:

AdminServers: Los servidores que desea utilizar que provean el componente de Admin. Estos servidores deben estar en una cadena de caracteres separados por coma: “server1,server2,server3”.
AnalyticsServers: Los servidores que desea utilizar que provean el componente de AnalyticsServers. Estos servidores deben estar en una cadena de caracteres separados por coma: “server1,server2,server3”.
ContentServers: Los servidores que desea utilizar que provean el componente de ContentServers. Estos servidores deben estar en una cadena de caracteres separados por coma: “server1,server2,server3”.
CrawlServers: Los servidores que desea utilizar que provean el componente de CrawlServers. Estos servidores deben estar en una cadena de caracteres separados por coma: “server1,server2,server3”.
QueryServers: Los servidores que desea utilizar que provean el componente de QueryServers. Estos servidores deben estar en una cadena de caracteres separados por coma: “server1,server2,server3”.

function New-SPSearchTopology($AdminServers, $AnalyticsServers, $ContentServers, $CrawlServers, $QueryServers)

{

$servers = $AdminServers + "," + $AnalyticsServers + "," + $ContentServers + "," + $CrawlServers + "," + $QueryServers

#Check the existence of the servers

foreach($server in $servers.Split(","))

{

Get-SPServer $server -ErrorAction Stop

}

#Initialize variables

$ssa = Get-SPEnterpriseSearchServiceApplication

#Clone search topology

$activeTop = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active

$newTop = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone –SearchTopology $activeTop

#Admin component

Set-SPSearchComponents -ServerType "Admin" -ServersStringArray $AdminServers -Topology $newTop

#Analytics servers

Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Content

Set-SPSearchComponents -ServerType "ContentProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Crawl

Set-SPSearchComponents -ServerType "Crawl" -ServersStringArray $AnalyticsServers -Topology $newTop

#Query

Set-SPSearchComponents -ServerType "QueryProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Active Topology

Set-SPEnterpriseSearchTopology -Identity $newTop

}

Un ejemplo para invocar esta función podria ser el siguiente:

New-SPSearchTopology –AdminServers “server1,server2” –AnalyticsServers “server1,server3” –ContentServers “server2,server4” –CrawlServers “server5,server6” –QueryServers “server7,server8,server9”

Espero que esta entrada haya sido de ayuda para crear su nueva topología empresarial de Búsqueda en SharePoint 2013, y recuerde que no todas las consideraciones acerca del servicio empresarial de Búsqueda de SharePoint 2013 han sido tomadas en cuenta en este artículo, en el futuro espero escribirles acerca de:

Como detener el servicio de búsqueda en los servidores no requeridos.
Mover la ubicación de los archivos de índice.
Particiones del índice.
Bases de datos de búsqueda.

Create a Search Topology in SharePoint 2013

2013-05-10T15:28:00Z

As you may remember in SharePoint 2010 you had a specific user interface to create and reconfigure your enterprise Search topology, in the Search Service applications management. There you can create, edit and remove the following components:

Admin component
Crawl components
Crawl databases
Query components
Partitions

And it was very easy by the administrator to use any server in their farm to configure the best enterprise Search topology for their business requirements.

One thing than many people said to me was that the configuration was very easy with the UI, but if you put something wrong or your farm have any issue, when you finished to reconfigure your enterprise search topology, and you click in the button to apply all the changes, it takes a while and gives you an error and also you lose the majority of the changes that you made before.

The above problem was a good reason to configure your enterprise search topology with Power Shell, because you have the flexibility to create and reconfigure the components one by one, it help you to identify issues in your farm regarding the search service before finish to define your enterprise search topology.

Also some Share Points administrators have afraid to manage SharePoint with Power Shell, because are thinking that are writing scripts so are developing things, and they may be don’t want to be a developers, only IT infrastructure guys. But you must to know that the reason that Microsoft are integrating Power Shell in all our products is to try to standardize the way that you can manage the different services. I hope this blog could help to those SharePoint administrators that have this concept in mind.

Now, for the people that are working with SharePoint 2013, knows that the only way to create or reconfigure your enterprise Search Topology is using the Power Shell cmdlets created for the new and powerful components of the SharePoint 2013 Enterprise Search Service Application.

The propose of this blog entry is to show you some examples to create an enterprise Search topology in SharePoint 2013, also with Power Shell, but not only to tell you the specific cmdlets that you must or can use to do this job, my objective is to try to automatize this work creating scripts that you can use in your different implementations of SharePoint 2013, also this can help the SharePoint administrators to lose their afraid when are using Power Shell to manage SharePoint.

All the cmdlets that I use in this entry are based in the following TechNet document:

Manage search components in SharePoint Server 2013

http://technet.microsoft.com/en-us/library/jj862354.aspx

If you didn’t read the above document, I recommend to you to do it or take as a reference for the cmdlets that you are going to see here.

I’m going to start to summarize the basics steps that you must to do when you want to create a new Enterprise search topology:

Start the search server instance: Remember that you must to start the server instance in all servers that you want to use for a specific service application, in this case to create a new Search topology you must to start the service instance in the servers than you want to use in your topology.
Retrieve the active Search topology: You have 2 options, first to create a new empty search topology or second to clone the active topology and modify them, in this case I assuming that we are creating a Search topology using some of the same components that the current topology have, so for this reason we are going to clone the active topology instead to create a new one, to do this you must to retrieve the current active Search topology.
Clone the active Search topology: As I explained in the above step, we are going to clone the active Search topology.
Add or remove search components: When we have a cloned Search topology we can remove or add components without affecting the active Search topology. In this steps we are going to redistribute and use all the servers we defined in the first step.
Active the new Search topology: Finally we need to set the modified Search topology as the active topology to begin to work whit it.

As you can see there are some steps that you must to do and in some cases you must to repeat them, for this reason I created the following power shell functions to help to create our Search topology.

GetOrStartSearchServiceInstance

The following function help us to check if the search service instance is started in a specific sever and retrieve the reference to it, or start the service instances in the case that is wasn’t started.

function GetOrStartSearchServiceInstance($Server)

{

$startInstance = $false

$serverIns = Get-SPEnterpriseSearchServiceInstance -Identity $Server

if($serverIns -ne $null)

{

if($serverIns.Status -ne "Online")

{

$startInstance = $true

}

else

{

$startInstance = $true

}

if($startInstance)

{

$serverIns = Start-SPEnterpriseSearchServiceInstance -Identity $serverIns

}

return $serverIns

}

In this case you provide to the function a server name and the function retrieve a search service instance, you must to call it in the following way:

GetOrStartSearchServiceInstance -Server “<server name>”

As you can saw in the TechNet document, to add and remove the search component we use the following functions:

Remove-SPEnterpriseSearchComponent: To remove a specific Search topology component.
New-SPEnterpriseSearch<SearchComponent>Component: Where <SearchComponent> could be Admin, AnalyticsProcessing, ContentProcessing, Crawl and QueryProcessing. To create a new Search topology component.

In the case of New-SPEnterpriseSearch<SearchComponent>Component, you can dig in deep and see that you can use the same basic parameters: the Search topology and the search service instance, for that reason I created the following function to help create and remove the specific components on a the specific servers.

Set-SPSearchComponents

This functions needs the following parameters:

ServerType: Is a string that define the component to add or remove, can be: Admin, AnalyticsProcessing, ContentProcessing, Crawl or QueryProcessing.
ServersStringArray: The servers that you want to use to host the specific search component. This servers must be separated by coma, for example: “server1,server2,server3”.
Topology: The reference to the Search topology that you want to modify to add or remove the componets.

function Set-SPSearchComponents($ServerType, $ServersStringArray, $Topology)

{

#Check if is a valid type of search component

$validTypes = ("Admin", "AnalyticsProcessing", "ContentProcessing", "Crawl", "QueryProcessing")

if($validTypes.Contains($ServerType) -ne $true)

{

throw "ServerType is not valid."

}

#Check server by server is need to Remove or Add

$ServerType += "Component"

$currentServers = Get-SPEnterpriseSearchComponent -SearchTopology $Topology | ?{$_.GetType().Name -eq $ServerType}

#Remove components

foreach($component in $currentServers)

{

Remove-SPEnterpriseSearchComponent -Identity $component -SearchTopology $Topology #-Confirm $true

}

#Add Components

foreach($server in $ServersStringArray.Split(","))

{

#Check in search service instance is started, otherwise start it

$serIns = GetOrStartSearchServiceInstance -Server $server

switch($ServerType)

{

"AdminComponent" {New-SPEnterpriseSearchAdminComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"AnalyticsProcessingComponent" {New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"ContentProcessingComponent" {New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"CrawlComponent" {New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

"QueryProcessingComponent" {New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}

}

#Show in the output the search components of the topology to see the modificatios made on.

Get-SPEnterpriseSearchComponent -SearchTopology $Topology

}

An example to use this function could be:

Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray “server1,server3” -Topology $newTop

Finally to give you a mainly example to create a SharePoint 2013 Enterprise Search Topology, I written the following function using the functions mentioned above.

New-SPSearchTopology

To use this function must to pass the following parameters:

AdminServers: The servers that you want to use to host the Admin search component. This servers must be separated by coma, for example: “server1,server2,server3”.
AnalyticsServers: The servers that you want to use to host the Analytics Processing search component. This servers must be separated by coma, for example: “server1,server2,server3”.
ContentServers: The servers that you want to use to host the Content Processing search component. This servers must be separated by coma, for example: “server1,server2,server3”.
CrawlServers: The servers that you want to use to host the Crawl search component. This servers must be separated by coma, for example: “server1,server2,server3”.
QueryServers: The servers that you want to use to host the Query search component. This servers must be separated by coma, for example: “server1,server2,server3”.

function New-SPSearchTopology($AdminServers, $AnalyticsServers, $ContentServers, $CrawlServers, $QueryServers)

{

$servers = $AdminServers + "," + $AnalyticsServers + "," + $ContentServers + "," + $CrawlServers + "," + $QueryServers

#Check the existence of the servers

foreach($server in $servers.Split(","))

{

Get-SPServer $server -ErrorAction Stop

}

#Initialize variables

$ssa = Get-SPEnterpriseSearchServiceApplication

#Clone search topology

$activeTop = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active

$newTop = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone –SearchTopology $activeTop

#Admin component

Set-SPSearchComponents -ServerType "Admin" -ServersStringArray $AdminServers -Topology $newTop

#Analytics servers

Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Content

Set-SPSearchComponents -ServerType "ContentProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Crawl

Set-SPSearchComponents -ServerType "Crawl" -ServersStringArray $AnalyticsServers -Topology $newTop

#Query

Set-SPSearchComponents -ServerType "QueryProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop

#Active Topology

Set-SPEnterpriseSearchTopology -Identity $newTop

}

An example to use this function could be:

I hope this post could help you to create your new SharePoint 2013 Enterprise Search Topology, and remember that not all the Enterprise Search considerations are taken on this scripts, in the future I going to write about how to change the following characteristics:

Stop the search service instance.
Move the index location.
Move the search component.
Index partitions.
Search databases.

Windows Aware updating and SQL Server 2012 (Part II) – Step by Step

2013-04-11T00:46:00Z

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:

\\WIN-0M99J4ILA2E\UpdatesDemo\Root5

DefaultHotfixConfig.xml

\<nodo 2 name>

\SQL2012SP1

\<SQLServer2012SP1Package>.exe

\<nodo 4 name>

\SQL2012SP1

\<SQLServer2012SP1Package>.exe

As described on the first post, we start the Cluster-Aware updating tool.

<root>

…

</DefaultRules>

<Template path="$update$" parameters="/ACTION=PATCH /allinstances

/QUIET /IAcceptSQLServerLicenseTerms"/>

</Success>

<Success_RebootRequired>

</Success_RebootRequired>

</NotApplicable>

</ AlreadyInstalled >

</ExitConditions>

</Folder>

</FolderRules>

</root>

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:

Max execution time in minutes (StopAfter), after this all the update process is stopped.
Warnning time in minutes (WarmAfter), after this a warning messages is generated, this can be used, for example, to warm that the finalization of the maintainance windows is near.
Order on which the nodes have to be updated (NodeOrder).
The plug-in to use (CaaPluginName), on this case Microsoft.HotfixPlugin
Additional parameters for the plug-in Microsoft.HotfixPlugin.
Other values, that can be consulted in http://technet.microsoft.com/en-us/library/jj134224.aspx

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:

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

Windows Aware updating y SQL Server 2012 (Parte II) – Paso a Paso

2013-04-11T00:29:00Z

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

DefaultHotfixConfig.xml

\<nodo 2 name>

\SQL2012SP1

\<SQLServer2012SP1Package>.exe

\<nodo 4 name>

\SQL2012SP1

\<SQLServer2012SP1Package>.exe

Así mismo, el archivo de configuración le agregué la siguiente sección en rojo.

<root>

…

</DefaultRules>

<Template path="$update$" parameters="/ACTION=PATCH /allinstances

/QUIET /IAcceptSQLServerLicenseTerms"/>

</Success>

<Success_RebootRequired>

</Success_RebootRequired>

</NotApplicable>

</ AlreadyInstalled >

</ExitConditions>

</Folder>

</FolderRules>

</root>

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.

Hacemos click en Next.

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

Hacemos click en Next.

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.

Hacemos click en Next.

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

Windows Aware Updating and SQL Server 2012 (Part I) – Introduction to Windows Aware Updating

2013-04-10T05:14:00Z

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:

Puts the first node on maintenance mode
Move the roles (Previously know as applications and services or Groups) from the node
Install the updates
Restart the server if necessary
Puts the node out of the maintenance mode
Move to the update node the roles previously on execution at the beginning of the process
Repeats the steps on all the remaining nodes, un a sequential mode

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:

Microsoft.WindowsUpdatePlugin

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

Microsoft.HotfixPlugin

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.

\\<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

Where:

The folder CAUHotfix_All will contain all the updates that fill be installed on all nodes of the cluster
The folder <node 1 name> will contain all that updates to install on that specific node with that name, and this will be the same process for the other nodes <node X name>
If the folder CAUHotfix_All doesn’t exist only the specific updates for each node will be installed.
If the folder for each specific node doesn’t exist, only the updates on CAUHotfix_all will be installed, if this folder exist

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:

\\<networkshare>\hotfixroot

DefaultHotfixConfig.xml

        \CAUHotfix_All

               \SQL2012SP1

                       \<SQLServer2012SP1Package>.exe

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:

\\<networkshare>\hotfixroot

DefaultHotfixConfig.xml

        \<nodo 2 name>

               \SQL2012SP1

                       \<SQLServer2012SP1Package>.exe

\<nodo 4 name>

               \SQL2012SP1

                       \<SQLServer2012SP1Package>.exe

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.

<root>

…

</DefaultRules>

<Template path="$update$" parameters="/ACTION=PATCH <INSTANCIA A ACTUALIZAR>

/QUIET /IAcceptSQLServerLicenseTerms"/>

</Success>

<Success_RebootRequired>

</Success_RebootRequired>

</NotApplicable>

</ AlreadyInstalled >

</ExitConditions>

</Folder>

</FolderRules>

</root>

Where <INSTANCIA A ACTUALIZAR> can:

Specify the name of the instance in the form /INSTANCENAME=Inst1 to update the SQL Instance of name Inst1.
/allinstances to update all the instances install on the node.

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:

Success, output code 0
Success_RebootRequired, output code 3010
NotApplicable, output code -2068578302, when the specify instance doesn’t exist on the node.
AlreadyInstalled, output code -2068643838, when the update is already installed on the specified Instance.

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:

\\WIN-0M99J4ILA2E\UpdatesDemo\Root3

DefaultHotfixConfig.xml

        \CAUHotfix_All

               \windows8-RT-KB2792100-x64.msu

\Win20121>

               \windows8-RT-KB2737084-x64.msu

\Win20122

               \windows8-RT-KB2737084-x64.msu

\Win20123

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.

Windows Aware updating y SQL Server 2012 (Parte I) – Introducción a Windows Aware Updating

2013-04-10T05:09:20Z

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:

Coloca el primer nodo en modo de mantenimiento
Mueve los roles (anteriormente llamado “applications and services”) del nodo
Instala las actualizaciones
Reinicia el nodo si es necesario
Saca al nodo del modo de mantenimiento
Mueve al nodo actualizado los roles que estaban en ejecución en dicho nodo al inicio del proceso.
Repite el proceso en los nodos restantes, uno por uno de forma secuencial.

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:

El directorio CAUHotfix_All contendrá las actualizaciones que serán instaladas en todos los nodos del clúster
El directorio <nodo 1 name> contendrá las actualizaciones a instalar en el nodo con dicho nombre, y así sucesivamente hasta el nodo <nodo x name>
Si no existe la carpeta CAUHotfix_All sólo se instalarán las actualizaciones especificadas para cada nodo.
Si no existe una carpeta con el nombre de un nodo sólo se instalarán las actualizaciones en CAUHotfix_All, si es que es este último directorio existe.

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:

\\<networkshare>\hotfixroot

DefaultHotfixConfig.xml

        \CAUHotfix_All

               \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

\\<networkshare>\hotfixroot

DefaultHotfixConfig.xml

        \<nodo 2 name>

               \SQL2012SP1

                       \<SQLServer2012SP1Package>.exe

\<nodo 4 name>

               \SQL2012SP1

                       \<SQLServer2012SP1Package>.exe

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>

<Template path="$update$" parameters="/ACTION=PATCH <INSTANCIA A ACTUALIZAR>

/QUIET /IAcceptSQLServerLicenseTerms"/>

</Success>

<Success_RebootRequired>

</Success_RebootRequired>

</NotApplicable>

</ AlreadyInstalled >

</ExitConditions>

</Folder>

</FolderRules>

</root>

Donde <INSTANCIA A ACTUALIZAR> puede:

Especificar el nombre la instancia a actualizar en la forma /INSTANCENAME=Inst1 para actualizar la instancia de nombre Inst1.
/allinstances para actualizar todas las instancias instaladas en el nodo.

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:

Success, código de salida 0
Success_RebootRequired, código de salida 3010
NotApplicable, código de salida -2068578302, cuando la instancia especificada no existe en el nodo.
AlreadyInstalled, código de salida 2068643838, cuando la actualización ya estaba instalada en la instancia indicada.

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

DefaultHotfixConfig.xml

        \CAUHotfix_All

               \windows8-RT-KB2792100-x64.msu

\Win20121>

               \windows8-RT-KB2737084-x64.msu

\Win20122

               \windows8-RT-KB2737084-x64.msu

\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.

¿Privileges on the Service SID or on the SQL Service Account?

2013-04-10T04:07:18Z

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.

References

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

¿Privilegios al Service SID o a la cuenta de Service?

2013-04-10T04:01:03Z

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

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