Esto significa nada más que podemos personalizar las plantillas administrativas existentes o crear nuevas plantillas y así aumentar las directivas. Windows nos proporciona unas plantillas administrativas para sus directivas, otras aplicaciones, ya puse el ejemplo de Office, también pueden proporcionar plantillas administrativas. Más que cambiar o modificar las existentes, es más recomendable crear nuestras propias plantillas.
Un aviso: las directivas son generalmente algo que los desarrolladores hacen para dar a los administradores más control sobre las aplicaciones de usuario. Una directiva necesita de código añadido por los desarrolladores que lea las directivas y obligue sus configuraciones a sus aplicaciones. Si los desarrolladores añaden directivas a su código, también crean plantillas para ello. Por otra parte, sin código que obligue a la aplicación de la configuración de directiva, el crear una plantilla administrativa para el es inútil.
- Reparar directivas rotas. No es muy frecuente, pero puede darse el caso que para reparar una directiva incorrecta se cree una plantilla personalizada.
- Crear plantillas administrativas personalizadas. Windows tiene cientos de directivas, office también. Ir a la caza de directivas es a veces frustrante. Podemos crear plantillas personalizadas que recoja en un lugar todas las que implementamos, haciendo el trabajo más sencillo. También podemos repasar la descripción de una directiva y cambiarla para que sea más fácil de entender.
- Personalizar Windows. Muchos de los valores del registro que podemos utilizar para personalizar Windows no tienen interfaz de usuario. Podemos construir una para ellos mediante una plantilla administrativa y entonces cambiar esos valores con el Editor de Directivas.
Podemos usar cualquier editor de texto para la creación de plantillas administrativas. Las plantillas tienen su propio lenguaje y debemos aprenderlo y acostumbrarnos a él. El editor de directivas es perfecto para indicarnos mensajes de error cuando una plantilla los contiene, indicándonos el número de línea, la clave del error y algo más de info. En resumen, cómo usar una plantilla administrativa:
- Con el lenguaje de la plantilla, creamos una, es un archivo de texto con la extensión .adm.
- Cargamos la plantilla en el Editor de directivas.
- Editamos la configuración que define la plantilla.
Un ejemplo, ejemplo.adm:
1: CLASS USER
2:
3: CATEGORY "Directivas de ejemplo"
4: #if version >= 4
5: EXPLAIN "Este ejemplo no hace nada"
6: #endif
7:
8: POLICY "Directiva de ejemplo"
9: #if version >= 4
10: SUPPORTED "Al menos XP Profesional"
11: #endif
12: EXPLAIN "Este tampoco hace mucho"
13: KEYNAME "SoftwarePolicies"
14: VALUENAME Ejemplo
15: VALUEON NUMERIC 1
16: VALUEOFF NUMERIC 0
17: END POLICY
18: END CATEGORY
Los If y endif engloban estados que sólo funcionan con ciertas versiones de Windows.
NT = 2; 2000 = 3; XP SP1 = 4; XP SP2 y 2003 = 5.
Sí queremos añadir comentarios a la plantilla:
; Esto es un comentario
// Esto también lo es
CLASS USER //configuración por usuario
CLASS MACHINE; Configuración por equipo.
Cadenas (strings)
Cuando creamos una plantilla fácil no nos será muy necesario, pero en cuanto trabajemos con plantillas más complicadas nos será muy útil trabajar con la codificación de cadenas, es como definir variables de texto para entendernos.
POLICY !!variable //aquí usamos una variable y no un texto.
POLICY “Ejemplo” // aquí es un texto y no una variable.
En el primer caso para que sustituya la variable variable por la cadena texto, usaremos la definición de cadenas, que no es más que añadir una sección denominada [strings] tal cual, corchetes incluídos. Con lo que el ejemplo quedaría:
POLICY !!variable //aquí usamos una variable y no un texto.
[strings]
variable=”Ejemplo”
Sintaxis de las plantillas
La primera entrada en un archivo de plantilla es la clave CLASS donde se define si la configuración de directiva que seguirá se aplica por-usuario o por-equipo. Pueden utilizarse múltiples CLASS en una misma plantilla. Cuando Windows procese el archivo de plantilla, las definidas en las secciones CLASS USER se unirán en HKCU y las de las secciones CLASS MACHINE en HKLM.
Queda claro pues que su sintaxis es: CLASS USER o CLASS MACHINE, sea para usuario o equipo.
Clave CATEGORY
Después de utilizar CLASS con los valores que aparecerán bajo Configuración de usuario o de Equipo, usaremos CATEGORY para crear subcarpetas en esa rama. El editor mostrará la configuración en esa carpeta. Podemos anidar CATEGORY dentro de CATEGORY.
Estas pueden contener cero o más directivas, las que no contienen directivas tienen una o más subcategorías.
Dentro podemos emplazar claves KEYNAME.
Para cerrar CATEGORY, END CATEGORY.
CATEGORY nombre
KEYNAME subllave
Directivas
END CATEGORY
nombre es el nombre de la carpeta que queremos que se vea en el editor de directivas, podemos usar variables.
Subllave es una subllave opcional de HKLM o HKCU que usamos para la categoría. No se incluye la llave raíz puesto que al definir CLASS ya le estamos indicando de donde colgará. Si hay espacios entre el nombre de la subllave hay que encomillarla.
Las claves que podemos usar dentro de CATEGORY son: CATEGORY, END, KEYNAME y POLICY.
Clave KEYNAME
Esta se usa dentro de CATEGORY y define que subllave HKCU o HKLM (dependiendo de CLASS) contiene el valor que estamos cambiando.
Clave POLICY
Esta clave es para definir una directiva que el administrador pueda cambiar. El editor mostrará la directiva y sus controles en un cuadro de diálogo que el administrador usará para cambiar el estado y valores de la directiva. Se pueden incluir múltiples POLICY en una CATEGORY, pero no es necesario una KEYNAME antes de cada POLICY, la más reciente se aplica a cada POLICY. Para finalizar, END POLICY.
Cada directiva contiene una clave VALUENAME para asociar un valor de registro con ella. De forma predeterminada, el editor asume que es un REG_DWORD y coloca un 0x01 al habilitar la directiva y la elimina al deshabilitarla; si no queremos que lo haga usaremos las claves VALUEON y VALUEOFF. No necesitamos ninguna otra clave aparte de VALUENAME para obtener este comportamiento. Sin embargo podemos especificar opciones adicionales, casillas de verificación, listas, cuadros de texto, y más, incluyendo las claves opcionales PART.
#
POLICY nombre
[KEYNAME subllave]
EXPLAIN ayuda
VALUENAME valor
[PART]
..
END POLICY
Nombre de la directiva.
Subllave, opcional, de HKCU oHKLM a usar por la categoría.
Ayuda es el texto que mostrará el editor en la pestaña de Explicación.
Valor, valor de registro a modificar.
Las claves que podemos usar dentro de una sección POLICY: ACTIONLISTOFF, ACTIONLISTON, END, KEYNAME, PART, VALUENAME, VALUEON, VALUEOFF, HELP, POLICY.
(Hay algunas más pero son para que los desarrolladores creen extensiones de directiva).
Clave PART
PART Name Type
Donde Type puede ser:
CHECKBOX | Muestra en pantalla un Ckeckbox. El valor REG_DWORD es 0x01 si está seleccionado o 0x00 si no lo está.
|
|
COMBOBOX | Muestra en pantalla un ComboBox.
|
|
DROPDOWNLIST | Muestra un combobox con una lista, el usuario sólo puede elegir un elemento.
|
|
EDITTEXT | Muestra en pantalla un cuadro de texto que acepta entradas alfanuméricas. El valor es REG_SZ o REG_EXPAND_SZ.
|
|
LISTBOX | Muestra una lista con los botones Agregar/Quitar. Único tipo que permite administrar múltiples valores de una llave.
|
|
NUMERIC | Muestra un cuadro de texto con un control opcional que acepta valores numéricos. REG_DWORD.
|
|
TEXT | Muestra una línea estática de Texto. No almacena datos en el registro y es útil para añadir ayuda al cuadro de diálogo.
|