Notas sobre el uso de templates en Azure

Hola Mundo:

Usar templates para la creación de recursos en Azure es una característica que existe desde hace algunos añ os en Azure. Esto fue traído por la tecnología implementada Azure Resource Manager, que cambia la forma en la cual se crean y de administran recursos.
Éstas son algunas notas para tener en consideración




Herramientas adecuadas

En mi caso, trabajo con un MacBook Pro y afortunadamente está Visual Studio Code , que es un IDE gratuito y multi plataforma, orientado a desarrollos en la nube y también funciona como editor de texto para otros lenguajes. 
Este IDE trae la posibiliad de trabajar con extensiones que potenciarán el desarrollo. Hay uno para Azure Resource Manager llamado Azure Resource Manager Tools.

Variables, parámetros y funciones definidas

Es importante conocer la diferencia entre parámetros y variables. Básicamente, los parámetros son los que se reciben desde un formulario generado de forma automática y deben ir encasillados desde el espacio de parameters. Las variables son justamente eso, variables. Sirven para la utilización de complejas estructuras de forma simple. Las variables pueden tomar como valor el valor de un parámetro.  
Las funciones definidas apoyarán en tareas como concatenación o trabajar con las propiedades de un resource group, por ejemplo.
Mas información sobre estas funciones se pueden encontrar en: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions
Ejemplos
Si no sabes donde empezar a trabajar con templates, es recomendado basarte en ejemplos.  Existe un completo repositorio de templates que pueden servir para armar templates para la mayoría de los escenarios. La documentación sobre como usarlos se puede encontrar en https://azure.microsoft.com/en-us/resources/templates/ y el repositorio en Github se puede acceder desde https://github.com/Azure/azure-quickstart-templates
Espero que estas notas guíen el inicio  de trabajo con Azure ARM Templates.
Chau! 

Error al actualizar Windows 10 1511

Hola a todos:

Me encuentro trabajando distribuyendo, a través de System Center Configuration Manager, paquetes de actualizaciones para que suban de versión las máquinas con Windows 10.

El problema se presenta en las máquinas Windows 10 1511 al intentar distribuirles un paquete de actualización. Arroja un error particular:
“OnSearchComplete – Failed to end search job. Error = 0x80240fff.”
El error se puede encontrar en los log WUAHandler.log y UpdatesDeployment.log

Este error se presenta cuando las máquinas con Windows 10 1511 no han instalado el update de junio del 2017  (KB4022714).
Se puede descargar desde el siguiente link: https://www.catalog.update.microsoft.com/Search.aspx?q=KB4022714 

Este se puede distribuir como un paquete normal de actualización, o bien, como un paquete cualquiera.
Luego de la instalación del update y posterior reinicio, será posible aplicar la actualización.

Espero que les sirva.

Notas sobre el rol SMP de SCCM

Hola Mundo:
Muchos meses han pasado desde la última entrega. La verdad es que estado entre ocupado y sin mucha información que compartir.
El día de hoy les vengo a hablar sobre un rol de SCCM que está poco documentado. Este rol es State Migration Point.
State Migration Point o SMP es un rol encargado de almacenar de forma temporal los datos de usuario capturados durante la primera parte de la ejecución de un task sequence.
Cabe destacar que esta NO  es una herramienta de respaldo.
Por lo general este rol se instala en el servidor principal de SCCM, pero en ocasiones se requiere que esté instalado en un servidor aparte.
Estas son mis notas:

  1. Instalación de requisitos previos
  2. Cuando se acciona el instalador del rol desde SCCM, este no habilita las características necesarias para el correcto funcionamiento del rol.
    Las características a habilitar son:

  3. Lectura de log de instalación
  4. Todas las instalaciones de roles de SCCM dejan un registro de instalación, en el que va indicando las acciones que va realizando durante la instalación. También deja un registro de los mensajes de error.

    Los logs están ubicados en:
    Volumen:SMSLogs
    Los que corresponden a la instalación son smpMSI y SMSSMPSetup.
  5. Lectura log funcionamiento
  6. En la misma ubicación indicada en el punto anterior, se encuentra el log smpmgr. Este log almacena los mensajes de estados y funcionamiento del rol. Constantemente está realizando pruebas de funcionamiento. Estas pruebas siempre deben devolver el siguiente mensaje de estado:

      Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK  
      Health check operation succeeded 
      Completed availability check on local machine 
         En el caso que de error 500, revisar los mensajes del log.
