Error al distribuir updates con SCCM

Hola Mundo:

System Center Configuration Manager es una plataforma muy cómoda y competente para la

administración de un servicio de distribución de actualizaciones para productos Microsoft. Estamos hablando de Windows Server Update Services (WSUS).

Al momento de distribuir actualizaciones, en el log WUAHandler.log (de la máquina cliente) se puede observar lo siguiente:

El mensaje es:
Group Policy settings were overwritten by a higher authority (Domain controller) to: <URL WSUS> Policy

Básicamente, SCCM reconoce que las políticas del dominio tienen más autoridad que las que él puede manejar.

Solución:  Desactivar política de dominio donde se le indica a las estaciones de trabajo dónde tienen que ir a buscar actualizaciones.

De esta forma, le entregamos el control a SCCM para que se encargue de aplicar las reglas de actualización de productos  Microsoft.

Eso.
Chau.

Cuentas con privilegios locales en productos de System Center

Hola Mundo:
Los productos de System Center están orientados, principalmente, a la administración. Por lo tanto,
es necesario que estas herramientas tengan los privilegios adecuados, ni más ni menos, para poder realizar operaciones propias de la administración con ellas.
Es el caso de System Center Operations Manager en el que la plataforma debe tener acceso  a la máquina que será monitoreada para la instalación del agente, ya sea en cualquier plataforma, o bien, para la ejecución de procesos propios del monitoreo. Esta cuentas son las Action Account y RunAs Accounts. También existen otras cuentas de mantenimiento que no serán tocadas en este artículo.
Por su parte, System Center Configuration Manager, tiene que ser capaz de realizar la instalación del agente, Client Push Installation Account, o poder subir a la máquina al dominio, en caso de estar ejecutando un Task Sequence de distribución de sistemas operativos que incluya esa tarea.

En muchos casos, también se debe configurar una cuenta para que la máquina pueda acceder a los recursos en red para la obtención de un paquete. En los dos últimos casos, esta cuenta se llama Network Access Account.
Es una muy buena práctica y altamente recomendado que las cuentas a configurar no tengan privilegios sobre el dominio. Solo deben poder autenticarse. Es un riesgo innecesario que las cuentas tengan privilegios de administrador de dominio. 
La creación de una cuenta que tenga permisos de administración local de las máquinas administradas no es proceso distinto a como cuando se crea una cuenta de usuario en Active Directory.  
Lo que si es necesario es la configuración de una política de dominio para que esta cuenta se miembro del  grupo de administradores de la máquina.
Para crear esta política ir a la herramienta de administración de políticas de grupo (se requiere permisos sobre el dominio para llevar a cabo esta acción). Idealmente, esta cuenta no debe expirar. En el caso de cambio de contraseña, actualizar las configuraciones realizadas en la plataforma.
Crear una nueva política y asignarle un nombre descriptivo.
En el editor de políticas, navegar hacia: Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups
Crear una nueva definición de grupo. Tener muy en cuenta que la acción Update no quitará los otros miembros que ya forman parte del grupo de administradores local de las máquinas. El ámbito de esta configuración solo aplica a nivel local de las máquinas clientes.
En el combo box se debe seleccionar el grupo Administrators (built-in)
En la última porción del cuadro, se debe agregar los miembros. Aquí es donde se agrega la cuenta que se creó para este propósito. La acción debe ser  Add to this group.
Así se verá el cuadro una vez que se hayan realizado las configuraciones necesarias
Dándole OK a todos los cuadros, la política queda lista para ser enlazada a una OU de computadores y las cuentas listas para ser configuradas.
Sobre los detalles de cuentas de SCCM y SCOM visitar los enlaces:
Espero que sea de su utilidad.

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.

Ventanas de mantenimiento con System Center Configuration Manager

Hola Mundo:

Es tarea del departamento de TI y soporte hacer mantenimiento en las estaciones de trabajo. El mantenimiento implica la ejecución de las revisiones de los antivirus, limpieza de los equipos, distribución de configuración, distribución de aplicaciones y, la más temida, distribución de actualizaciones.


