Configurar IP en linea de comandos

Hola Mundo:

Feliz año nuevo a todos. Parto este año con una ayuda de memoria y escribiendo el post 500 de la
historia del blog.
El siguiente artículo trata sobre cómo configurar una interfaz de red a través de la línea de comandos. Esta modalidad es muy útil para cuando necesitemos configurar parámetros de red en entornos Windows PE, como es el caso de la distribución de sistemas operativos en ambientes que no tienen. DHCP y se tiene que ir al servidor WDS o SCCM a buscar la imagen.
Sin más preámbulo, empecemos.

Antes de partir hay que conocer cuáles son las interfaces disponibles en el equipo

El mount Netsh interface show interface nos dará la información de todas las interfaces de red que tiene el equipo. Tomar nota del elemento que está en Nombre interfaz.
El comando para configurar la red debe seguir la sintaxis: netsh interface ip set address «NOMBRE INTERFAZ» static IP MASCARA GATEWAY 
Este comando sirve para configurar una ip estática. Para DHCP, cambiar static por DHCP y borrar el resto.
Sin DNS configurado no es posible resolver el nombre del servidor. Este comando debe seguir la siguiente sintaxis:
Netsh interface ip add dns «NOMBRE INTERFAZ» DNS validate=no
Si acceden a revisar la configuración verán los parámetros configurados.
Feliz 2020.

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

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.

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.

Cambio de hora 2017

Hola Mundo:

El día de hoy Microsoft liberó un nuevo hotfix opcional para el cambio de hora en Chile.

Lo único que cambia con respecto al anterior, es que se agrega la nueva zona horaria para la región de Magallanes.

El código del hotfix opcional es KB4015193 y pueden encontrar más referencia en:

https://support.microsoft.com/en-us/help/4015193/dst-changes-in-windows-for-magallanes-chile

Esta actualización ya está disponible para ser distribuida por WSUS o para ser descargada desde el catalogo http://www.catalog.update.microsoft.com/search.aspx?q=4015193

Es importante tener en cuenta que para distribuir este hotfix en máquinas Windows 8.1 o Windows Server 2012 R2, es necesario tener instalado el siguiente update rollup:
https://support.microsoft.com/en-us/help/2919355/windows-rt-8.1,-windows-8.1,-and-windows-server-2012-r2-update-april-2014

¡A parchar, a parchar!

Obtener los contenedores donde se descubren equipos

¡Qué belleza que desde cierto año en adelante todos los productos de Microsoft se administran desde la consola de Powershell!

Esto da muchas prestaciones al momento de obtener información, realizar otro tipo de tareas administrativas no soportadas desde la administración gráfica o automatizar procesos.

Yendo al contexto, SCCM trabaja sobre Active Directory para el descubrimiento de usuarios, grupos y equipos. El descubrimiento específico para equipos se llama Active Directory System Discovery y, según la configuración aplicada, se ejecuta siguiendo una agenda y hace el descubrimiento en contenedores y unidades organizativas.

El listado de OU descubiertas se puede obtener directamente desde la consola, pero en un formato que no es exportable. Se torna complejo saber cuáles son cuando ya son un número considerable.

La solución está en hacerlo desde Powershell de SCCM. Primero que todo, hay que iniciar una sesión en el Powershell de SCCM.
Usar el siguiente script, asumiendo que el codigo de CLP y el servidor es MI-SCCM

PS CLP:> $ADDiscovery = Get-CimInstance -ComputerName "MI-SCCM" -Namespace "rootSMSsite_CLP" -ClassName SMS_SCI_Component -Filter 'ComponentName="SMS_AD_SYSTEM_DISCOVERY_AGENT"'

PS CLP:> $ADContainerProp = $ADDiscovery.PropLists | Where-Object {$_.PropertyListName -eq 'AD Containers'}

PS CLP:> $ADContainerProp.Values

De esta forma, se obtendrá un listado en texto plano en Powershell para usarlo como se estime conveniente.

Espero que sea de utilidad.

Hasta la proxima entrega.

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?

WSUS no sincroniza con SCCM. Error 503