Espero que esta información les sea de utilidad

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

Recomendaciones para la administración de logs de IIS

Hola Mundo
Internet Information Services es el servidor de aplicaciones incluido como rol dentro de Windows Server, que otros roles y plataformas utilizan para poder dar servicios a la red en la que están inmersos. 
Cada transacción genera una entrada en el registro de log de IIS. Estos registros contienen con precisión el quién, qué, dónde, cuándo y cómo de la transacción. En sistemas altamente concurrentes, el tamaño de los log puede volverse inmanejable. 
 Es altamente aconsejable tener en vista el crecimiento del directorio , con alguna herramienta de monitoreo, o bien, revisando periódicamente con alguna herramienta para estos fines, como WinDirStat (herramienta de terceros gratuita). 

%SystemDrive%inetpubLogFiles

 Para poder tener un mayor control para el posterior análisis, se recomienda partir configurando en IIS:

  • Centralized Binary Logging. Esta configuración permite preservar los recursos de memoria, disminuyendo la cantidad de archivos de log. Manejando un único archivo de datos no formateados. 
  • Crear archivos separados para los distintos sitios web y aplicaciones. Limitar la cantidad de campos que se registran. Registrar solo lo estrictamente necesario. 

 A nivel de sistema de archivos también se pueden hacer cambios en el tratamiento del directorio de logs y es comprimiendo el directorio. Esto se consigue con privilegios de administración sobre el sistema y entrando a las propiedades avanzadas del directorio. Habilitando la compresión, el volumen del directorio será de solo un 2% del tamaño original. Almacenar los log en un directorio remoto es una buena forma, pero hay que considerar el alto trabajo de la red y recursos externos para el correcto funcionamiento.  Recordar que son sistemas intensivos en el uso de recursos. 
 Cuando la administración no es adecuada, el directorio crece y es necesario eliminarlos directamente desde el directorio. La operación no requiere detener el servicio. Se recomienda partir eliminando los más antiguos. 
 La administración y el monitoreo correcto de los log de IIS aseguran la continuidad operativa del sistema en general y ayuda al cuidado de los recursos de disco del servidor. Si se quiere ir más allá, siempre es una opción hacer inteligencia sobre los archivos de log con alguna solución de Big Data.

Habilitar usuario root y permitir login por ssh

Hola Mundo:
Ubuntu impuso la moda de deshabilitar el usuario root y que todas las operaciones que requerían privilegios se hicieran a través de sudo. Esto fue una ventaja desde el punto de vista de seguridad, ya que la superficie expuesta era mucho menor. 

El procedimiento es sencillo, pero hay que tener consideración con la seguridad.
sudo passwd root
Con esto se le asigna una contraseña al usuario root. Para permitir el acceso por ssh hay que ir a /etc/ssh/sshd_config y buscar la opcion PermitLogin y dejarla en yes.


Luego se reinicia el servicio

sudo /etc/init.d/sshd restart
Con esta configuración aplicada ya estarían en condiciones de usar el usuario root.
Espero que hayan disfrutado este micro post.

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 sobre WSUS y SCCM

Hola Mundo:

Este artículo no pretende ser una guía paso a paso para la instalación y configuración de Windows
Server Update Services para System Center Configuration Manager. Más bien es una serie de recomendaciones, basadas en la literatura y en la experiencia, para que ambos servicios trabajen de la mejor manera posible.
Base de datos
Por defecto, el asistente de instalación del rol estará configurado para usar un Windows Internal Database. Este motor de datos, es un SQL Server muy pequeño que funciona sobre Windows Server. 
Utilizarlo no es la mejor práctica en este escenario. Lo mejor es usar un servidor SQL Server aparte. Usar el mismo SQL Server que SCCM es una buena idea (siempre y cuando se cumplan las mejores prácticas). Esto facilita la administración y el mantenimiento de SUSDB.
Asistente de configuración de rol
Una vez que el rol termina de instalar, es necesario ejecutar un asistente de configuración del rol. En este asistente se indica la ruta donde se descargarán las actualizaciones. Es importante ejecutarlo para que SCCM reconozca que el rol está completamente operativo.
Esta consola ya no debe usarse para la distribución de actualizaciones. Solo debe usarse para vigilar la sincronización y ejecutar tareas de limpieza.
Sincronización
Dependiendo de la arquitectura de la solución de SCCM y WSUS, la configuración de este punto va a   permitir que el servidor pueda sincronizar con el catálogo de actualizaciones en línea. 
En el caso que sea el mismo servidor que sale a internet, no debe existir ninguna URI configurada. En el caso que sea otro servidor el que hace la sincronización del catálogo, como el caso de CAS, la URI debiera estar configurada y apuntando al puerto que corresponda. Si es un Windows Server 2012 sin SSL, el puerto es 8530. Si tiene SSL el puerto será 8531. Si es un servidor de una versión inferior, el puerto será el 80.
Esta configuración debe ser configurada en las opciones de configuración del rol Software Update Point en SCCM. 

