Welcome to Delicate template
Header
Just another WordPress site
Header

Alguna vez nos habremos (o no) preguntado como hace nuestro sistema para actualizar las directivas de nuestras maquinas y aplicar los cambios. Lejos de comparar claves con claves para detectar cambios en las mismas, Microsoft utiliza un sistema de versionado para detectar cambios en las directivas de nuestro entorno.

Verificar versión:

Podemos verificar la versión de las directivas desde :

HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\

En este punto disponemos de una serie de claves {XXX}, cada una de ellas corresponde a una extensión documentada en:

http://bit.ly/14GoMce

Por ejemplo, la extensión {25537BA6-77A8-11D2-9B6C-0000F8080861} corresponde a directivas de FolderRedirection. Dentro observaremos las directivas aplicadas que contienen configuraciones de FolderRedirection.

En la clave GPONAME podremos observar el ID de la directiva en cuestión, la cual corresponde con el ID del Sysvol (podemos ver este ID, en la consola de gestión de directivas – gpmc.msc , campo DETALLES de la directiva en cuestión).

En esta, observamos también la VERSION de la directiva; el valor que actualmente nos interesa.

Versión: 3080239

Entendiendo la versión

Veamos de donde sale este número. Una directiva de grupo dispone de dos partes, directiva de maquina y directiva de usuario. Con el fin de verificar y rastrear cambios en la configuración, la GPO rastrea el número de versión en busca de cambios.

Este número se divide en dos partes, una primera para la configuración de maquina y una segunda para configuración de usuario, divididos en forma de 16bits.

En el caso ejemplo, disponemos del siguiente número:

3080239 teniendo en cuenta que la composición de una versión se compone de: [User versión 16Bits][Computer Versin 16Bits]

Realizamos conversión a hexadecimal, para ello podemos utilizar la propia calculadora de Windows la cual nos facilitará la tarea: 2F002F

Realizamos la separación del hexadecimal en dos bloques de 16 bits, el cual nos da el siguiente resultado:

0x00010021 : [002F] User Version [002F] Computer versión

Así disponemos de una versión 47 para la gpo de usuario y una 47 para la gpo de máquina.

Cualquier modificación en la directiva, modificara la versión para la GPO y en el proceso de verificación de directivas se compara la versión. En caso de que la versión no coincida, se reaplicarán cambios de la directiva, en caso que la versión sea igual, se informa que no existen cambios y la directiva no será re-aplicada.

La versión de la directiva, es posible visualizar-la desde la pestaña de DETALLES en la consola de administración de directivas de grupo (gpmc.msc)

Si navegáis un poco por esta sección del registro observareis mas detalles interesantes. Os dejo literatura al respecto para aquellos que queráis profundizar mas.

Habilitar GPSvcDebugLevel para Troubleshooting de GPOs (2008)

Para habilitar el debug en 2008, realizaremos lo siguiente:

Troubleshooting e información ampliada en el procesamiento de directivas

–    Abrir regedit
–    Situarnos en HKLM\Software\Microsoft\Windows NT\CurrentVersion
–    Crear una nueva clave llamada “Diagnostics”
–    Generar un DWORD con nombre “GPSvcDebugLevel” e incluir el valor hexadecimal 0x30002
–    Crear el directorio %systemroot%\Debug\Usermode
–    Realizar un gpupdate /force

A partir de este momento, los logons de usuario generarán un fichero gpsvc.log en la ruta creada, dónde podremos verificar que esta ocurriendo durante la aplicación de directivas.

 Troubleshooting y errores durante en el uso directivas.

–    Abrir regedit
–    Situarnos en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
–    Generar un DWORD con nombre “ExtensionDebugLevel” e incluir el valor decimal 2.
–    Reiniciar la maquina.

El fichero winlogon.log es creado en %systermroot% \Security\Logs para su revisión.

Recursos adicionales:

