Welcome to Delicate template
Header
Just another WordPress site
Header

p1

Disponemos de dos métodos para la realización de esta tarea. Una consta del uso de GPO, para el otro método, será necesario la edición del registro.

Método 1. GPO

Utilizaremos la siguiente directiva:

User Configuration\Administrative Templates\Windows Components\Store

Dónde podemos ver la opción: Turn off the Store application

Método 2. Register

Nos situamos en la clave de registro

 [HKEY_CURRENT_USER\Software\Policies\Microsoft\WindowsStore]

Para des-habilitar la store, crear la clave con los valores a continuación indicados.

«RemoveWindowsStore»=dword:00000001

p2

 

 

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

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.