Social Icons

twitter facebook google plus linkedin

viernes, 20 de julio de 2018

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:\SMS\Logs
    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


miércoles, 4 de abril de 2018

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.


miércoles, 24 de enero de 2018

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