Es muy habitual que se implemente una mala política de distribución de actualizaciones a nivel corporativo. Esta política es, sencillamente, no distribuir actualizaciones. 
Los motivos para no distribuir actualizaciones  he visto que, principalmente, son 3:

  1. Porque no son necesarias
  2. Porque son una molestia para los administradores y para los usuarios
  3. Porque no cuentan con una herramienta que permita optimizar el proceso
No entraremos en discusión sobe las buenas prácticas al respecto, pero si me quiero centrar en el punto 2. 
El punto 2 está condicionado a que no se dan las ventanas de trabajo para que se realice esta importante tarea y es ahí donde quiero llegar.
Las ventanas de mantenimiento son espacios de tiempo en los que los usuarios no se encuentran trabajando. Es un espacio donde el horario hábil ya acabó y se pueden ejecutar las tareas automatizadas, como la de distribución de actualizaciones.
Con System Center Configuration Manager se puede configurar las ventanas de mantenimiento a nivel de colección y configurar la distribución de paquetes para que se realice la instalación dentro de esa ventana.
Generando una ventana de mantenimiento por colección, puede darse el caso que a una máquina tenga asignada dos o más ventanas de mantenimiento. 
  • Si las ventanas de mantenimiento no tienen tiempo en común, serán tratadas como ventanas de mantenimiento aparte.
  • Si las ventanas de mantenimiento tienen tiempo en común, se considerará la extensión total de las ventanas. Por ejemplo: Si dos ventanas de mantenimiento de una hora de extensión cada una, sobre un equipo, tienen un tiempo en compartido de 30 minutos, la ventana será de 90 minutos.

La configuración de una ventana de mantenimiento para colección, se tiene que hacer en las propiedades:

Vista de las ventanas de mantenimiento creadas.

Configuración de la agenda de la ventana de mantenimiento

Al momento de la distribución de una aplicación se puede configurar cual es la acción que se puede tomar una vez que la fecha límite de instalación ha sido alcanzada:
Los invito a configurar las ventanas de mantenimiento para que no veamos a usuarios haciendo:
Al ver que se están instalando actualizaciones cuando está haciendo su trabajo.
Adelante estudios.

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!

Migración de File Server y configuración de los SPN

Hola Mundo:
No hay migración de servicios que no esté acompañada de dolores de cabeza. Especialmente si son servicios críticos para las organizaciones, como es el caso de los servidores de archivos.

Nunca hay que creer cuando comentan que la migración de un File Server es solo mover los archivos de un lugar a otro usando Robocopy y luego hacer el cambio en el servidor DNS para que siga conservando el mismo nombre que el servidor de origen y el cambio sea transparente a los usuarios.

Antes de explicar el cambio de SPN, me gustaría que se entendiera el concepto de SPN en su definición más fundamental.
SPN viene de la sigla de Service Principal Name.
Éstos deben estar asociados a un objeto de Active Directory (cuenta de usuario, grupo o computador) en el cual el servicio se ejecuta. Su función principal es soportar la autenticación mutua entre un cliente y un servicio.

Entonces, la configuración de un SPN consiste en la asociación de un servicio a un objeto de AD. Un objeto de AD puede tener varios SPN asociados, pero un SPN solo puede estar asociado a un objeto de AD. En el caso de que se duplique un SPN, vendrán los problemas.

