Mover base de datos de una region a otra en Azure

Hola mundo:
En esta entrega, revisaremos un procedimiento altamente solicitado por administradores de infraestructura en Azure. Este consiste en migrar una base de datos de una región a otra con muy bajo downtime y, prácticamente, sin pérdida de datos, utilizando la geo replicación y las características de alta disponibilidad.
Para este ejemplo, tendré una base de datos de prueba (AdventureWorks)  en la región East US. Para efectos de la prueba, es una base de datos de bajo costo.
Dentro del panel del recurso, iremos al menú de la izquierda y ubicaremos la opción Geo-Replication
Abrirá una ventana asi. Se muestra un mapa con las regiones disponibles para hacer la replicación

Para hacer la replicación, escogeré la región West US 2 del listado. Una vez seleccionada la región, abrirá un asistente donde se pide configurar algunos parámetros. Entre los parámetros a configurar es la creación de un servidor SQL Server donde residirá la base de datos réplica. 
Una vez seteados los parámetros, la replicación comenzará a ejecutarse:

 
Aparece la base de datos replicada en el apartado de Secondaries y en el mapa se ve una gráfica de la replicación.
Al entrar en la réplica de la base de datos, veremos la opción de hacer un failover forzado.
Al hacer el failover aparece una advertencia diciendo que todas las sesiones van a ser desconectadas y que podría perder datos. Entendiendo los riesgos, procedemos.
Al volver a la vista principal de geo replicación, se ve que el estado de la base de datos secundaria está en proceso de failover.
Luego de esperar el cambio, se puede observar que la base de datos secundaria ya es primaria:
Ahora queda cumplir el cometido: Eliminar la base de datos para que solo quede en una sola region. Para esto hay que ir a la vista de las bases de datos y eliminar la que corresponde. Tomar en cuenta que aparece cual es el rol de la base de datos (primaria o secundaria). 
Confirmación de eliminación
Con este procedimiento, la geo replicación queda desactivada y la base de datos operando en la nueva región.  Es importante cambiar la conexión en las aplicaciones que hagan uso de esta base de datos. Recordar que es un nuevo servidor SQL Server, con un nombre distinto.
Espero que les sea de utilidad.

Autenticación remota a SQL y error de certificado

Hola Mundo:
¡Uf! bastante tiempo sin dedicarle unas líneas al blog que me ha acompañado por un poco más de 10 años. Que ha sido testigo de mi aprendizaje y de mis experiencias en el mundo de bits y bytes.

Hoy he vuelto con la solución a un problema recurrente al momento de conectarse a un origen de datos como SQL Server.

La cadena de certificación fue emitida por una entidad en la que no se confía
—————————-
La conexión con el servidor se ha establecido correctamente, pero se ha producido un error durante el proceso de inicio de sesión. (provider: SSL Provider, error: 0 – La cadena de certificación fue emitida por una entidad en la que no se confía.)

Para las conexiones remotas a SQL Server, el servidor requiere de un certificado que debe ser importado en las máquinas donde se realizará la conexión.

Desde el servidor,  abrir el contenedor de certificados y navegar hacia la ruta de la imagen:

En el cliente, el certificado se debe importar en:

y listo.

Espero que les sirva

Mover la ubicación de la base de datos de SCCM

Hola Mundo

La organización del almacenamiento de un servidor de base de datos es crucial para el rendimiento y
correcta operación de ésta. Requiere de constante monitoreo y cambios, en el caso de ser necesario, para mantener la continuidad operativa del servicio.

Mover el archivo de datos y archivo de log de una base de datos de un directorio a otro puede sonar una tarea trivial. Este tipo de operación requiere de una planificación previa, ventana de mantenimiento para bajar el servicio y un plan de rollback, en caso de fallo.

La base de datos de SCCM es crucial para el funcionamiento de la plataforma completa. Es aquí donde se almacenan todos los datos y configuraciones. Por lo que un mal funcionamiento de la base de datos, provocaría un comportamiento errático, o bien, dejaría fuera de servicio a la solución.

Cuando se mueve la base de datos de SCCM de un directorio físico a otro, conservando el servidor, es necesario volver a setear la propiedad TRUSTWORTHY de la base de datos.

Básicamente, esta propiedad indica si la instancia de SQL Server confía en la base de datos o no. Para la operación de la solución, la instancia debe confiar en la base de datos posterior al cambio.

En el caso que no se configure la propiedad, se generarán muchos problemas al momento de distribuir  una actualización a través del rol Software Update Point y WSUS.
El error que van a encontrar es:

