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

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.

Inventarios muy grandes en SCCM

Hola Mundo!
¿Qué tal la vida? ¿Las vacaciones? ¿El tiempo de verano? Se apareció marzo, pues. Nada que hacer.
El día de hoy, les compartiré un error habitual en SCCM a la hora de recolectar inventarios.
Una de las principales funciones de SCCM es mantener inventarios actualizados de las estaciones de trabajo que administra. Es bien completo y se puede manejar, con precisión, qué es lo que se va a inventariar. 
El problema se presenta cuando el inventario es muy grande y el archivo que llega al servidor excede los 5 MB. Ese es el tamaño máximo permitido por la plataforma.
El error que nos podemos encontrar es el siguiente:
Inventory Data Loader failed to process the file C:Program FilesMicrosoft Configuration Managerinboxesauthdataldr.boxProcessXXXXXX.MIF because it is larger than the defined maximum allowable size of 5000000.

Solution: Increase the maximum allowable size, which is defined in the registry key HKLMSoftwareMicrosoftSMSComponentsSMS_INVENTORY_DATA_LOADERMax MIF Size (the default is 5 MB), and wait for Inventory Data Loader to retry the operation.
 El mismo mensaje de error nos sugiere qué hacer. Modificar el Registro de Windows. Navegar hacia la clave HKLMSoftwareMicrosoftSMSComponentsSMS_INVENTORY_DATA_LOADERMax  MIF Size y aumentar el valor.
Eso es todo.
Simple, ¿no?

Consola de SCOM se cierra de forma inesperada

Hola Mundo:

El día de ayer atendí un caso de soporte en el que la consola se SCOM 2012 R2 se cerraba de forma
inesperada.
Según el visor de eventos, el mensaje de error reportado es:

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1090, time stamp: 0x55ba7214
Faulting module name: ntdll.dll, version: 6.1.7601.23543, time stamp: 0x57d2fde1
Exception code: 0xc0000374
Fault offset: 0x00000000000bf262
Faulting process id: 0x1038
Faulting application start time: 0x01d2393cc1f5ba30
Faulting application path: E:Program FilesMicrosoft System Center 2012 R2Operations ManagerConsoleMicrosoft.EnterpriseManagement.Monitoring.Console.exe
Faulting module path: C:WindowsSYSTEM32ntdll.dll

Haciendo una investigación en mi buscador favorito, encuentro que otros usuarios han reportado el mismo comportamiento luego de la instalación de una actualización de octubre del 2016.
Una rápida solución consiste en la desinstalación de la actualización KB3185331.

Afortunadamente, Microsoft ya se hizo cargo del problema y liberó una actualización:
https://support.microsoft.com/en-us/kb/3200006

Solución: Instalar la actualización especificada en el link y reiniciar el servidor.

Más referencia sobre el problema:

Éxito!

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.

Introducir licencia en SCCM 2012 R2

Hola Mundo:
Llegué un poco tarde a iniciar el 2016 en el blog, de todas formas nunca es tarde para compartir una útil anotación sobre SCCM.
El día de hoy mostraré los pasos para introducir la licencia de SCCM 2012 y 2012 R2.   Afortunadamente, en SCCM podemos introducir la licencia cuando el producto ya instalado. Esto no es posible con otros productos de System Center.
Paso 1: Abrir programas y características
No es que vayamos a desinstalarlo, solo vamos a hacer un cambio en él.
Mostrará una advertencia que hay otros usuarios conectados a la aplicación. Le damos a Continuar.

Paso 2: Iniciar el asistente y seguirlo

Paso 3: Seleccionar la opción de  realizar mantenimiento en el sitio

Paso 4: Seleccionar la opción de actualizar la edición de evaluación

Paso 5: Aceptar los términos y condiciones

Paso 6: Ejecución y OK!

El proceso completo no debiera tomar más de 10 minutos. Tienes 180 días para introducir la licencia. 
Espero que les sirva.
Chau!