Primer artículo del año. 


Este año se abre con una problemática muy habitual de WSUS y SCCM y guarda relación cuando el
rol de Software Update Point de SCCM no logra conectarse con el servicio de WSUS para gatillar la la actualización del catálogo de actualizaciones para los productos Microsoft seleccionados.
El servicio de WSUS provee una capa de servicios web que otros componentes, como SCCM, consumen para la interoperación.
El signo observado es el error de SCCM al sincronizar con el servicio. Al revisar el log SMS_WSUS_SYNC_MANAGER vamos a encontrar el siguiente mensaje:
Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.
Básicamente, lo que se indica es que al intentar acceder al servicio web, éste le responde con un error 503. 
Si hacen el ejercicio de entrar por el navegador a la URL del servicio, el resultado será el mismo.

Al abrir la consola de IIS y revisar los App Pool encontrarán que WsusPool se encontrará detenido:

Ahí está el problema. El App Pool se encuentra detenido. Tienes dos opciones: Inciarlo de forma manual y esperar a que nuevamente se caiga, o bien, solucionar el problema.
Me inclino por la segunda opción. El problema está en que el App Pool cuenta con memoria asignada insuficiente para atender las peticiones de los clientes. Cuando hay muchos clientes haciendo uso del servicio, se va a utilizar toda la memoria y el servicio se detendrá.
Para corregir el problema entrar a las opciones avanzadas y buscar el elemento Private Memory Limit (KB) y asignarle un valor mayor. Quizá unos 4 ó 5 GB estará bien.
Advertencia: Al aumentar la memoria asignada, el uso de recursos del servidor aumentará y provocará una carga mayor sobre el mismo. Al acceder muchos clientes al mismo servidor para la descarga de actualizaciones, es altamente probable que la red sufra un alto impacto. Si esto ocurre, sugiero revisar la arquitectura de distribución de paquetes.

Una vez realizado el cambio, iniciar el App Pool y el servicio funcionará normalmente.

Saludos!

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!

Ejecutar acciones en clientes SCCM de forma remota

Hola Mundo:
En implementaciones de SCCM para la administración de estaciones de trabajo es necesario realizar

refresco de políticas de algunas máquinas cliente antes del tiempo agendado de refresco.

Me explico. Por defecto, todas las máquinas conversan con el servidor de administración (MP) una vez cada 60 minutos. Estos minutos se empiezan a contar cuando se instala el agente, por lo que no todos los agentes sincronizan al mismo tiempo.
A través de la máquina local del cliente se puede forzar la ejecución del refresco de políticas de máquina, que alteraría el normal tiempo de refresco. 
Para efectos de pruebas y distribución de algún paquete es necesario hacerlo, pero supone un problema darle las indicaciones al usuario para que el lleve a cabo la acción, o bien, intentar conectarse a su máquina e interrumpirlo en sus labores, también es un problema.
Afortunadamente, SCCM y sus agentes funcionan sobre WMI para la ejecución de sus procesos y recolección de información. Teniendo esto asumido, ya podemos decir que se pueden ejecutar procesos de WMI de forma remota.
Cada una de las acciones del agente de SCCM está identificado a través de un identificador. Los más comunes son:
  • Hardware Inventory: {00000000-0000-0000-0000-000000000001}
  • Software Inventory: {00000000-0000-0000-0000-000000000002}
  • Machine policy retrieval and evaluation cycle: {00000000-0000-0000-0000-000000000021}
El cmdlet Invoke-WmiMethod nos apoyará en esta operación. 
Por ejemplo, si se necesitara ejecutar la acción de refresco de políticas de máquina la linea para ejecutar en Powershell sería así:
 Invoke-WmiMethod -ComputerName NOMBRE_DEL_CLIENTE -Namespace rootCCM -Class SMS_Client -Name TriggerSchedule -ArgumentList "{00000000-0000-0000-0000-000000000021}"

Es importante que la sesión de Powershell debe ser con privilegios de administración local de la máquina cliente.
¿Ven? ya se pueden ahorrar problemas y optimizar el trabajo.

Saludos!