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>
As described on the first post, we start the Cluster-Aware updating tool.
<root>
<DefaultRules>
…
</DefaultRules>
<FolderRules>
<Folder name="SQL2012SP1">
<Template path="$update$" parameters="/ACTION=PATCH /allinstances
/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>
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:
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
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:
Así mismo, el archivo de configuración le agregué la siguiente sección en rojo.
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:
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:
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
\CAUHotfix_All
Update1.msu
Update2.msi
Update3.msp
\<nodo 1 name>
Update4.exe
Update 5
….
\<nodo x name>
UpdateY.exe
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.
<Template path="$update$" parameters="/ACTION=PATCH <INSTANCIA A ACTUALIZAR>
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:
\\WIN-0M99J4ILA2E\UpdatesDemo\Root3
\windows8-RT-KB2792100-x64.msu
\Win20121>
\windows8-RT-KB2737084-x64.msu
\Win20122
\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 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:
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.
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
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:
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
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.
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:
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.
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
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
Hola SharePointeros
Esta ves estuve trabajando con un cliente en Jamaica y me encontré con un problema instalado actualizaciones en una granja de SharePoint 2010, básicamente estábamos instalando un CU y después de instalar los binarios ejecutamos el Asistente de Configuración de SharePoint como mandan los cánones y nos arrojó una pantalla de error y no nos permitió seguir:
En primera instancia tratamos de re-instalar el CU pero nos arrojó el clásico mensaje diciendo que el CU ya estaba instalado.
Entonces pensé, reiniciemos y eso seguro lo corrige, pero sorpresa no fue así.
Tuve que ir a mirar en la base de datos de conocimientos y encontré que los parámetros Installcheck -noInstallcheck del psconfig me podría ayudar, así que abrí una sesión de PowerShell como administrador y escribí: psconfig -cmd installcheck -noinstallcheck.
Magia, en esta ocasión el asistente de configuración de SharePoint inició y completó sin errores.
Espero que les sea útil!
Hello community,
This time I was working on a customer in Jamaica and faced an issue installing updates in a SharePoint 2010 farm, basically we were installing a CU and when we try to start the PsconfigGUI we got an error screen preventing us to update SharePoint properly:
At first sight I though reinstalling the hotfix is an option but I got a message saying, the fix is already installed, so that meant binaries were already there.
Ok a reboot will fix it like in the most cases, but this time didn't work.
Then looking into the KB I found that Installcheck -noInstallcheck psconfig parameters could help, so I ran PowerShell and typed psconfig -cmd installcheck -noinstallcheck.
Magic, this time SharePoint Configuration Wizard started and completed successfully.
Hope this can help you in some way!
Hola!!
Una de las nuevas características de SQL Server 2012 son las Contained Databases , gracias a esta característica podemos parcialmente aislar algunos objetos que por su naturaleza residen en la instancia de bases de datos como lo son los “logins”, si bien en términos de migración y consolidación esta es una gran ventaja, permítanme comentarles algunos aspectos a considerar a nivel de seguridad.
Se debe tener en consideración que si algún usuario en la contained database tiene el permiso de ALTER ANY USER, tendrá la capacidad de modificar los permisos de los usuarios y dar permisos de conexión a cualquier persona sin conocimiento del Administrador de SQL, usuarios que pertenezca a los roles de bases de datos “db_owner” y “security_admin” obtendrán automáticamente dicho permiso, dando como resultado un hueco de seguridad, por esto tenemos que ser muy cuidadosos con dar estos permisos a usuarios no administradores de SQL.
Otro escenario que debemos considerar es que cuando nos conectamos a un contained database y en esa misma instancia se encuentra alguna base de datos con la cuenta “guest” habilitada, una vez que el usuario se ha podido conectar a la contained database, también tendrá la capacidad de acceder a esa base de datos, esto en conjunto que el escenario anterior donde una usuario con el permiso de ALTER ANY USER pude dar acceso a cualquier persona para conectarse al servidor, se convierta en un gran problema de seguridad. Es por ello que debemos minimizar el uso de este permiso y constantemente auditar el acceso y uso del permiso ALTER ANY USER en las bases de datos.
Ahora platiquemos de otro escenario, ¿Que sucedería si creamos un usuario en nuestra base de datos de contenido, con el mismo nombre de un login existente en nuestra instancia? Si accedemos a la base por medio de este login y a su vez al momento de conectarnos especificamos la Contained Database como catálogo inicial, lo que obtendríamos sería una negación del servicio para este login, ya que el contexto de seguridad evalúa usuario y contraseña sobre la Contained Database en lugar de el entrono de logins de SQL.
Para finalizar y tomando en cuenta mis dos recomendaciones anteriores, les expongo lo siguiente. ¿Cual es el impacto de darle “attach” a una base de datos de contenido en una nueva instancia? , al attachar una Contained Database estaremos abriendo una puerta de conexión a los usuarios con password de la Contained Database attchada. ¿Cómo podemos evitar el riesgo de acceso a usuarios no autorizados a esta instancia? usando la opción de RESTRICTED_USER, ya que esta previene la autenticación para usuarios con passwords de la Contained databases.
Todas estas consideraciones son fácilmente manejables teniendo una adecuada delegación de control de acceso y mejores prácticas de seguridad.
Espero les sean de utilidad estos puntos y para mayor información de este y tros escenarios pueden consultar en TechNet:
http://technet.microsoft.com/en-us/library/ff929055
Bajen todos los servicios de SQL, incluyendo el SQL Engine, Analisys Services, Reporting Services, Integration Services, Full Text Search o cualquier otro que pueda hacer una sesión a SQL. También es bueno deshabilitar el TCP/IP protocol en caso que alguna aplicación se esté conectando a SQL server remotamente y haga sesión.
Ahora agreguen el switch –m (se debe agregar “;-m” sin espacios, ni las comillas) en los parámetros de inicio de SQL, esto hará iniciar el Servicio de SQL Server en modo single-user y solo podrá accederlo un solo usuario (es por esto que deben para cualquier servicio que haga sesión a SQL) y además debe tener privilegios de administrador en la maquina Windows
Luego de esto deberán ingresar a SQL usando sqlcmd en modo trusted podrán entrar a SQL Server, recuerden que deben estar logueados con una cuenta que sea miembro de los Administradores locales del Servidor
sqlcmd –E –S NombreServidor\NombreInstancia
Luego de entrar a sqlcmd podrá ejecutar cualquier comando que desee, ya que entrar con el contexto de un sysadmin, para colocar a alguno login como sysadmin podrán usar el stored procedures sp_addsrvrolemember: EXEC sp_addsrvrolemember 'NombreLogin', ‘sysadmin’; GO
Ya con esto tendrá un Login con privilegios de sysadmin, ahora ya puede bajar el servicio de SQL, remover el swith –m (esto remueve el modo single-user) e iniciar SQL Server, podrá usar el login al que se le otorgo los derechos de sysadmin y hacer los cambios que requieran.
Some days ago I visit a client on Puerto Rico that was having some performance problems on a transactional application and after resolving the issue the client express interested on learning about Column Store Index, this kind of indexes is a new functionality on SQL Server 2012, as we will see his kind of index work great on some scenarios but not all. The SQL Server versions that support this functionality is SQL Server 2012 Enterprise, Evaluation and Developer Edition.
Traditional Indexes are stored by rows instead of by columns. This kind of storage is extremely efficient when you require to access the data on a row or a small amount of rows. However if you request all the rows or a really big range, this approach becomes not as effective.
The Store Column Indexes allow you to present a big range of rows by storing the data organizing it by columns. When you create the Column Store Index you usually include all the columns on a table, this will assure that all columns will
In a Column Store Index, instead of storing all column of a specific row, each column is store a part from each other with all the rows from that column. The benefit of this type of index is that only the columns and rows needed to reply a request will be read. Usually a Dataware House scenarios only a 15% of the columns of an index to obtain the result of a request.
There are two principal restriction to consider when working with Column Store Indexes. First a Column Store Index is read-only, once created you can modify the base table, this means operations like INSERT, UPDATE and DELETE are not allowed, for this reason is a good practice to use table partitioning to reduce that amount of data that need to be inserted on a Column Index Store and allow an easier reconstruction of an index when inserting new values to the table, because of this restriction the Column Index Store are more suited for scenarios that data don’t change frequently, like in Dataware House. The second restriction is that there can be only one Column Index Store per table, this limitation is not a real problem because you usually include ALL the columns of a table on the Column Index Store.
Another limitation is related to the creation time of the Column Index Store in comparison with a non-clustered Index, the average time could be from 2 to 3 times longer than the non-clustered index. However, despite the restrictions mentioned earlier, the Column Index Store can provide a great value on performance benefits, and also the compression you get from similar data on the same page.
The following data types can NOT be used on the Column Index Store: binary, varbinary, ntext, text, image, nvarchar(max), varchar(max), uniqueidentifier, rowversion, sql_variant, decimal (greater than 18 digits), datetimeoffset, xml, and data types based on CLR. Also the number of columns are restricted to 1024. Finally the index cannot be UNIQUE or CLUSTERED, contain Included Columns or have a defined order (Ascending or Descending)
The Column Index Store use their own compression technology, and that why they can be combined with the page and row compression data options. They can’t also be used on replication schemas, change tracking, change data capture or filestream. This technologies works on a Read/Write scenario and that why are not compatible with the read-only nature of the Column Index Store.
How to create a Column Index Store:
The creation of the Column Index Store can be done through T-SQL or SQL Server Management Studio
T-SQL
CREATE NONCLUSTERED COLUMNSTORE INDEX <ColumnStoreIndexName> ON <Table> (col1, col2, col3);
<ColumnStoreIndexName> ON
<Table> (col1, col2, col3);
-- Create the columnstore index
CREATE NONCLUSTERED COLUMNSTORE INDEX [csindx_FactResellerSalesPtnd]
ON [FactResellerSalesPtnd]
(
[ProductKey], [OrderDateKey], [DueDateKey], [ShipDateKey], [CustomerKey], [EmployeeKey],
[PromotionKey], [CurrencyKey], [SalesTerritoryKey], [SalesOrderNumber], [SalesOrderLineNumber],
[RevisionNumber], [OrderQuantity], [UnitPrice], [ExtendedAmount], [UnitPriceDiscountPct],
[DiscountAmount], [ProductStandardCost], [TotalProductCost], [SalesAmount], [TaxAmt], [Freight],
[CarrierTrackingNumber], [CustomerPONumber], [OrderDate], [DueDate], [ShipDate]
);
Management Studio
Column Index Store and Partitioned Tables
Let’s create a partitioned table named FactResellerSalesPtnd using the following code from MSDN
Step #1: Create the table FactResellerSalesPtnd (A Partittioned versión of: FactResellerSales)
USE AdventureWorksDW2012;
GO
CREATE PARTITION FUNCTION [ByOrderDateMonthPF](int) AS RANGE RIGHT
FOR VALUES (
20050701, 20050801, 20050901, 20051001, 20051101, 20051201,
20060101, 20060201, 20060301, 20060401, 20060501, 20060601,
20060701, 20060801, 20060901, 20061001, 20061101, 20061201,
20070101, 20070201, 20070301, 20070401, 20070501, 20070601,
20070701, 20070801, 20070901, 20071001, 20071101, 20071201,
20080101, 20080201, 20080301, 20080401, 20080501, 20080601,
20080701, 20080801, 20080901, 20081001, 20081101, 20081201
)
CREATE PARTITION SCHEME [ByOrderDateMonthRange]
AS PARTITION [ByOrderDateMonthPF]
ALL TO ([PRIMARY])
-- Create a partitioned version of the FactResellerSales table
CREATE TABLE [dbo].[FactResellerSalesPtnd](
[ProductKey] [int] NOT NULL,
[OrderDateKey] [int] NOT NULL,
[DueDateKey] [int] NOT NULL,
[ShipDateKey] [int] NOT NULL,
[CustomerKey] [int] NOT NULL,
[EmployeeKey] [int] NOT NULL,
[PromotionKey] [int] NOT NULL,
[CurrencyKey] [int] NOT NULL,
[SalesTerritoryKey] [int] NOT NULL,
[SalesOrderNumber] [nvarchar](20) NOT NULL,
[SalesOrderLineNumber] [tinyint] NOT NULL,
[RevisionNumber] [tinyint] NULL,
[OrderQuantity] [smallint] NULL,
[UnitPrice] [money] NULL,
[ExtendedAmount] [money] NULL,
[UnitPriceDiscountPct] [float] NULL,
[DiscountAmount] [float] NULL,
[ProductStandardCost] [money] NULL,
[TotalProductCost] [money] NULL,
[SalesAmount] [money] NULL,
[TaxAmt] [money] NULL,
[Freight] [money] NULL,
[CarrierTrackingNumber] [nvarchar](25) NULL,
[CustomerPONumber] [nvarchar](25) NULL,
OrderDate [datetime] NULL,
DueDate [datetime] NULL,
ShipDate [datetime] NULL
) ON ByOrderDateMonthRange(OrderDateKey);
-- Using simple or bulk logged recovery mode, and then the TABLOCK
-- hint on the target table of the INSERT…SELECT is a best practice
-- because it causes minimal logging and is therefore much faster.
ALTER DATABASE AdventureWorksDW2012 SET RECOVERY SIMPLE;
-- Copy the data from the FactResellerSales into the new table
INSERT INTO dbo.FactResellerSalesPtnd WITH(TABLOCK)
SELECT * FROM dbo.FactResellerSales;
[ProductKey],
[OrderDateKey],
[DueDateKey],
[ShipDateKey],
[CustomerKey],
[EmployeeKey],
[PromotionKey],
[CurrencyKey],
[SalesTerritoryKey],
[SalesOrderNumber],
[SalesOrderLineNumber],
[RevisionNumber],
[OrderQuantity],
[UnitPrice],
[ExtendedAmount],
[UnitPriceDiscountPct],
[DiscountAmount],
[ProductStandardCost],
[TotalProductCost],
[SalesAmount],
[TaxAmt],
[Freight],
[CarrierTrackingNumber],
[CustomerPONumber],
[OrderDate],
[DueDate],
[ShipDate]
Step #2: Let’s execute an query and confirm if the Column Index Store was used
SELECT SalesTerritoryKey, SUM(ExtendedAmount) AS SalesByTerritory
FROM FactResellerSalesPtnd
GROUP BY SalesTerritoryKey;
Performance Benefits for Column Index Store
Cost
FROM FactResellerSales
-- Índice almacenado por columnas
SELECT SalesTerritoryKey, SUM (ExtendedAmount) AS SalesByTerritory
The relative cost of the Second Query (using a column index store) is 16% in comparison with the relative cost of the First Query (using a regular clústeres index)
Disk I/O
When executing the queries using STATISTICS IO ON (show the information related with the Disk I/O activity for the queries) you see a big improvement on the Second Query
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS IO OFF
(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 2982, physical reads 2, read-ahead reads 2972, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSalesPtnd'. Scan count 1, logical reads 599, physical reads 4, read-ahead reads 235, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Time
When executing the queries using STATISTICS IO ON (show the information in milliseconds related with the analyzing, compile and executing the queries) you see a time reduction on the Second Query
SET STATISTICS TIME ON
SET STATISTICS TIME OFF
SQL Server Execution Times:
CPU time = 46 ms, elapsed time = 109 ms.
CPU time = 32 ms, elapsed time = 85 ms.
Conclusion
Experts agree that the performance improvement when using column index store on a table fluctuate between 10% and 100%. However as mentioned in this article applications that benefit the most are the ones with high read volumes like data warehousing, but not for high write scenarios like OLTP systems. The star and snow flake schemas usually take part on data warehousing and datamarts where the velocity on data extraction is more important that the efficiency on the data manipulation. The column index store can improve this type of scenarios that are ideal for this technology.
Hace unos días visite un cliente en Puerto Rico que tenía problemas de rendimiento en una aplicación transaccional y entre las opciones que quería considerar era el uso de índices almacenados por columnas. Este tipo de índice es una de las nuevas funcionalidades que tiene SQL 2012 pero como veremos a continuación sus características lo hacen idóneo para ciertos escenarios no para todos. Las versiones de SQL 2012 donde está disponible la funcionalidad de índices almacenados por columnas son: SQL Server 2012 Enterprise, Evaluation, y Developer.
Los índices tradicionales son almacenados por filas en vez de columnas. Esta forma de almacenamiento es extremadamente eficiente cuando se requiere acceder una fila o un rango compuesto de un grupo pequeño de filas. Sin embargo cuando se solicitan todas las filas o un rango grande, este método se vuelve ineficiente.
En un índice almacenado por columnas, en vez de almacenar juntas todas las columnas de un registro, cada columna es almacenada de forma separada con todas las demás filas en el índice. El beneficio de este tipo de índice consiste en que solo las columnas y las filas requeridas para contestar una consulta serán leídas. En escenarios de Datawarehouse, a menudo se utiliza menos de un 15% de las columnas de un índice para obtener el resultado de una consulta.
Hay dos restricciones principales a considerar cuando se trabaja con índices almacenados por columnas. En primer lugar un índice almacenado por columna es de solo lectura. Una vez se ha creado, no se pueden realizar modificaciones a los datos en la tabla. Es decir las operaciones: INSERT, UPDATE y DELETE no están permitidas. Por esta razón a menudo se utiliza el particionamiento de tablas para reducir la cantidad de datos que necesitan ser almacenados en un índice almacenado por columnas y para permitir el reconstruir un índice cuando se insertan nuevos datos a la tabla. Debido a esta restricción, los índices almacenados por columnas son idóneos en situaciones donde los datos no cambian con frecuencia como es el caso de los datawarehouse. La segunda restricción limita a uno el número de índices almacenados por columnas que pueden existir en una tabla. Esta restricción no se considera un problema ya que se acostumbra a incluir todas las columnas de la tabla en el índice almacenado por columnas.
Otra limitación está relacionada con el tiempo que toma la creación de un índice en comparación con un índice nonclustered. El tiempo promedio podría ser de dos a tres veces más. Sin embargo, a pesar de las restricciones antes mencionadas, los índices almacenados por columnas pueden proveer un valor significativo en términos de rendimiento si se considera que el índice solo cargará las columnas que sean requeridas por la consulta. Además de la mejora en compresión que se puede obtener por contar con data similar en la misma página.
Los siguientes tipos de datos no pueden ser utilizados en índices almacenados por columnas: binary, varbinary, ntext, text, image, nvarchar(max), varchar(max), uniqueidentifier, rowversion, sql_variant, decimal (mayor de 18 dígitos), datetimeoffset, xml, y tipos basados en CLR. Además el número de columnas está limitado a 1,024. Finalmente por la naturaleza del índice no puede ser UNIQUE, CLUSTERED, contener columnas incluidas o tener definido un orden (ascendente o descendente).
Los índices almacenados por columnas utilizan su propia tecnología de compresión por lo cual no se pueden combinar con la opción de compresión a nivel de fila o página. Tampoco pueden ser utilizados en esquemas de replicación, change tracking o Change data capture, filestream. Estas tecnologías trabajan en escenarios de lectura/escritura lo cual no es compatible con la naturaleza de solo lectura de los índices almacenados por columnas.
Como crear un índice almacenado por columnas
La creación de un índice almacenado por columnas puede ser realizada a través de T-SQL o utilizando SQL Server Management Studio.
Índices almacenados por columnas con tablas particionadas
Crearemos una tabla particionada llamada FactResellerSalesPtnd utilizando el siguiente código de MSDN (http://msdn.microsoft.com/en-us/library/gg492088.aspx).
Paso #1: Crear la tabla FactResellerSalesPtnd (Versión particionada de la tabla: FactResellerSales)
Paso #2: Vamos a correr una consulta y confirmaremos que se utilizó el índice almacenado por columnas.
Beneficios en términos de rendimiento de los índices almacenados por columnas
Costo
El costo relativo de la segunda consulta (utilizando un índice almacenado por columnas) es de 16% en comparación con el costo relativo de la primera consulta que es de 84% y utiliza un índice regular.
Actividad de disco
Al correr las consultas con STATISTICS IO ON (Muestra información relacionada con la cantidad de actividad de disco generada por las instrucciones Transact-SQL) se observa una mejora en rendimiento en la segunda consulta relacionada principalmente con las lecturas lógicas y read-ahead.
Tiempo
Al correr las consultas con STATISTICS TIME ON (Muestra el número de milisegundos necesarios para analizar, compilar y ejecutar cada instrucción) se observa una reducción de tiempo en la segunda consulta relacionada con el tiempo transcurrido y tiempo de CPU.
Conclusión
Expertos coinciden que la mejora en rendimiento obtenida al utilizar índices almacenados en columnas fluctúa entre un 10% a un 100%. Sin embargo como hemos mencionado en este artículo las aplicaciones que se benefician más son las relacionadas con altos volúmenes de lectura y no en sistemas altamente transaccionales. Los esquemas de estrella y copo de nieve usualmente forman parte de los datawarehouse y datamarts donde la velocidad de la extracción de los datos es más importante que la eficiencia en la manipulación de los datos. La tecnología de índices almacenados en columnas puede detectar y agilizar las consultas dirigidas a estos esquemas por lo cual son los escenarios típicos idóneos para su aplicación.
Hello Community,
After many time of abscense I'm back to continue providing you with more information that can be valuable or useful, this time for SharePoint 2010 beginners that would like to know the new OOB Backup/Restore features and how to schedule backups using Windows scheduled tasks.
First we need to know and understand SharePoint Central Administration site options
As we can see on the image above we have 2 categories "Farm Backup and Restore" & "Granular Backup".
Here we have granular backup options now. SharePoint 2010 includes export/import options that was only available through stsadm in MOSS 2007, in order SharePoint administrator can execute a backup of a site, list or document library without PowerShell:
3. Finally a shortcut to review the status of the granular backup
Using Windows Scheduled Tasks
Having scheduled backups are fundamental for SharePoint adminsitrators, most of the times this taks are executed overnight, first of all, to grant data integrity and get the last updated data ,and then to minimize performance impact because of the heavy I/O on disks
In this section you will find some examples with the correct syntaxis for PowerShell scripts, but first we need to build a .BAT file like this one
@echo on
SET SOURCE_SITE=<URL>SET DEST=<Path>
powershell -command <PS1 File> %SOURCE_SITE% %DEST%echo “Backup completed successfully at %DEST%” on %DATE% %TIME% >> <LogFileCustom>
<URL> Will be the Site Collection to be backed up
<Path> Path for the backup file. Drive:\backupintranet\backupintranet.bak
<LogFileCustom> Log file(Optional) Drive:\backupintranet\backupLog.txt
<PS1 File> PowerShell script location Drive:\backupintranet\Bckptl.ps1
But, what's inside PS1 file?, we have many options. Before we need to understand that SharePoint Central Administration site only allows us to make backups of the entire farm or at web application level only, but not for a specific site collection or site, we need to highlight that SharePoint administrator will be able to restore SharePoint objects as fast as possible, rather than restoring the entire content inside the content database that can be 200 GB of size and taking hours to be restored.
Well PS1 file MUST start with the following line in order to start PowerShell
Add-PsSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
What we have for backups:
Site Collections:
Backup-SPSite -Identity <Site collection name> -Path <backup file> [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose] (http://technet.microsoft.com/en-us/library/ee748617.aspx)
Sites, Lists or Document Libraries
Export-SPWeb -Identity <Site URL> -Path <Path and file name> [-ItemUrl <URL of site, list, or library>] [-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression] [-GradualDelete] [-Verbose] (http://technet.microsoft.com/en-us/library/ee428301.aspx)
Farm configuration
Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> -DatabaseCredentials <WindowsPowerShellCredentialObject> [-Verbose] (http://technet.microsoft.com/en-us/library/ee428320.aspx)
This last option is a new feature in SharePoint 2010 that allows SharePoint administrator to backup farm CONFIGURATION located in Configuration database, the objective is to restore some configuration settings in a different Configuration database like a DRP SharePoint farm (Disaster Recovery Plan)
If you want to know more backup/restore options and some PowerShell sample scripts for SharePoint 2010 you can check the following technet article:
http://technet.microsoft.com/en-us/library/ee428315.aspx
See you soon...!!!
Hola comunidad,
Después de mucho tiempo regresamos a continuar con información que puede ser valiosa para ustedes, en esta ocasión para los principiantes de SharePoint 2010 que desean saber las opciones de Respaldo y Restauración que SharePoint 2010 tiene out-of-the-box y como usar las tareas programadas de Windows para calendarizar respaldos.
Primero entendamos las opciones que tenemos desde la Administración Central de SharePoint
Como podemos observar en la imagen anterior tenemos 2 categorias "Respaldo y Restauración de la granja" y "Respaldo Granular".
Después tenemos las opciones para los respaldos granulares. SharePoint 2010 integra estas opciones que solo estaban disponibles a traves de stsadm en la versión anterior, para que el administrador de la granja de SharePoint pueda en un momento dado ejecutar un respaldo de una lista o biblioteca de documentos sin tener que usar PowerShell:
3. Y finalmente un acceso directo a revisar el estado del respaldo granular
Usando las tareas programadas de Windows
La calendarización de los respaldos será siempre una función fundamental pues la mayoría de los administradores de sistemas programa estas actividades durante la noche, en primer lugar por el impacto que puede existir en los datos a respaldar ya sea para mantener la integridad o para tener en el respaldo la mayor actualización de la información y por otro lado para no afectar el desempeño de las aplicaciónes debido al alto I/O que un respaldo conlleva.
Esta sección tiene la intención de proveer de algunos ejemplos con la sintaxis apropiada para que cada administrador de SharePoint calendarice sus respaldos.
Primero es necesario saber que requeriremos de un archivo .bat para la ejecución del respaldo desde PowerShell, por ejemplo:
@echo onSET SOURCE_SITE=<URL>http://intranetSET DEST=<Path>echo “backup Started at” %DATE% %TIME% >> <LogFileCustom>
powershell -command <PS1 File> %SOURCE_SITE% %DEST%echo “Backup completed successfully at %DEST%” on %DATE% %TIME% >> <LogFileCustom>@echo on
<URL> Será la Colección de sitios a respaldar
<Path> La ubicación completa incluyendo el nombre del archivo donde se creará el respaldo. Ej.: Drive:\backupintranet\backupintranet.bak
<LogFileCustom> El archivo de log de los respaldos (Opcional) Ej.: Drive:\backupintranet\backupLog.txt
<PS1 File> La ubicación del script de PowerShell que será ejecutado para el respaldo. Ej.: Drive:\backupintranet\Bckptl.ps1
Ahora bien que deberá incluir el archivo PS1?, bien pues tenemos varias opciones. De inicio debemos de tomar en cuenta que las opciones del sitio de Administración Central de SharePoint nos permite hacer respaldos a nivel de toda la granja o de aplicación web, pero no de una colección de sitios en particular, siendo importante destacar que haciendo esta clase de respaldos el administrador de SharePoint tendrá la capacidad de restaurar información imporntate en menor tiempo que si lo hiciera restaurando toda la base de datos de contenido, pues ésta podría llegar a medir hasta 200 GB, lo que implicarían horas en una restauración.
Bien pues el archivo PS1 deberá iniciar con la siguiente línea que permitirá ejecutar la llamada de PowerShell
Ahora si las opciones para respaldos:
Colecciones de Sitios:
Sitios, Listas o Bibliotecas de documentos
Configuración de la granja
Esta última es una nueva característica que permitirá respaldar cierta configuración almacenada en la base de datos de Configuración de SharePoint, con el objetivo de restaurar dicha configuración en una nueva base de datos de configuración en una nueva granja de SharePoint y reducir el tiempo de creación de una nueva granja, por ejemplo en el caso de granjas para DRP (Disaster Recovery Plan)
Si desean conocer más opciones y ejemplos de scripts de PowerShell para los diferentes objetos de SharePoint 2010 pueden consultar el siguiente contenido:
Hasta la próxima...!!!
A new feature in SQL Server 2012 is the tabular models in Analysis Services, and after facing some issues when I was preparing a demo for a recent event I decided to finish some tests to compare the performance of Tabular Models vs multidimensional models.
First, what it is Analysis Services Tabular Mode. SQL Server includes not only the relation engine but also the analytical engine. Prior to SQL Server 2012, there was only one kind of analytical database in SQL Server (multidimensional database or cubes), now in SQL Server 2012 we have a new kind of analytical database engine, Analysis Services in tabular mode, the objective is similar to the multidimensional database, be able to answer questions about the data as fast as possible, however, the internal architecture and the language used (DAX instead of MDX) are different. Analysis Services in tabular mode holds all the information in memory in columnar storage (instead of the classic row based storage), this significantly improves query performance without requiring indexes or aggregations. For more details about tabular mode you can read the related ppt that you can found in http://blogs.technet.com/b/sql_pfe_latam/archive/2012/06/27/1-176-simposio-latinoamericano-de-sql-server.aspx
In these scenarios, the data used was random and I run this test on a 16GB of RAM Laptop (not a high end Server), however it is useful to illustrate that we need to be careful before choosing one modelo r the other doing the appropriate proof of concepts.
Tabular mode has some advantages over multidimensional but it also has disadvantages.
Some of the advantages of tabular models are:
- They are easier and faster to develop.
- If you already have PowerPivot models in production is very easy to evolve these models to tabular models.
- You can use PowerView on tabular models.
Some disadvantages can be seen in the results of my tests. The scenario consists of a 16.4 GB relational database with data compression containing 100 million rows with less than 10 columns. Here is some data about the size and behavior on both tabular models and multidimensional models on this database.
Característica
Tabular
Multidimensional
Processing time
More than 9 hours
20 minutes
Memory consumption
11 GB
1 GB
Database Size
4.5 GB
8.4 GB
Query 1
88 ms
94 ms
Query 2
334 ms
62 ms
Query 3
5033 ms
920 ms
The previous results don’t mean that you shouldn’t use tabular mode, but should evaluate if it is your best option. Depending on the data, the amount of dimensions, the complexity of measures, etc., the results can change.
Here are the print screens of the previous tests.
The relational database size (no data compression)
Tabular Mode Database size
Multidimensional Database Size
Queries response time in Tabular mode
Queries response time in multidimensional mode
“The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft”
Una nueva característica en SQL Server 2012 son los modelos tabulares de Analysis Services, y después de toparme con algunas sorpresas al preparar una demo para un evento reciente decidí terminar unas pruebas y comparar el performance de los modelos tabulares vs los modelos multidimensionales.
Antes que nada, ¿Qué es Analysis Services Tabular Mode?. SQL Server incluye no solo el motor relacional sino que también incluye un motor analítico. Antes de SQL Server 2012, había solo una clase de base de datos analítica en SQL Server (las bases de datos multidimensional o simplemente cubos). En SQL Server 2012 tenemos una nueva clase de base de datos analítica, Analysis Services en modo tabular, el objetivo es similar a las bases de datos multidimensionales, ser capaz de responder preguntas complejas acerca de la información (queries) tan rápido como sea posible, sin embargo, la arquitectura y lenguaje usados varían. En bases de datos tabulares el lenguaje utilizado es DAX en lugar de MDX y la arquitectura de modo tabular está basada en tener toda la información comprimida en memoria organizada en modo tabular a diferencia de las base de datos multidimensionales que organizan la información en registros y utilizan agregaciones para mejorar el performance de los queries. El modo Tabular no requiere índices ni agregaciones gracias a ésta nueva arquitectura. Para más detalles del modo tabular pueden leer la presentación relacionada con el tema que pueden encontrar en http://blogs.technet.com/b/sql_pfe_latam/archive/2012/06/27/1-176-simposio-latinoamericano-de-sql-server.aspx
En éste escenario, los datos usados son aleatorios y el equipo es un Workstation con 16Gb de RAM (no precisamente un High End Server), sin embargo sirve para ilustrar que hay que tener cuidado antes de escoger tabular mode sin hacer las pruebas de concepto apropiadas.
Tabular mode tiene algunas ventajas sobre modelos multidimensionales pero también tiene algunas desventajas.
Tres de las ventajas más grandes de los modelos tabulares son:
- Son más fáciles y rápidos de crear
- Si ya tienes proyectos en PowerPivot es muy fácil evolucionarlos a TabularMode
- Puedes usar PowerView para consumir éstos modelos
Dentro de las desventajas se encuentran los resultados de las pruebas que hice y que muestro a continuación.
El escenario consiste de una base de datos de 16.4 GB con una tabla de hechos con 100 millones de registros que tiene menos de 10 columnas. El comparativo al cargar ésta información tanto a Tabular Mode como a multidimensional se muestra a continuación:
Procesamiento
Más de 9 horas
20 minutos
Consumo de memoria
Tamaño aprox. BD
Los resultados anteriores no significa que no deben usar Tabular Mode, pero si que deben hacer una evaluación antes de tomar una decisión, dependiendo del conjunto de datos, de la cantidad de dimensiones, de la complejidad de las métricas, etc, los resultados van a beneficiar más a un modelo que al otro.
Aquí muestro los print screens que reflejan los datos anteriores.
Tamaño base de datos relacional (no se usó compresión)
Tamaño de base de datos modo Tabular
Tamaño de Base de datos en modo multidimensional
Queries en modo tabular
Queries en modo multidimensional
“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”
Este material tambien lo podras acceder en http://blogs.technet.com/b/sql_pfe_latam/
Dear members of the PFE LATAM community and SQL community, last Friday, June 22, 2012 we had our first Latin American Symposium of SQL Server in the Microsoft Mexico Auditorium.
The agenda for this evens was create by a people with diverse roles like: developers and It Pros. We have speakers like:
Microsoft PFE Database (Premier Field Engineer)
Mexico SQLPASS leads
Microsoft TAM (Technical Account Manager)
Microsoft Solution Sales
The initiative of a Latin-American SQL Server symposium was a big effort done thanks to the collaboration of the communities (groups of users) and we hope to expand this over time to other Latin America countries.
The objective of these events is:
1. To have High Quality events in Latin America to share the same information provided at United States events that are presented several times a year, but in our language and at our reach. For many people that works with Microsoft technology or are is interested in them, might not be affordable to travel to the United States for various reasons.
2. Show the advantages and business benefits that Microsoft products and technologies offer, enhancing the productivity and efficiency of companies and individuals working with these. We accomplish this by sharing the features and details of the latest versions of SQL Server products
This year, Microsoft was the sponsor and was key player combining the efforts made by the SQL Server community to make this event a success. The objective of the event is not only to show the products and their benefits, but also generate a symbiosis that allows our partners or business associates (IW category) to publicize the products and services they provide, generating opportunities for them, and strengthening our partners’ ecosystem.
On this occasion, we had approximately 200 participants from 89 different companies. Presentations exposed during the symposium can be downloaded here.
We invite you to share your comments on the topics and what you'd like to see at the following events.
Estimados miembros de la Comunidad PFE LATAM y Comunidad SQL, el pasado Viernes 22 de Junio del 2012 se llevó a cabo el Primer Simposio Latinoamericano de SQL Server en el Auditorio de Microsoft México
La agenda de este evento fue creada por diversos autores como: desarrolladores y It Pros, en este evento contamos con speakers como:
Leads SQLPASS México
La iniciativa del Simposio Latinoamericano de SQL Server fue un esfuerzo organizado gracias a la colaboración de las comunidades (grupos de usuarios) y esperemos que esta iniciativa se expanda a otros países de Latinoamérica en un futuro proximo.
El objetivo de estos eventos es:
1. Tener en Latinoamérica eventos de alta calidad y compartir la misma información que se ofrece en eventos del mismo tipo que se ofrecen en Estados Unidos varias veces al año, pero en nuestro idioma y a nuestro alcance. Esto nos permite alcanzar y ayudar a más usuarios ya que muchas personas que trabajan con tecnología Microsoft o están interesados en ella no les es fácil viajar a los Estados Unidos por diversas razones.
2. Mostrar las ventajas y beneficios de negocio que los productos y tecnologías Microsoft ofrecen, proveyendo una mayor productividad y eficiencia a las empresas y personas que trabajan con estas. Esto lo logramos compartiendo y detallando las características de las últimas versiones de los productos de SQL Server
Este año Microsoft fue el patrocinador y fue pieza clave para unir los esfuerzos de la Comunidad de SQL Server para lograr que el evento fuera un éxito. El objetivo del evento no es únicamente dar a conocer los productos y sus beneficios, sino también generar una simbiosis que permita a nuestros partners o socios de negocios (categoría IW) el dar a conocer sus productos y servicios, generando áreas de oportunidad y así fortalecer nuestro ecosistema de partners.
En esta ocasión tuvimos aproximadamente 200 participantes de 89 distintas empresas. Las presentaciones expuestas durante el simposio las podrás descargar aquí.
Te invitamos a que nos compartas tus comentarios sobre los temas y nos digas que te gustaría ver en los siguientes eventos.
Hello everybody, this time I’m going to talk about a problem that it’s not related to SQL specifically, it’s an issue that I found related with Windows Server 2003 Failover Clustering
The problem it’s that after installing a shared disk to the cluster nodes they didn’t show up on the cluster, when creating the Physical Disk resource the disks didn’t appear on the drop down list to correlate them to the cluster resource.
After putting a few key words on Bing I found an article about the issue.
Unable to select disk from dropdown in Cluster Administrator http://support.microsoft.com/kb/969053
It helped, but the solutions didn't resolve my issue, let’s review the steps for the Alternative Method:
1. The following command will create a resource of type physical disk: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk"
This step allows you to create a physical disk resource on the cluster with the name Disk F: on the Cluster Group, the resource will be offline and without specific properties
2. The next command is needed for associating the disk through its disk signature to the physical disk resource.
This step will associated the shared disk with the physical disk resource created on the last step through the disk signature. However when executing the command I receive the System Error 87.
So I decided to associated them directly through the registry, with the following steps:
- Open the cluster administrator on the node for the group where you want to add the disk
- Add the physical disk resource using cluster.exe as shown on the article. Ex: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk". The resource will be created offline
- Under HKEY_LOCAL_MACHINE\Cluster\Resources key locate the {GUID} for the physical disk resource you added above.
- Under the Parameters key, ADD a DWORD value called Signature - assign it the HEX disk signature number.
- You should now be able to bring it Online in Cluster Administrator.
This way you should be able to add disk as a resource on the cluster. This issue is uncommon and generally it appears when there some type of incompatibility with the SAN drivers. It likely that with a restart of all the cluster nodes the issue it’s also solved, but sometimes this is not an option.
You can do this using diskpart.exe to read the disk's signature.
1) Go to a command prompt and type "diskpart".
2) In the DISKPART> prompt, type "list disk”.
3) In the DISKPART> prompt, type "select disk n" <- where n is the disk number you wish to view
4) In the DISKPART> prompt, type "detail disk"
5) The "Disk ID: " value is the disk's signature in hexidecimal format.
Hola a todos, esta vez les voy a hablar de tema que no esta relacionado con SQL Server directamente, les voy a hablar de un issue relacionado con Windows Server 2003 Failover Clustering.
El problema en si es que luego de instalar los discos compartidos en los Nodos del Cluster no podían ser agregados como un recurso de Disco físico en el clúster, al realizar el procedimiento para crear un Physical Disk Resource los discos no aparecían en la lista de para seleccionar discos, en realidad no aparecía ningún disco.
Luego de introducir algunas palabras claves en Bing encontré un artículo donde se menciona el problema. Unable to select disk from dropdown in Cluster Administrator http://support.microsoft.com/kb/969053
Aunque me ayudo, la solución no resolvió completamente el problema, vamos a seguir los pasos del método Alternativo:
Este paso te permite crear el un recurso de disco con el nombre Disk F: en el grupo Cluster Group, el recurso se crear offline y sin propiedades especificas.
Este paso se utiliza para asociar el disco compartido al recurso del disco físico creado en el paso anterior a través de la firma (signature) del disco. Sin embargo al ejecutar el comando se generaba un error System Error 87.
Por lo tanto decidí asociarlo directamente a través del registro. Con los siguientes pasos:
- Abro el clúster administrator en el nodo donde esta el Grupo de clúster donde quiero agregar el disco
- Añado el recurso de disco a través de cluster.exe como se muestra en el artículo. Ejm: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk". El recurso es agregado offline
- En la llave de registro HKEY_LOCAL_MACHINE\Cluster\Resources ubico el {GUID} para el recurso de disk agregado anteriormente, deberás ir uno a uno hasta encontrar el que tenga el mismo nombre, Ejm: Disk F:
- En el Key Parameters, añadir un valor DWORD llamado Signature, y en el mismo agregaras la firma hexadecimal del disco
- Ahora podrás ir al cluster administrator y colocar el disco en línea. Puedes ver la propiedades para verificar que esta mapeado al disco adecuado.
De esta manera podrás agregar los discos como recursos del cluster. Este problema es poco común y generalmente se da cuando hay algún tipo de incompatibilidad o issue con los drivers de los discos de la SAN. Es probable que un reinicio de todos los nodos del cluster también resuelva
Si deseas saber como obtener la firma (Signature) del disco sigue los siguientes pasos:
1) Ir al command prompt y escribir "diskpart".
2) En DISKPART> prompt, escribe “list disk”
3) En DISKPART> prompt, escribe "select disk n" <- donde n es el disco que deseas saber la firma
4) En DISKPART> prompt, escribe "detail disk"
5) El valor de "Disk ID: " es el valor en Hexadecimal de la firma del disco
Saludos comunidad
Recientemente una nota acerca de la politica de Microsoft Support Lifecycle fue liberada notificando que a partir del 10 de Julio de 2012 SharePoint Server 2010 dejará de ser soportado en sus versiones actualizas previas al Service Pack 1. El equipo de SharePoint de Latinoamerica les suguiere que actualicen sus granjas de SharePoint 2010 al menos al Service Pack 1 con el respectivo Refresh de Junio, o bien al último update acumulativo de Abril de 2012 (http://support.microsoft.com/kb/2598151) recién liberado.
Referencias:
Microsoft Lifecycle Support Policy FAQ - http://support.microsoft.com/gp/lifePolicy
Lifecycle support team - https://support.microsoftonline.com/eform.aspx?productKey=lifecycle&ct=eformts
MSL Customer Newsletter Sign-up - https://profile.microsoft.com/RegSysProfileCenter/subscriptionwizard.aspx?wizid=98973176-f0b1-4f60-957d-5936c3b933c0&lcid=1033
Si desean actualizar sus granjas de SharePoint por favor consulten la información siguiente:
Updates for SharePoint 2010 Products - http://technet.microsoft.com/en-us/sharepoint/ff800847
Hello there community
Recently was released a note about Microsoft Support Lifecycle policy in which we were adviced that SharePoint Server 2010 (any version before SP1) won't be supported anymore after July 10,2012. SharePoint LATAM PFE team suggests you to update to Service Pack 1 plus June CU Refresh at least, or April 2012 CU (http://support.microsoft.com/kb/2598151) which is the latests SharePoint 2010 Update.
References:
If you want to update your SharePoint Server 2010 please review the following information:
Hi Technet community.
Today I have the privilege to start write in this blog (and a little reward the knowledge I've gained in Technet and MSDN). A few weeks ago it was the launch of SQL 2012 (http://www.microsoft.com/es-es/sqlserver/default.aspx) and I would like to make a brief reference to the current documentation that will allow us to explore some of its new BI features from SharePoint 2010 perspective.
A few weeks ago in Caracas-Venezuela, business partners and customers met at the Renaissance Hotel, to see first hand the value proposition offered by MIcrosoft to help companies and NGOs in the information management: analysis, reporting fast and simple ("Power View"), over huge data ("Parallel Datawarehouse"), in any location (On Premise, cloud or mix) with high availability ("Always On"). SQL 2012 is here with new features in order to strengthen their commitment with the transactional, spatial, multidimensional and critical information.
From the point of view of collaboration and Insights, this commitment translates into the ability to: - Support SharePoint 2010 with Service Pack 1 (SP1) databases.- Editing and publishing in SharePoint sites, reports in any format Office, using "Power View", a new feature of SQL Server Reporting Services for SharePoint.- Strengthen the high availability databases, SharePoint 2010 (with SP1), by "Always On"
At this moment, SQL 2012 is not mentioned in software requirements documentation for SharePoint 2010, However, We have the following Guide for use SQL 2012 BI features in a SharePoint 2010 farm: http://technet.microsoft.com/en-us/library/hh231680(v=SQL.110).aspx This guide describes the possibility of deploying a farm SharePoint on SQL 2012, previously updated with Service Pack 1.
I hope this reference help you to promote the updating of your SharePoint 2010 farm and start to familiarize with the new features of BI in SQL 2012.
Hey there community,
Today we will learn how to create and use WMA or MP3 files as ringtones in our powerfull Windows Phone 7.
Since Microsoft released its Mobile operating system we wished to use our old ringtones from other companies or inclusive from our Windows Mobile phone, today is official we can use WMA and/or MP3 files as ringtones in our phone, but first we need to acomplish some pre-requisites:
Pre-requisites
Procedure:
Enjoy, for more information about please review http://www.microsoft.com/windowsphone/en-us/howto/wp7/start/create-ringtones.aspx
Una vez más trayendo para ustedes algo que pueda ser de utilidad.
Desde que Microsoft liberó la nueva y más reciente versión de su sistema operativo para dispositivos móviles, todos deseamos que el hardware nos permitiera hacer lo que se hace con la competencia (iPhone) relacionado a la personalización de nuestro teléfono y contactos sobre todo. Cuando intentábamos usar un archivo wma como timbre simplemente no era posible.
Pero esto se acabo, ahora podemos usar archivos no protegidos como MP3 o WMA como timbres personalizados y poder usarlos en la configuración de nuestro teléfono, solo debemos cumplir ciertas condiciones y seguir los siguientes pasos:
Requisitos
Procedimiento
Y listo a disfrutar, si tienes dudas o deseas información más detallada y oficial sobre este tema consulta: http://www.microsoft.com/windowsphone/en-us/howto/wp7/start/create-ringtones.aspx