IIS App Pool

WSUS es un rol que basa gran parte de su funcionamiento en servicios web. Éstos servicios web corren sobre Internet Information Services (IIS). 
Al ser una aplicación, utiliza un App Pool con sus propias configuraciones, pero manejables desde la consola de IIS. De vez en cuando, requieren de ajustes para el uso de CPU y memoria. Tiene a consumir bastante cuando tiene una carga considerable de trabajo de distribución de actualizaciones. Recomiendo esta lectura: http://blog.maximilianomarin.com/2017/01/wsus-no-sincroniza-con-sccm-error-503.html
GPO
No es necesario usar una GPO para indicarle a los equipos del dominio dónde deben ir a buscar las actualizaciones. De eso se encargan los Client Settings de SCCM. En el caso que  exista una política, SCCM nunca podrá instalar actualizaciones en las máquinas, porque el dominio tiene mayor «poder» sobre las estaciones de trabajo. Recomiendo esta lectura http://blog.maximilianomarin.com/2016/09/error-al-distribuir-updates-con-sccm.html
Matenimiento

Es más que necesario ejecutar un plan de limpieza mensual en WSUS para que el servicio opere de forma correcta. Esto implica hacer una limpieza del catálogo, actualizaciones y mantenimiento sobre la base de datos.  Recomiendo esta lectura https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/

Eso es todo por hoy. Tomen en cuenta las recomendaciones. Espero que les sirvan.

Chau.

Consideraciones para la instalacion de Cumulative Updates en SCCM

Hola Mundo:
Los cumulative update son paquetes que incluyen actualizaciones que corrigen fallos de las

plataformas, agregan características nuevas y van quitando aquellas que no son ampliamente usadas o las que ya no se utilizan.
Estos paquetes se liberan con cierta periodicidad y es importante estar atento a la liberación de éstos.
Este artículo pretende dar algunas recomendaciones para la instalación de algún cumulative update en System Center Configuration Manager.
¿Instalarlos o no?
Es muy importante tener en consideración que el rubro de las tecnologías de la información es muy dinámico y variable, por lo tanto, siempre los productos están implementando características nuevas y siempre están saliendo nuevos sistemas operativos que requieren de funcionalidades nuevas. 
No instalarlos es patear el trabajo para más adelante y no sacarle el máximo provecho a la tecnología.
Respaldos
Siempre. Antes de hacer cualquier cambio, es necesario contar con los respaldos al día y de fácil acceso.
Ventana de mantenimiento
Un reinicio luego de la instalación del paquete nunca viene mal. Considerar la instalación y el reinicio en un horario no productivo o cuando se tenga la certeza que no impactará en las operaciones de los usuarios.
¿Dónde empezar?
Dependerá de la implementación que se quiera actualizar. Si es una estructura jerárquica, se recomienda partir desde lo más arriba hacia abajo. Si se tiene un CAS, partir desde el CAS hacia los otros sitios. Si es solo un servidor, partir por el servidor, luego la consola y al final los agentes.
¿Se debe instalar todos los CU anteriores antes de instalar el actual?
Dependerá del CU que se esté instalando. Por ejemplo, el CU4 de la versión 2012 R2 reemplaza a los anteriores. Siempre es una buena idea leer la descripción del CU antes de aplicarlo.
Descripción del CU
Como todo paquete de actualización tiene su respectiva entrada en el sitio de soporte de Microsoft. Leerlo antes de comenzar es un buen comienzo.
La pantalla de inicio de instalación del CU nos dará más información
Si queda alguna duda sobre el paquete que se quiere instalar, consultar en los foros de Technet, Server Fault  o alguno otro de su preferencia.