Computer Policy for Client-side Extensions: http://technet.microsoft.com/en-us/library/cc978265.aspx
Client-side Extension Preferences: http://technet.microsoft.com/en-us/library/cc978250.aspx
Group Policy Client Side Extension List: http://blogs.technet.com/b/mempson/archive/2010/12/01/group-policy-client-side-extension-list.aspx
Understanding the domain-based GPO version number: http://blogs.technet.com/b/grouppolicy/archive/2008/01/08/understanding-the-domain-based-gpo-version-number-scripts-included.aspx
Best Practices: http://technet.microsoft.com/en-us/library/cc961688.aspx
The Basics of Group Policies: http://blogs.technet.com/b/askperf/archive/2007/06/05/the-basics-of-group-policies.aspx
Group Policy Site: http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx
Using Log files for Troubleshooting GPOs: http://technet.microsoft.com/en-us/library/cc775423%28v=WS.10%29.aspx
How Administrative Templates Extension Works: http://technet.microsoft.com/en-us/library/cc758189%28v=WS.10%29.aspx

Gpupdate masivo

marzo 22nd, 2013 | Posted by cristiansan in ActiveDirectory | CLI | Microsoft | PowerShell - (0 Comments)

Durante la integración y/o administración de una plataforma pueden aparecer necesidades constantes de actualizar GPOs en los servidores.

Modificar una GPO y realizar un gpupdate en los servidores no es una tarea complicada, pero cuando son unos cuantos los servidores a actualizar, puede ser un poco tedioso.

Las pruebas se realizarán sobre un servidor donde validaremos su correcto funcionamiento, pero confirmado el proceso, si queremos aplicar de forma inmediata estos cambios al resto de servidores, no nos quedará mas remedio que ir conectando uno por uno para forzar el update o esperar a que estas sean aplicadas de forma automática.

PowerShell permite a los administradores Windows automatizar tareas que solemos utilizar o que es necesario realizar de forma común o repetitiva.

Este pequeño script en PowerShell se encargará de actualizar mediante gpupdate una lista de servidores concreto. Para ello, nos son necesarias 3 cosas.

  1. Lista de servidores a actualizar
  2. Procedimiento para lanzar gpupdate de forma remota
  3. PShell Script que incluya el script

El primer punto se solventa con un fichero .txt en el cual incluimos el nombre de maquina (fqdn). Ejecutar el comando en mas o menos servidores, implica únicamente modificar el fichero con mas o menos servidores a actualizar.

Para el segundo punto, busque la solución mas rápida. Y esta vino de Sysinternals con “psexec.exe” el cual nos posibilita la ejecución de comandos de forma remota.

Por último, solo quedaba generar el script. Y este es sin duda el punto mas sencillo 😉 Ahí os dejo el código:

$ListComputers = gc .\Servers.list.txt

# Creamos variable $ListComputers con el contenido del fichero servers.list.txt

Foreach ($strComputer in $ListComputers)

# Por cada elemento, asignar valor a la variable $strComputer y realizar:

{.\psexec.exe \\$strComputer gpupdate.exe /target:computer /force}

#Ejecuta de forma remota mediate psexec.exe sobre la maquina $strComputer, un gputdate.exe y actualiza las GPOs de maquina.

Modificando el target por :user las gpo de usuario serán actualizadas, pero tened en cuenta que las directivas de usuario en algunos casos requieren de un logoff de usuario. Para forzar este logoff utilizaríamos el modificador /Logoff.

$ListComputers = gc .\Servers.list.txt

Foreach ($strComputer in $ListComputers)

{.\psexec.exe \\$strComputer gpupdate.exe /target:user /forcé /Logoff}

 Recursos:

Psexec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Gpupdate: http://technet.microsoft.com/en-us/library/cc739112%28v=ws.10%29.aspx

 

 

 

 

Si alguna vez necesitáis utilizar el liberador de espacio en 2012 Server (tambien en 2008), os daréis cuenta que no esta ahí… y si queremos liberar espacio… como demonios lo hacemos?

Basta con seguir los siguientes pasos.

Abrir la consola de PowerShell e introducir:

dism /online /enable-feature /all /featurename:DesktopExperience

01

Reiniciamos máquina.

Echo esto, ya dispondremos de la opción para la limpieza de disco.

02

 

Su significado es «IE Enhanced Security Configuration«, su misisón es la de controlar y restringir el acceso a la worl wide web para evitar ataques a nuestros servidores basados en la navegación web y la ejecución de scripts. Para los que querais información adicional, os recomiendo el Link añadido al final del artículo.