Cuando se realiza una migración de File Server y posteriormente se hace el cambio en el DNS para que el antiguo servidor apunte al nuevo y se intenta acceder a la ruta, el visor de eventos mostrará un error así:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SRV-NUEVO$. The target name used was cifs/SRV-VIEJO. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMINIO.CL) is different from the client domain (DOMINIO.CL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. 

Como el SPN no estaba configurado de forma correcta, no es posible hacer ni mantener la autenticación, por lo tanto, da error.

Para configurar el SPN, se debe hacer con una cuenta con privilegios sobre el dominio.

Eliminando un SPN
Antes de asignar un SPN a un objeto, hay que eliminarlo  del objeto al cual estaba asignado. Se debe seguir la sintaxis:
setspn -D servicio/host ObjetoAD Por ejemplo:

setspn -D host/srv-viejo.midominio.cl srv-viejo
setspn -D host/srv-viejo srv-viejo
setspn -D cifs/srv-viejo.midominio.cl srv-viejo
setspn -D cifs/srv-viejo srv-viejo

De esta forma se elimina los SPN asociados al file server del objeto srv-viejo.

Asociar un SPN
Una vez desasociados los SPN al antiguo objeto, se debe asociar al nuevo objeto. La sintaxis es:
setspn -S servicio/host ObjetoAD Por ejemplo:

setspn -S host/srv-viejo.midominio.cl srv-nuevo
setspn -S host/srv-viejo srv-nuevo
setspn -S cifs/srv-viejo.midominio.cl srv-nuevo
setspn -S cifs/srv-viejo srv-nuevo

De esta forma, el servicio podrá autenticar y mantener la autenticación. El recurso compartido es accesible desde los clientes. Hay que tener un especial cuidado con los clientes con Windows XP. Por que aparte de configurar los SPN correspondientes, también hay que hacer un cambio en el editor del registro de Windows. Seguir la documentación de este link: https://support.microsoft.com/en-us/kb/281308

Más información sobre la herramienta setspn se puede encontrar aqui: https://technet.microsoft.com/en-us/library/cc961723.aspx

Así que para la próxima vez que alguien diga que las migraciones de File Server son un proceso sencillo y sin muchos pasos, es pura fantasía.

Hasta la próxima.

Chau

Proteger un directorio con AD RMS

Hola Mundo
La pregunta del millón es: ¿se puede proteger un directorio con Active Directory Rights Management Services (AD RMS)? 
La respuesta es: No precisamente.

AD RMS es un servicio que funciona a nivel de dominio que se encarga de la protección del contenido de documentos de Office, correos electrónicos y, eventualmente, otro tipo de documentos como los PDF.

Si se tiene un número considerable de documentos a los que se necesita proteger y este número de documentos aumenta de manera periódica, existe una herramienta gratuita llamada Active Directory Rights Management Services Bulk Protection Tool que se encarga de proteger los documentos de una carpeta en base a plantillas de permisos.

Las plantillas de permisos deben ser generadas en la consola de AD RMS. En la plantilla, se puede asignar permisos por usuario o por grupo.

Las plantillas se deben guardar en un directorio compartido. Esta configuración se realiza, de igual manera, en la consola de AD RMS.

Lo importante es definir de manera correcta los permisos.
Al ir seleccionando los permisos que tendrá el grupo o usuario de Active Directory sobre el (o los) documento, los privilegios que son dependencias de otros se irán seleccionando de forma automática en la medida que son requeridos.

Una vez que la plantilla está creada y disponible en un directorio compartido, se invoca a la herramienta que protege de forma masiva. Esta herramienta debe estar instalada en el  mismo servidor donde están los documentos. Se puede tomar como si fuera un servidor de archivos.
La forma de usar la herramienta es:

RMSBulk [/decrypt location] [/encrypt location rms_template [owner_email]] [/log log_file [/append] [/simple]] [/preserveattributes] [/silent]

La herramienta no tiene interfaz gráfica. Deja abierta la posibilidad de crear un script y automatizar el proceso. Mejor aun, crear una tarea programada con la secuencia de comandos.
Con una buena organización de directorios y plantillas, se puede automatizar la protección de documentos  a gran escala.
¡Hasta la próxima!

Desinstalar actualización de Microsoft con SCCM 2012 R2

Hola Mundo:

SCCM tiene numerosos roles que se instalan según la funcionalidad que se necesite de la implementación.
Uno de ellos es el rol de Software Update Point que se encarga de la distribución de actualizaciones de Windows. Funciona sobre el rol de Windows Server Update Services (WSUS).
A través del asistente se pueden implementar actualizaciones hacia una colección de dispositivos.

Entonces ¿cómo quitar un update? 
La gram mayoría de las actualizaciones de Microsoft se instalan con la herramienta wusa.exe ubicada en C:WindowsSystem32  o C:WindowsSysWoW64
Esta herramienta tiene parámetros que se encargan de la desinstalación pasiva y silenciosa de actualizaciones. Los parámetros son /uninstall /quiet /norestart
Por ejemplo:
Si se necesita desinstalar un update que su código corresponde al KB1234567 se debe ejecutar la línea:
wusa.exe /uninstall /kb:1234567 /quiet /norestart

Conociendo esto se puede pensar en distribuir un script a través de un paquete o la línea de comandos a través de un paquete para hacer la desinstalación.
Sorpresa causará cuando vean que el update no se desinstalará y arrojará error.

El procedimiento adecuado es usar un Task Sequence.
Habitualmente los Task Sequence se utilizan para desplegar imágenes de sistemas operativos, pero ahora se usará para ejecutar una línea de comandos.

Creación de un Task Sequence personalizado. Ya conté más arriba que no se usará para desplegar una imagen de Sistema Operativo.

Información descriptiva del Task Sequence. No es necesario una imagen de booteo, porque no se desplegará una imagen de sistema operativo.

Resumen de la creación del Task Sequence.

Creación Exitosa.

Una vez creado el Task Sequence, no tiene ningún paso. En este paso es cuando se agrega una tarea de ejecución de línea de comandos.

Configuración de la tarea. En la caja de línea de comandos, se especifica qué update se quiere quitar usando la herramienta wusa.exe. Guardar y aplicar los cambios.
Una vez creado el Task Sequence hay que implementar en la colección que se necesite.

Problema: Falta de configuración de Sufijo DNS

Hola Mundo:

En todas las organizaciones que cuentan  con el servicio de Active Directory y DNS para la
administración de objetos de equipos, cuentas y políticas, las máquinas pueden tener conectividad a otras máquinas solo usando el nombre, siendo no necesario usar el FQDN.

Por ejemplo:

En ambos casos se ve que el ping funciona correctamente. La otra máquina responde indistintamente si se llama a través de su nombre de máquina o de su FQDN.
Esto se debe al sufijo DNS. Cuando se invoca a una máquina solo por el nombre, la configuración de sufijo de DNS agrega el nombre de dominio como sufijo. En el ejemplo, el sufijo está configurado como bluesolutions.cl.
En el caso que no esté configurado, se puede configurar a través de una GPO:
Una vez esto, desplegar la política a las OU correspondientes y forzar la actualización de polítvas en los clientes.

Error al usar el cmdlet Uninstall-CSDatabase

Hola Mundo:

Cualquier proceso de migración va en la recta final cuando te pones a quitar por completo la antigua
versión.

En el caso de Lync, en una migración de la versión 2010 a la versión 2013, ya los últimos pasos son cuando migras el Central Management Store y desinstalas la base de datos antigua.
Hay un comando que sirve justamente para este propósito. El cmdlet (de Powershell) es Uninstall-CsDatabase.

El cmdlet tiene un montón de parámetros que no los tocaremos ahora. Siempre Technet lo explica mejor que yo: http://technet.microsoft.com/en-us/library/gg412922.aspx

Lo normal, es que siempre que se ejecute la herramienta, termine con un mensaje parecido a este para indicar que todo terminó de forma correcta:

Pero hay veces que termina así:

—————
Exit code: ERROR_ALLOW_DATABASE_ACCESS (-22)
—————
Ok. Que no cunda el pánico. Si esto ocurre es porque:

  1. La cuenta que estás usando no es administrador del SQL Server
  2. La cuenta que estás usando no es administrador local de la máquina de Lync
  3. La cuenta que estás usando no es una cuenta de dominio.
Cumpliendo los 3 puntos, la cosa funcionará.
Chau