*** *** Unknown SQL Error! SMS Provider 14-03-2012 07:56:47 2016 (0x07E0) 
*~*~*** Unknown SQL Error! ThreadID : 2016 , DbError: 50000 , Sev: 16~*~* SMS Provider 14-03-2012 07:56:47 2016 (0x07E0)
*** [24000][0][Microsoft][SQL Server Native Client 10.0]Invalid cursor state SMS Provider 14-03-2012 07:56:48 2016 (0x07E0)
*~*~[24000][0][Microsoft][SQL Server Native Client 10.0]Invalid cursor state *** Unknown SQL Error! ThreadID : 2016 ,
DbError: 0 , Sev: 0~*~* SMS Provider 14-03-2012 07:56:48 2016 (0x07E0)

El caso está descrito en el sitio de soporte de Microsoft y tiene los pasos precisos para la solución
https://support.microsoft.com/en-us/help/3057073/after-the-system-center-2012-configmgr-sql-site-database-is-moved,-you-cannot-create-a-software-update-package-or-application

Espero que les sirva.

Recomendaciones para base de datos para SCCM

Hola Mundo:

La implementación de System Center Configuration Manager requiere de un servidor de base de
datos SQL Server y existen recomendaciones para esta implementación, que presentaré las más relevantes.
Servidor dedicado
SCCM es una plataforma que almacena absolutamente todo en base de datos e incluso realiza transacciones sin darnos cuenta. Hay que pensar, que en todo momento se están recibiendo inventarios e información de distribución de paquetes. Aparte, hay que tener que es una herramienta asíncrona y mantiene su propia cola de procesos y transacciones con la base de datos.
Es por eso que siempre tiene muchas conexiones abiertas hacia la base de datos.
Particiones de disco
Como todo servidor de base de datos, la configuración de los discos es vital. Es muy importante que sistema operativo, datos, logs, tempdb y respaldo queden en discos distintos. Incluso, si son máquinas virtuales, los discos virtuales deberían estar en discos físicos distintos. Si se crean los discos duros virtuales en el mismo disco o LUN, las operaciones de las bases de datos harán uso de los recursos de un único disco, impactando el rendimiento.
Collation
El collation de una base de datos SQL Server es cómo el sistema interpreta cada uno de los caracteres que se almacena en la base de datos. SCCM requiere del collation SQL_Latin1_General_CP1_CI_AS. No funciona con otro más.
Cuentas
Al momento de instalar el servidor de base de datos, es altamente recomendado configurar una contraseña para la cuenta SA. Esto facilitará la resolución en caso de problemas. Es recomendado, también, configurar las cuentas de servicio como cuentas de dominio.
Puertos
SCCM no soporta puertos dinámicos de SQL Server. Así que cuando instales una instancia para SCCM, asegúrate que el servicio esté escuchando por el puerto 1433.
Mucho cuidado con las instancias nombradas, ya que tienden a configurarse como puertos dinámicos.

64 bits siempre
La arquitectura de 32 bits no está soportada por la plataforma. Siempre se debe usar SQL Server x64 para que SCCM pueda reconocerlo como un servidor de base de datos compatible. En el caso que no sea así, el programa de instalación dará un mensaje de error de incompatibilidad, aun cuando la versión de SQL Server sea soportada.

Uso de memoria
Siempre establece un mínimo y un máximo de memoria para la instancia. Recuerda que un servidor de base de datos es como un sistema operativo, por lo tanto, el uso de memoria es crítico. Como recomendación, siempre dejar un 10% para procesos propios del sistema operativos. Con esto evitas que la instancia utilice el 100% de la memoria y el servidor se quede sin recursos.

Respaldos
La misma plataforma de SCCM incluye una tarea de mantenimiento del sitio completo, inclusive de

la base de datos. Para que en el caso de recuperación ante un desastre, desde el programa de restauración del sitio, se restaure la base de datos. No está recomendado restaurar la base de datos de forma manual. La tarea de respaldo de SCCM debe ser habilitada.

Monitoreo
Como todo servidor de base de datos, está altamente recomendado contar con una solución de monitoreo de servicios para tener conocimiento del estado real de salud del servicio y del servidor y prevenir cuellos de botella e indisponibilidad del servicio.

CPU
Recomendación obvia, pero de todas maneras hay que mencionarla. Para una implementación de este estilo, mínimo 4 CPU si es una máquina virtual. Con esto se evita cuello de botella en el servidor.

Con estas recomendaciones, tendrás un servidor cercano a las mejores prácticas de funcionamiento e implementación y esto se traduce en un mejor rendimiento de la plataforma de SCCM.

Hasta la próxima.

Error en la instalación de System Center Operations Manager

Hola Mundo:

En la instalación de System Center Operations Manager (SCOM) es necesaria la configuración a una
base de datos SQL Server.

Al momento de configurar el nombre del servidor, la instancia de la base de datos y el puerto de conexión puede que aparezca un error de base de datos.

El error dice que puede que la base de datos no sea compatible con los requerimientos de SCOM.

El error es parecido a este:

Si vamos a mirar el log de instalación, en la parte de configuración de la base de datos, encontraremos algo asi:
[10:13:36]: Debug: :Connection was not open.  We will try to open it.
[10:13:37]: Debug: :SqlConnectionReady returned True.
[10:13:37]: Warn: :Warning:Current user doesn’t have enough permissions to force Sql service to start state. We will still continue and try to connect to Sql Server
[10:13:37]: Debug: :Connection was not open.  We will try to open it. [10:13:37]: Debug: :SqlConnectionReady returned True.
[10:13:37]: Info: :Info:Using DB command timeout = 1800 seconds.
[10:13:37]: Info: :SQL Product Level: SP1
[10:13:37]: Info: :SQL Edition: Standard Edition (64-bit)
[10:13:37]: Info: :SQL Version: 11.0.3128.0
[10:13:37]: Always: :Current Version of SQL=11.0.3128.0   Required Version=10.50.2500.0
[10:13:37]: Always: :Entering GetRemoteOSVersion.
[10:13:37]: Error: :GetRemoteOSVersion(): Threw Exception.Type: System.UnauthorizedAccessException, Exception Error Code: 0x80070005, Exception.Message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Lo que quiere decir el mensaje de error: «El usuario con el que está ejecutando la instalación no tiene permisos para levantar el servicio de SQL Server».

Solución: Agregue el usuario que está usando al grupo de administradores local de la máquina que tiene al SQL Server.

¡Espero que les sirva!

Chau.

Configurar la suscripción de reportes con SQL Server y SSRS

Hola Mundo:

Todo lo que se conecta a SQL Server genera datos que pueden ser presentados en un lindo reporte a través de SQL Server Reporting Services. Puedes trabajar con herramientas intuitivas y orientados a los usuarios no técnicos, como Report Builder. 
En este artículo veremos como crear suscripciones a los reportes ya generados. 
Las suscripciones son agendas que se crean para despachar, habitualmente, por correo electrónico algún reporte. Por ejemplo, envío de reporte de ventas de la semana anterior todos los días lunes a las 9:00 AM.
A nivel de base de datos, se requiere que el servicio SQL Agent esté corriendo. Este servicio es el encargado de administrar los job. Desde el punto de vista del reporte, es el servicio que se encarga de ejecutar la consulta en la base de datos al momento de generar y enviar el reporte.
Este servicio debe ser inicializado en la herramienta SQL Server Configuration Manager:
Para el envío de correos se necesita un servidor SMTP y una cuenta de correo para el envío (no es necesario que esta cuenta exista en el servidor). Los parámetros del servidor deben ser configurados en la herramienta Reporting Services Configuration Manager:
Sender Address es una dirección ficticia. Es para que muestre un origen válido. SMTP Server es la dirección del servidor SMTP. 
En el sitio web de administración de los reportes de SQL Server Reporting Services, buscamos el reporte que se quiere enviar por correo y en el menú contextual, se selecciona la opción de  suscribir.
Primera acción a realizar, es configurar los parámetros de envío de correo y forma. Esto incluye: destinatario, asunto y comentario. También hay que configurar el formato de envío del reporte y agenda (programación). Importante: El portal funciona de forma óptima con Internet Explorer.
Luego hay que configurar los parámetros, si es que el reporte los requiere:
Una vez que está todo OK, la configuración queda guardada apretando el botón Aceptar.
Eso por hoy.
Cambio y fuera.

Error al instalar AD RMS en Windows Server 2008 R2

Hola Mundo:
Para la implementación del rol de AD RMS, se puede utilizar una base de datos interna del rol o se puede utilizar un servidor SQL Server externo.
La instalación no es compleja. Es un asistente que pide datos bastante precisos.
El problema está cuando muestra el siguiente error:
El error hace referencia a la falta de un procedimiento almacenado. El SP se llama sp_dboptions y fue retirado en SQL Server Denali (Pre SQL Server 2012) y el fallo se va arrastrando para las próximas versiones de SQL Server.
El hotfix que se debe es instalar es el KB2619256 y se descarga desde el mismo sitio de Microsoft: https://support.microsoft.com/es-cl/kb/2619256
Para complementar la lectura, sugiero leer la documentación en Technet: https://technet.microsoft.com/en-us/library/dd772673(v=ws.10).aspx