IEESC proporciona una capa mas de seguridad, pero para muchos, en algunas ocasiones, puede suponer un lastre a la hora de realizar tareas de forma fluida. Para solucionar este inconveniente, vamos a ver como deshabilitar-lo en 2012 Server.

Para ello seguir los siguientes pasos:

  • Arrancar «Administrador del Servidor»
  • Situar-se en «Servior Local»
  • Dentro del cuadro de Propiedades, localizar «Escritorio Remoto»
  • Justo a su derecha, nos encontramos con la opción «Configuración de seguridad mejorada de IE»
  • Seleccionamos «Activado» y nos aparecerá el cuadro para deshabilitar su uso, tanto para Administradores como para Usuarios.

Quick-Disable

Desde linea de comando ejecutar:

«C:\Windows\system32\rundll32.exe» C:\Windows\system32\iesetup.dll,IEShowHardeningDialog

Con ello se nos mostrará directamente la ventana para deshabilitar las opciones de IESC.

Con este comando podemos generar un shorcut (nuevo acceso directo) con este comando, y utilizar-lo para el rapido acceso a la configuración de IEESC en nuestros entornos.

  • Boton derecho
  • Crear nuevo acceso directo
  • Incluir linea de comando

IEESC01

  • Cambiar icono

IEESC02

Listo para usar-se 😉

IEESC03

NOTA: Ojo, IEESC es una medida adicional de seguridad para nuestros servidores, deshabilitarlo solo cuando esteis totalmente seguros que no va a suponer un riesgo para vuestros equipos. La comodidad tiene un precio xDDD

Si quereis información Extendida de IEESC no dejeis de leeros:

http://technet.microsoft.com/en-us/library/dd883248%28v=ws.10%29.aspx

 

En este artículo vamos a explicar como migrar vuestro controlador de dominio de 2008/2008R2 al reciente 2012. Recordad que también es posible realizar un Upgrade del DC tras elevar el nivel funcional del dominio, pero… ¿de verdad vamos a realizar upgrade en entornos productivos? … 😛

Requisitos previos

Es esencial para seguir este manual…

–       Un Controlador de dominio en 2008/2008R2

–       Un Servidor 2012 Server

Para su migración podemos seguir los siguientes pasos:

  • Incluimos el servidor 2012 dentro del dominio.

 0M

  • Reiniciamos el Servidor.
  • Promocionamos el servidor de 2012 como un nuevo controlador de dominio.

DCPROMO no existe en 2012. Para ello, existen dos posible nuevos caminos.

  1. Utilzar PowerShell
  2. Utilizar ServerManager.

Vamos a usar el método 1 por ser un poco mas ágil inicialmente, aunque no durante todo el proceso; para simplificar-lo, para hacer-lo mas accesible a todo el publico, realizaremos y completaremos la migración desde la GUI.

Para ello, empezamos instalando el rol de AD desde powershell con un simple comando:

Add-WindowsFeature -name ad-domain-services -IncludeManagementTools

Si queremos asegurarnos de que el esquema del bosque y de AD han sido actualizados, en el CD de 2012, dentro de la carpeta Support, disponemos de las herramientas de ADPREP para tal efecto.

Adprep.exe /forestprep

Adprep.exe /domainprep /gpprep

Tras ello, seguimos tal y como indicamos a continuación:

En las notificaciones de administración de servidor podemos observar un icono de Advertencia.

Seleccionamos, “promover el Servidor”.

2M

Seleccionamos “Agregar el controlador al dominio existente”

 3M

Especificamos los roles para el controlador.

4M

Especificamos opciones adicionales.

5M

Confirmamos rutas de acceso y confirmamos el resumen de cambios a realizar y tras ello, se procede con la instalación. Tras ello, el sistema se reinicia.

Una vez finalizado y reiniciado el sistema.

  • Abrimos la consola de “Active Directory Domain and Trusts” desde las herramientas administrativas del controlador de dominio principal.
  • Botón derecho seleccionando “Change Active Directory Domain Controller” y seleccionamos el nuevo controlador de dominio el cual aparece en el listado.
  • Tras ello, seleccionamos “Maestro de Operaciones” y seleccionamos «Change»

7.5M

  • Confirmamos.

8M

 

Aunque creo que la mayoría ya estáis familiarizados, para aquellos que no están, voy a explicar de que se trata y como implementar-lo en unos sencillos pasos.

Básicamente los ADMX son plantillas administrativas, como las de toda la vida, con capacidad para ser centralizadas; lo que permite, gestionar-las desde cualquier punto en lugar desde únicamente la máquina utilizada para cargar los ADM.

Los ADMX consisten en dos ficheros, un ADMX y uno o varios ficheros ADML de idioma. Los ficheros ADMX contienen la definición y aplicación de las directivas, mientras que los ADML son definiciones de idiomas, necesarias para el correcto funcionamiento según el idioma utilizado en nuestro sistema Operativo.

Veamos como configurar-lo:

Central Store

Lo primero que será necesario, es la creación de un repositorio Central para el almacenamiento y el uso de las plantillas administrativas.

El almacenamiento centralizado consiste en un directorio en nivel root  del dominio que contiene todos los ficheros ADMX y subdirectorios dentro de ese nivel que contienen los paquetes de idiomas (ADML).

Crear Almacenamiento centralizado

Para generar el almacenamiento central realizamos lo siguiente:

Crear el siguiente directorio en un controlador de dominio:

\\Domain\sysvol\domain\policies\PolicyDefinitions

Crear un subdirectorio dentro de la ruta especifica con las definiciones de idiomas tal y como son utilizadas en las rutas originales:

ES_es; EN_US; etc

La nomenclatura para las subcarpetas especificas es:

ISO-style Language/Culture Name

Poblar el Almacenamiento centralizado.

Entendemos por “poblar”, el proceso por el cual procedemos a almacenar la lista de plantillas administrativas ADMX y recursos de idiomas ADML dentro del recurso de almacenamiento centralizado.

Para ello, abrimos un CMD y ejecutamos:

copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain% \policies\PolicyDefinitions\

Esto copiara los ADMX por defecto de 2008 dentro del PolicyDefinitions del Sysvol. Realizado, es necesario proceder a la copia de los idiomas:

copy %systemroot%\PolicyDefinitions\[MUIculture]\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\[MUIculture]\

donde [MUIculture] = EN_US ; ES_ES

Una vez realizado, ya podremos gestionar de forma centralizada las directivas del dominio desde cualquier máquina del dominio (siempre que cumplamos los requisitos para ello.)

Desde este momento, cualquier carga de un nuevo ADMX, como los propios de Office, Citrix, etc, pueden ser copiados en este almacenamiento, junto a su correspondiente ADML, permitiendo la gestión centralizada de las plantillas.

Convertir ADM a ADMX

Uno de las dudas que pueden surgir es que ocurre con los ADM actuales. Es posible centralizar-los?

La respuesta es NO. Los ADM no pueden ser centralizados, pero, lo que podemos hacer es convertir-los a ADMX.

Para ello, podemos utilizar ADM Migrator, el cual se basa en un Snap-in de MMC que nos permitirá convertir nuestros ADM a ADMX en unos sencillos pasos y de este modo centralizar la plantilla administrativa en cuestión.

Recursos

Microsoft KnolewdgeBase: http://support.microsoft.com/kb/929841/es

ADM Migrator: http://www.microsoft.com/en-us/download/details.aspx?id=15058

Download ADMX/ADML 2008R2: http://www.microsoft.com/en-us/download/details.aspx?id=6243

Posibles Problemas

Si al intentar gestionar las directivas de dominio desde el gpmc.msc obtemos el siguiente error al situarnos en las plantillas Administrativas:

Error 1:

«Encountered and Error While Parsing. – An Appropiate resource file could not be found for file \\_\_\x.admx (error = 18): There are no more files»

Solución:

Este error ocurre cuando no disponemos de las plantillas de idiomas correctamente cargadas en el repositorio Central. Para solventar-lo copiar las plantillas de idiomas ADML en el correspondiente repositorio centralizado.

Error 2:

«Encountered and Error While Parsing. – Resource $(String.XXX)’ referenced in attribute displayName could not be found.

File \\_\_\x.admx, line XX, Columm XX»

Solución:

Este problema es debido a un error en el fichero ADML de traducción. Comprobar el fichero indicado linea X, columna X del correspondiente ADML del ADMX que esta fallando.

Normalmente el problema es que esta linea no corresponde con la definición. Re-cargar los ficheros ADML nuevamente deberia solventar el problema.