Directivas y Preferencias

Si leemos GPMC, herramienta principal de creación de Directivas.

Una GPO es un objeto que contiene la configuración de valores que queremos aplicar a usuarios y/o equipos. En español, Directiva de Grupo.

Un Link de Directiva de Grupo es lo que enlaza la directiva a la parte del entorno de AD donde queremos aplicarla. Referido a su ámbito, en el que hay tres niveles donde las aplicamos: Sitios, dominios y OUs.

El Editor de Directivas de grupo es la herramienta que se utiliza para modificar los valores de las directivas, y los valores disponibles se basan en las plantillas administrativas disponibles y cargadas.

Los archivos ADMX tienen dos propósitos. El primero es definir los valores y la ubicación de configuración (en el equipo local) para aquéllos. La segunda es crear el interfaz que usamos para las modificaciones desde el Editor.

Las PREFERENCIAS proporcionan una alternativa para trabajar con imágenes en toda la organización y administrar valores que no se han configurado antes en una GPO. Inicialmente esta configuración establecida por el administrador del sistema refleja un estado predeterminado del sistema operativo y, estos valores no son obligatorios necesariamente.

Cuando hablamos de RSOP nos referimos al conjunto resultante de configuración de Directivas de Grupo aplicadas al finalizar completamente su proceso. Podría ser una combinación de varios niveles de Directivas.

Directivas vs Preferencias

Dos son las formas de configurar sistemas, las Directivas y las Preferencias. Ambas pueden modificar los objetos equipo y usuario, sin embargo la razón de su uso es muy diferente. La más importancia su obligatoriedad, las Directivas lo son, mientras que las Preferencias no lo son estrictamente.

Directivas:

Los valores e interfaz se basan en plantillas administrativas. Realizan cambios en el Registro según las indicaciones de la plantilla. Hay secciones especiales de las ramas del Registro que se controlan mediante Directivas, conocidas como las verdaderas. En caso de valores de Equipo:

    • HKEY_LOCAL_MACHINE\SOFTWARE\policies
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

y para el Usuario:

    • HKEY_CURRENT_USER\SOFTWARE\policies
    • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

Cada vez que el sistema procesa una Directiva y obtiene el RSOP, estas ramas del Registro (claves y valores) son borrados y reescritos con la nueva RSOP. Esto pasa sólo en la medida que una Directiva de grupo válida se sigue aplicando al equipo o usuario.

Finalmente, podemos crear nuestros propios valores de Directiva modificando una de las plantillas administrativas existentes o creando una nueva. Esto nos permite trabajar con el Registro completo (exceptúando las ramas mencionadas antes). Sin embargo, es muy importante advertir que estos valores tatuarán el Registro. En otras palabras, los valores quedarán establecidos permanentemente hasta que específicamente los revertamos en la Directiva. Esto significa que si eliminamos nuestra Directiva, este tipo de valores no desaparecen y debemos revertirlos a mano.

Preferencias:

Introducidas desde MS Windows 2008, nos proporcionan una alternativa al uso de scripts para realizar tareas comunes. Estas tareas, en todo caso, no eran fáciles de hacer en las Directivas. Las preferencias nos permiten ahora modificar valores del Registro Local, grupos y usuarios locales, archivos y carpetas, impresoras, servicios locales, unidades de red, y otros muchos valores locales. Ya que las Preferencias no son obligatorias, los usuarios pueden realizar cambios. Además, son de utilidad para aplicaciones a las que las Directivas no cuenta y valores del sistema. Sin embargo, siempre que un usuario decide cambiar algo, lo más probable es que no disponga del permiso necesario para hacerlo ya que la mayoría de las Preferencias requieren algún tipo de credenciales administrativas.

También podemos aplicar elementos de preferencias individuales mediante el filtrado de Directivas, aunque de forma distinta a las Directivas verdaderas, ya que en las segundas no podemos individualizar valores dentro de la Directiva.

En Windows Server 2008 R2, la edición de Preferencias se ha mejorado.

Veamoslo con un ejemplo:

Hasta ahora, yo mismo usaba un script de vbs para asignar unidades de red e impresoras a los usuarios, por ejemplo:

Dim oNet
Set oNet = CreateObject("WScript.Network")
ONet.MapNetworkDrive "Z:", "\\SRVDOMpruebas\compartido"
Set WshNetwork = CreateObject("WScript.Network")
PrinterPath = "\\SRVDOMpruebas\hpbusiness"
PrinterDriver = "HP BUSINESS injeck 1000"
WshNetwork.AddWindowsPrinterConnection PrinterPath, PrinterDriver
WshNetwork.SetDefaultPrinter "\\SRVDOMpruebas\hpbusiness"

Una unidad mapeada como Z que apunta al recurso ‘compartido’ y una impresora instalada en SRVDOMpruebas denominada hpbusiness, que ademas se establecía como predeterminada.

Bien, ahora esto podemos hacerlo con una GPP , es decir, Group Policy Preferences o Preferencias de Directiva de Grupo.

Crear una GPP es como crear una GPO, abrimos la consola de Administración de Directivas y vamos con el ejemplo.

  1. Seleccionamos Objetos de Directiva de Grupo, clic derecho y NUEVA, le damos un nombre descriptivo y dejamos el origen como sale.
    newGPOPreferences00newGPOPreferences01
  2. Clic derecho en la nueva directiva y Editar.
    newGPOPreferences02
  3. Unidad de red:
    1. En el editor escogemos la ruta, Configuración de Usuario|Preferencias|Configuración de Windows|Unidades de red, clic derecho, Nueva Unidad y seguimos el asistente.
      newGPOPreferences03
    2. El valor de Acción es lo más importante, cuatro posibilidades:
      1. Crear. La preferencia se configurará si la configuración no existe, por el contrario si ya existe, no se realizará ninguna acción.
      2. Reemplazar. Se elimina y se recrea de nuevo la configuración.
      3. Actualizar. La más poderosa, con ella lo hacemos todo, lo crea si no existe y si existe la actualiza.
      4. Eliminar. Se quita la configuración.
      newGPOPreferences05newGPOPreferences04
    3. Realizada la configuración como queda en la imagen, seguimos con el siguiente paso, configurar a qué usuarios les afectará la preferencia. (En este caso, esta es una de las dos configuraciones que residirán en la misma GPO que se enlazará a los usuarios de una OU, la otra es la impresora.) Para elegir los destinatarios de la OU receptora que pertenecerán al grupo ‘pruebas’.
      1. Pestaña ‘Comunes’.
        newGPOPreferences06
      2. Marcar la casilla ‘Destinatarios de nivel de elemento’.
      3. Pulsar el botón ‘Destinatarios’.
    4. Aquí tenemos el Editor de Destinatarios, vamos a individualizar, en este caso usuarios pero podríamos hacerlo con equipos también.
      1. En este caso los destinatarios son los usuarios del grupo pruebas, Nuevo elemento, grupo de seguridad.
        newGPOPreferences07
        newGPOPreferences08
      2. Pulsamos en el botón y elegimos el grupo.
        newGPOPreferences09
      3. Aceptar para finalizar la configuración.

Aquí ya tenemos la UNIDAD DE RED en Z:\, equivalente a la primera parte del script de ejemplo.

Para añadir la impresora realizaremos los mismos pasos, pero esta vez elegiremos Impresora compartida.

newGPOPreferences10 newGPOPreferences11

Y también escogeremos los destinatarios, en este caso por rango de IP.

 newGPOPreferences12

Juansa©2011

PowerSE Professional, editor scripts powershell free.

  powerSE01

Conocida herramienta de edición de scripts de PowerShell de Devfarm Software, Al parecer PowerSE está disponible gratuitamente ahora. PowerSE está diseñada para administradores, con el ánimo de ayudarles en las tareas diarias. PowerSE dispone de todas las características de los editores de gama alta, como remarcar con colores la sintáxis, Intellisense, y tabulación completa, pero lo que lo hace especial es la conjunción perfecta de editor y consola de comandos de PowerShell.

powerSE02

 

 

2008 R2: Automatizando tareas administrativas: Powershell(5)

Copiar y guardar los eventos, y al tiempo limpiar el registro.

Hay que descargarse la extensión Pscx-2.0.0.1.zip desde http://pscx.codeplex.com, y extraerla en el directorio de modulos del usuario: ‘Mis Documentos\WindowsPowerShell\Modules’, o en el directorio de modulos de PS, valor que devuelve la variable $PSHome desde el ISE, en mi caso:

variablePSHOME

El Script en castellano (más o menos).

<#
   .Sipnosis
    Este script guarda los log de Eventos
   .Descripción
    Se puede ejecutar de forma periódica (regularmente) para el archivo o copia de los log de eventos
    NB, este script los guarda y limpia el registro de eventos, no solamente hace una copia de seguridad.
    El script se ha diseñado con el ánimo de investigar y auditar los log de seguridad.
    De hecho copia los log en memoria, y luego los borra, y entonces los guarda en archivos csv,
    por ello se recomienda ejecutarlo de forma local o vía PS en remoto.
   .Ejemplo
    .\Inicia-copiasegEventLogs.ps1
   .Entradas
    Ninguna
   .Salidas
    Ninguna
   .Notas
    Nombre: Inicia-copiasegEventLogs.ps1
    AUTHOR: Benjamin R Wilkinson
    TRADUCCIÓN y ADAPTACIÓN CASTELLANO: Juansa
    DESARROLLADO: Mediante Windows PowerShell ISE.
    VERSIÓN: 1.0.0
    ULTIMA EDICIÓN: 20/07/2010
    CLAVES:
   .Link
#>
#Se requiere -Versión 2.0
[CmdletBinding()]
Param
   (
    [Parameter(Mandatory=$false,
               ValueFromPipeline=$true,
               ValueFromPipelineByPropertyName=$true)]
    [String]
    $computer = "$ENV:COMPUTERNAME",           
    [ValidateSet("Application", "Security", "System")]
    [Alias("l","log")]
    [String]
    $LogName = "Security",
    #$LogName ="Application"
    #$LogName ="System"
    #$MinBackupSize = "209715200", # 200MB
    #$MinBackupSize = "204472320", # 195MB
    $MinBackupSize = "1024", # 1MB
    [String]$BackupLocal = "D:\TEMP",
    [String]$Backupremote = "D:\COPIALOGS"
    #[String]$Backupremote = "\\ADTEST04\logs\seclogs"
    #[String]$Backupremote = "\\srvpl01\COPIALOGS"
   )#End Param
Begin
{
# El cmdlet para exportar a zip es de: http://pscx.codeplex.com/
Import-Module PSCX
Write-Host "Procesando $Logname Logs .. .. Server:"$computer (get-date)
}
Process
{
    $BaseDirLocal = "$BackupLocal\{0:yyyy_MM}-Logs" -f [DateTime]::now
    $LogFileName = "{0}-{1:yyyyMMdd_HHmm}-{2}.csv" -f $Computer,[DateTime]::now,$LogName
    $PathLocal = Join-Path -Path $BaseDirLocal -ChildPath $LogFileName
    Write-Host "  + Procesando $LogName Log"
    Write-Host "    – Leyendo $LogName Log"
   
    $Query = "Select * from Win32_NTEventLogFile where LogfileName = ‘$LogName’"
    if ((Get-WmiObject -Query $Query -ComputerName "localhost").FileSize -gt $MinBackupSize)
       {
        #Guarda los log a un Objeto de PS en memoria
        $SecLogs = get-eventlog -LogName $LogName
       
        #Limpia los log de eventos
        Write-Host "    – Limpiando $LogName Log"
        Clear-EventLog -LogName $LogName
       
        # Se asegura que existe el directorio local
        If(!(Test-Path $BaseDirLocal))
        {
          New-Item $BaseDirLocal -type Directory -force | out-Null
        }
        Write-Host "    – Exportando a CSV"
       
        # Exporta desde la memoria a CSV
        $SecLogs | ForEach-Object {$RString = $_.ReplacementStrings | ForEach-Object {$_}
        $Hash = @{            
        EventID       =$_.EventID
        MachineName   =$_.MachineName
        Category      =$_.Category
        CategoryNumber=$_.CategoryNumber
        EntryType     =$_.EntryType
        ReplStrings   ="$RString"
        TimeGenerated =$_.TimeGenerated
        UserName      =$_.UserName}
        New-Object PSObject -Property $Hash
        } | Export-Csv -Path $PathLocal -NoTypeInformation
        Write-Host "    – exportación a CSV completada"
       
        # Empaquetar en Zip
        Write-Host "    – Empaquetando Zip"
        $ZipLogArchiveFile = Get-ChildItem $PathLocal | write-zip -level 9
        if (Test-Path -Path $ZipLogArchiveFile)
        {
         Remove-Item -Path $PathLocal
        }
       
        # Copia los Log/CSV a carpeta compartida
        $BaseDirRemote = "$Backupremote\{0:yyyy_MM}-Logs" -f [DateTime]::now
        If(!(Test-Path -Path $BaseDirRemote))
        {
          New-Item $BaseDirRemote -type Directory -force | out-Null
        }
       
        # Elimina el archivo anterior
        If(Test-Path -Path $BaseDirLocal)
        {
          # Mueve todos los archivos desde el directorio local y lo limpia
          Write-Host "    – Archivando en Zip:"$ZipLogArchiveFile.Name
          Move-Item "$BaseDirLocal\*.zip" -Destination $BaseDirRemote -Force
          Remove-Item -Path $BaseDirLocal
        }
       }
    else
       {
        $Skip = $True
       }   
}
End
{
if (!$Skip)
    {
     $Msg = "Proceso de $LogName log completado, hay {0} logs exportados." -f $SecLogs.count
     $Msg2 = "Logs guardados a {0}\{1}" -f $BaseDirRemote, $ZipLogArchiveFile.Name
     Write-Host $Msg
     Write-Host $Msg2
     (get-date)
    }
else
    {
     Write-Host "El tamaño de los Log es menor de $($MinBackupSize/1MB) MB, no se realizan cambios"
    }
$Skip = $Null
}

limpiasecuritylog




Este scrip nos sirve para vaciar los logs. En el ejemplo lo hace con el de seguridad, pero podemos cambiar el valor de la variable $LogName a Application o System.



Por supuesto hay otras variables a explicar:



$LogName Security, Application o Security



$MinBackupSize Tamaño mínimo del registro de Seguridad, Aplicación o Sistema para realizar la copia, guardado y limpieza.



$BackupLocal Directorio local donde se vuelca la info a archivos CSV que serán empaquetados en zip y eliminados de dicho directorio (temporal)



$BackupRemote Directorio donde se guarda el zip empaquetado con el CSV.

2008R2: Automatizando tareas administrativas: powershell(4)

Variables, Alias, Ámbitos, perfiles y seguridad.

Variables en powershell

Una variable en un lugar de almacenamiento de datos. En muchos shells los únicos datos que pueden almacenarse en una variable son de tipo texto. En shells avanzados y lenguajes de programación, estos datos pueden ser de cualquier tipo, desde cadenas de texto a secuencias de objetos. Powershell es de los segundos, puede almacenar cualquier tipo.

Para definir una variable en powershell debemos nombrarla con el signo dolar $ como prefijo que nos ayuda a definir variables de álias, cmdlets, archivos y otros elementos que el usuario del shell quiera utilizar. El nombre de una variable puede contener cualquier combinación de carácteres alfanuméricos (a-z, 0-9) y el subrayado (_). Aunque no hay establecida una nomenclatura en los nombres de variables en powershell, no deja de ser interesante utilizar un nombre que refleje el tipo de datos que contiene la variable.

powershellVariable

En el ejemplo he usado el ISE, he definido una variable $Detenido cuyo contenido es una colección de servicios donde su estado es Detenido.

Alias

En Powershell, como en la mayoría de shells de línea de comandos, se pueden definir alias de comandos. Es un método de ejecución de comandos del shell (cmdlets) usando un nombre diferente. En todo caso la razón del uso de alias es por la reducción de carácteres en el nombre a usar y reducir lo que se escribe.

Por ejemplo: en lugar de usar get-process usar sólo gps. Este es un alias predefinido, hay otros: con el cmdlet get-alias obtenemos la lista de los predefinidos.

Pero en Powershell disponemos de varios cmdlets que nos permiten definir nuevos alias, exportarlos, importarlos y como el dicho anteriormente, mostrarnos una lista de los existentes. La lista de estos cmdlets también la podemos obtener con otro cmdlet:

powershellalias

Con get-alias obtenemos una lista de alias disponibles en la sesión actual, todos los predefinidos y los que hayamos creado nosotros, export-alias e import-alias nos servirán tanto para exportar como para importar la lista entre sesiones, mientras new-alias y set-alias nos permiten definir nuevos alias en la sesión actual.

Los alias creados mediante los dos últimos cmdlets son válidos únicamente en la sesión actual. Para disponer de alias persistentes entre sesiones de powershell se han de definir en un archivo de perfil, en cada línea un alias:

set-alias nuevo new-object

set-alias hora get-date

Y aunque el uso de comandos cortos no deja de tener su encanto, un uso indiscriminado no es muy recomendable. Primero porque los alias no son tan portables como los scripts, imaginad: un script lleno de alias, cada uno de ellos debe incluirse mediante set-alias al principio del script para asegurarse que todos los necesarios están presentes, independientemente del equipo o del perfil de la sesión, cuando se ejecute el script. Hay que reconocer que una concentración grande de alias pueden causar confusión en comandos y scripts. Los alias definidos podrían tener sentido para un programador, pero no todos comparten esa lógica en la definición de alias. Así qué, si uno quiere que otros entiendan sus scripts, cuantos menos alias mejor, o en todo caso alias entendibles y claros.

Ámbitos

Un ámbito o alcance es un límite lógico donde Powershell aisla el uso de funciones y variables. Los ámbitos se pueden definir como: global, local, script y private. Funcionan en una jerarquía en que la información del ámbito se hereda descendentemente, es decir, el ámbito local puede leer del ámbito global, pero no al revés.

global

Como su nombre indica, el ámbito global se aplica a toda la instancia de powershell. Los datos se heredan por todos los ámbitos hijo, comandos, funciones o scripts que se ejecutan usando variables definidas en global. Sin embargo, tened en cuenta que no se comparten ámbitos globales entre instancias de powershell.

powershellscopesglobal

local

Un ámbito local se crea dinámicamente cada vez que se ejecuta una función, filtro o script. Después de la ejecución, la información se descarta. Puede leer información del ámbito global, pero no realizar cambios. Veamos el mismo ejemplo anterior pero en forma local.

powershellscopeslocal

script

El ámbito de script se circunscribe a la ejecución del script y acaba cuando éste finaliza. Veamos un ejemplo:

powershellscopescript

Cuando ListaServicio.ps1 se ejecuta, la información guardada en la variable $Servicios (el primer servicio) se muestra en el panel de salida. Pero al intentar acceder a la información de la variable desde la consola con $Servicios[0] se devuelve un error, ya que la variable sólo es válida en el ámbito del script. Cuando finaliza el script, el ámbito y todo su contenido es descartado.

¿Qué pasa si un administrador quiere usar un script en un Pipeline o acceder como a un archivo de biblioteca en busca de funciones comunes? Normalmente esto no es posible ya que powershell descarta el ámbito de script en cuanto éste script finaliza. Por suerte, Powershell admite la técnica del punto-origen (dot-sourcing), un término original de UNIX. Aplicarla a un script hace que Powershell cargue el ámbito de script dentro del ámbito padre de la llamada. Para usarla, simplemente hay que añadir el prefijo (.) punto al nombre del script cuando se ejecute, algo como: PS C:\> ..\script.ps1

private

Parecido al ámbito local pero con una diferencia clave: Las definiciones en el ámbito privado no son heredadas por ningún ámbito hijo. Qué mejor que verlo en un ejemplo, siguiendo el hilo de los anteriores.

powershellscopeprivate

El ejemplo se ejecuta porque usa el operador de llamada &. Con este operador, podemos ejecutar fragmentos de código script en un ámbito local aislado. Esta técnica es útil para aislar un bloque del script y sus variables de un ámbito padre o, como vemos aquí, separar una variable de ámbito privado de un bloque del script.

Perfiles

Un perfil de powershell no es más que una colección de valores guardados para personalizar el entorno de powershell. Hay varios tipos de perfiles, cargados en un orden específico cada vez que powershell se inicia.

todos los usuarios todos los hosts

Debe ubicarse en %windir%\system32\windowspowershell\v1.0\profile.ps1 (1). Los valores de este perfil se aplicarán a todos los usuarios de powershell en el quipo actual.

todos los usuarios host actual

Debe ubicarse en %windir%\system32\windowspowershell\v1.0\ShellID_profile.ps1 (2). Se aplican a todos los usuarios del shell actual (de forma predeterminada la consola).

usuario actual todos los hosts

Debe ubicarse en %userprofile%\My Documents\windowspowershell\profile.ps1 (3). Aquéllos usuarios que desean controlar su propio perfil pueden utilizar este tipo. Se aplica sólo al usuario actual de la sesión de powershell y no afecta al resto.

usuario actual host actual

 Debe ubicarse en %userprofile%\My Documents\windowspowershell\ShellID_profile.ps1 (4). Como el perfil todos de host específico, este tipo carga valores para el shell actual, aunque los valores son de usuario específico.

Hay otros perfiles, por ejemplo para el ISE, usuario actual ISE(5) o todos los usuarios ISE(6).

Antes de crear un perfil: get-help about profiles

(1) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force}

(2) if (!(test-path $profile )) {new-item -type file -path $profile -force} Desde la consola de Powershell.

(3) if (!(test-path $profile.CurrentUserAllHosts)) {new-item -type file -path $profile.CurrentUserAllHosts -force}

(4) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force} Desde la consola de Powershell.

(5) if (!(test-path $profile )) {new-item -type file -path $profile -force} Desde el ISE.

(6) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force} Desde el ISE.

Si deseamos editar el perfil desxe el ISE: psEdit $profile

powershellprofile

Aunque en este caso no me lo edita porque no existe.

SEGURIDAD

Cuando se liberó WSH con Windows 98 (ufffff), fue un regalo para los administradores que buscaban capacidades de automatización como sus hermanos UNIX. Pero al mismo tiempo, los viruseros descubrieron rápidamente que abría un gran frente de ataque contra los Windows.

Casi cualquier cosa de un sistema Windows puede automatizarse o controlarse con WSH, lo cual es una ventaja para administradores. Pero WSH no aporta ningún tipo de seguridad en la ejecución de scripts. Le das un script y lo ejecuta. De donde proviene o cual es su propósito no importa. Con este comportamiento WSH es más conocido como una vulnerabilidad que como una herramienta.

Con todas las críticas contra la seguridad de WSH, el equipo de diseño de powershell decidió incluir una directiva de ejecución para mitigar las amenazas de seguridad que plantea el código malicioso. Una directiva de ejecución define restricciones en cuanto a Cómo permite ejecutar los scripts o que archivos de configuración se cargan. Powershell tenía cuatro directivas de ejecución principales: Restricted, AllSigned, RemoteSigned y Unrestricted. Algo como: Restringida, Todos firmados, Remotos firmados y Sin restricción.

De forma predeterminada Powershell está configurado para ejecutarse bajo la Restringida. La más segura y qué sólo le permite ejecutarse en modo interactivo. Nada de scripts, y archivos de configuración firmados digitalmente por un emisor de confianza.

Todos firmados es la inmediatamente inferior a Restringida. Significa que los scripts y archivos de configuración deben ir firmados digitalmente por un emisor de confianza para ser cargados o ejecutados.

La directiva de Remotos firmados está pensada para evitar la ejecución de scripts y archivos de configuración remotos que no estén firmados digitalmente, pero que no será necesario si los mismos son locales.

Y la última y como su propio nombre sugiere: Sin restricción, permite la ejecución y/o carga de scripts y archivos de configuración. Locales y firmados, aunque a los remotos les antecede una opción para elegir si se ejecuta o no.

Con la liberación de powershell 2.0, se añadieron las directivas Bypass y Undefined.

Con la primera, Bypass, no se bloquea nada y además no hay avisos ni preguntas para elegir.

Undefined que no existe ninguna directiva definida en el ámbito actual, y si esta es la que hay para todos los ámbitos entonces la directiva es la Restringida.

Configurar la directiva de ejecución

De forma predeterminada la directiva es la Restringida, si queremos cambiarla usaremos el cmdlet Set-executionPolicy. (También podemos usar la Directiva de Grupo para establecer la directiva de ejecución en varios equipos).

Vamos a cambiar la directiva mediante el ISE, primero vemos la que hay get-executionpolicy, y el resultado es Unrestricted. Vamos a establecerla en Set-executionpolicy AllSigned… Por seguridad nos envía una ventana de confirmación, le damos al Sí y …¿qué pasa?

cambiarexecutionpolicy

cambiarexecutionpolicyNODEJA

No la cambia y nos lanza una serie de mensajes y advertencias. El acceso es denegado. Bien, lo que sucede es que hemos de iniciar el ISE con el comando Ejecutar como Administrador, veamos ahora:

cambiarexecutionpolicy02

Sin ningún problema, está cambiada sin errores.

2008 R2: Automatizando tareas administrativas: powershell(el ISE)

Powershell ISE

powershellISE02

Otra de las características introducidas con Powershell 2.0 es el denominado Entorno de scripting integrado(ISE). Aplicación Host basada en WPF (Windows Presentation Foundation) para Powershell. Mediante el ISE podemos ejecutar comandos y escribir, probar y depurar scripts. Entre sus cualidades nos encontramos con:

> Un panel de comandos para ejecutar interactivamente comandos.

> Un panel de script, para escribirlos, editarlos y ejecutarlos. Se pueden ejecutar completos o sólo las líneas seleccionadas.

> Un panel de salida con desplazamiento que muestra una copia de los comandos desde su panel, scripts desde el suyo y sus resultados.

> Hasta ocho entornos de ejecución de Powershell independientes en la misma ventana, cada una con sus propios comandos, scripts y salidas.

> Edición multilínea en el panel de comandos, que nos permite pegar múltiples líneas de código, ejecutarlo, y rellamarlo como una unidad.

> Depurador integrado para la depuración de comandos, funciones y scripts.

> Características personalizables que nos permiten ajustar colores, fuentes y capas.

> Un modelo de objeto de script que nos permite más personalización y así extender el ISE.

> Números de línea y columna, atajos de teclado, completar tabulaciones, ayuda sensible al contexto y compatibilidad con Unicode.

El ISE de Powershell es una característica opcional en Windows Server 2008 R2. Para usarlo debe instalarse desde Añadir Características. El Administrador del Servidor instalará los requerimientos necesarios, .NET framework 3.5 SP1.

agregaISEagregaISE02

agregaISE03agregaISE04

agregaISE05

Luego podremos acceder desde Inicio, accesorios, Windows Powershell, con dos accesos:

agregaISE06

El título de la ventana nos dirá en qué entorno estamos.

agregaISE08

Los requisitos para usar el ISE:

- XP o posterior.

- .NET Framework 3.5.

ISEpowershellXP01ISEpowershellXP02

ISEpowershellVista01ISEpowershellVista02

Centro de Administración de Active Directory

Una de las nuevas herramientas incorporadas en Windows Server 2008 R2 es el Centro de Administración de Active Directory o ADAC, dicen que para facilitarnos la vida. Con esta herramienta podemos realizar diversas tareas administrativas, además de crear usuarios y grupos.

Desde Inicio, Herramientas Administrativas, Centro de Administración de Active Directory:

ADAC01

ADAC02

ADAC03

Es una herramienta intuitiva y fácil de ejecutar. Son unos paneles personalizablesque representan la mayoría de tareas que podemos llevar a cabo. Podemos añadir/quitar paneles y personalizar la vista general de la página para ayudarnos a encontrar rápidamente las tareas que más frecuentemente realizamos.

Uno de sus usos es la búsqueda de diversos objetos en AD.

Podemos crear usuarios nuevos:

ADAC04

ADAC05

También grupos:

ADAC06

ADAC07

O tener una visión de las propiedades en un interfaz mejorado.

ADAC08

ADAC09aADAC09b

Podéis experimentar con ella, Somriure

2008 R2: Automatizando tareas administrativas: powershell(3)

Trabajar en remoto con powershell.

Una de las carencias de powershell 1.0 era la falta de un interfaz para ejecutar comandos en una máquina remota, y aunque con WMI y pocos cmdlets podíamos conectar con un equipo remoto, la verdad es que había una ausencia clara de dicha característica. Así nace la característica ‘Remoting’ en Powrshell 2.0.

Como el propio nombre sugiere, es una característica diseñada para la ejecución de comandos (o scripts) en equipos remotos. Esto puede significar la ejecución de uno o varios comandos en una o miles máquinas remotas. Además, los comandos pueden ser emitidos de forma síncrona o asíncrona, uno cada vez o a través de una conexión persistente llamada runspace, e incluso programados o silenciados.

Para uitilizar Remoting hemos de tener los permisos apropiados para conectar con el equipo remoto, ejecutar powershell y ejeutar los comandos deseados. Complementariamente el equipo remoto debe tener Powershell 2.0 y WinRM instalados, además de powershell configurado para remoto.

Cuando usamos Remoting, la sesión que utilicemos para ejecutar comandos determina el entorno propio de ejecución. Los comandos pues están sujetos a las directivas de los equipos remotos, los perfiles y preferencias.

*Los comandos ejecutados contra un equipo remoto no tinen acceso a la información contenida en nuestro perfil local, así qué, los que usen funciones o alias definidos en nuestro perfil local, fallarán estrepitósamente si no están definidos en el equipo remoto.

Cómo

Básicamente Powershell mantiene una conversación que fluye entre un cliente (el equipo con la sesión de powershell) y un servidor (el equipo remoto) contra el que queremos ejecutar los comandos:

> Un comando es ejecutado en el cliente.

> El comando es transmitido al servidor.

> El servidor ejecuta el comando y devuelve su salida al cliente.

> El cliente muestra en pantalla o utiliza la respuesta devuelta.

En un nivel profundo, powershell remoting es muy dependiente de WinRM para facilitar el intercambio de comandos y respuestas entre cliente y servidor. WinRM es un componente de Windows Hardware Management, un servicio basado en web que nos habilita enumerar información y manipularla en un equipo remoto. Para el manejo de sesiones remotas, WinRM fue desarrollado según el protocolo estándar basado en SOAP denominado WS-Management. Este protocolo es muy compatible con los cortafuegos, y se desarrolló primeramente para el intercambio de información de administración entre sistemas que pueden estar basados en diversos sistemas operativos y en varias plataformas de hardware.

Cuando Powershell usa WinRM para enviar/recibir comandos/respuestas entre cliente/servidor el intercambio se realiza mediante series de mensajes XML. El primero de ellos es una solicitud al servidor, conteniendo el comando a ejecutar. Esta solicitud se envía mediante el protocolo SOAP. El servidor como respuesta ejecuta el comando en una nueva instancia de Powershell denominada runspace. Completada la ejecución el resultado va de regreso al cliente en un segundo mensaje XML, también con SOAP.

El motivo del uso de XML es porque no pueden enviarse directamente objetos .NET por la red. Así que para llevar a cabo la transmisión, los objetos se serializan dentro de series de elementos de datos XML(CliXML). En cuanto el cliente/servidor reciben la transmisión, el mensaje XML se convierte en un tipo de objeto desserializado. El objeto resultante no dura demasiado. En vez de eso, es un registro de propiedades en un momento exacto y como tal carece de cualquier método.

Requerimientos

En ambos equipos, el local y el remoto:

> Powershell 2.0 o superior.

> Microsoft .NET Framework 2.0 o superior.

> Windows Remote Management 2.0(Incluído en Windows 7 y 2008R2, hay un paquete de instalación para Vista y 2008)

Configuración

De forma predeterminada WinRM está instalado en todos los Windows Server 2008R2 como parte del propio sistema operativo. Sin embargo, no se encuentran habilitadas las conexiones remotas por cuestiones de seguridad. Podemos utilizar algunos métodos para configurar el Remoting, por ejemplo:

> Usando el cmdlet enable-psremoting (mediante la opción EJECUTAR COMO ADMINISTRADOR):

remotingPS01

inicia el servicio WinRM y configura su inicio en automático; crea una escucha para aceptar solicitudes de cualquier IP; Añade una excepción el el cortafuegos para las comunicaciones vía WS-Management.

Habilita la configuración de las sesiones registradas de PS para recibir instrucciones desde un equipo remoto.

En caso de no estar registrada la configuración de PS, lo hace ahora.

Si los equipos son de 64 bits, también registrará, si no lo está aún, la configuración del PS32.

Quita el valor ‘denegar todos’ del descriptor de seguridad de todas als configuraciones de sesiones registradas.

Reiniciará el servicio WinRM para que tomen efecto todos los nuevos cambios.

> Desde el Administrador del Servidor:

    1. Abrimos la consola
    2. en el área resumen, clic en Configurar Administración remota del Administrador del servidor.
      remotingServerManagement01
    3. Siguiente, Marcar la casilla Habilitar la administración remota de este servidor desde otros equipos.
      remotingServerManagement02
    4. Aceptar

> Usando una GPO:

  1. Creamos una nueva gpo (o editamos una), yo he creado una nueva.
    remotinggpo01remotinggpo02
  2. Expandimos Configuración de equipo, Directivas, Plantillas Administrativas…, Componentes de Windows, Windows Remote Management, seleccionamos Servicio WinRM.
    remotinggpo03
  3. Clicamos en Permitir configuración automática de escucha del panel derecho, habilitamos y definimos los filtros IPv4 e IPv6 con ‘*’.
    remotinggpo04
  4. Aceptar
  5. Después expandimos Configuración de equipo, Directivas, Configuración de Windows, Configuración de Seguridad, Firewall de Windows con seguridad avanzada.
    remotinggpo05
  6. Clic derecho en Reglas de entrada, Nueva regla.
    remotinggpo06
  7. En el asistente: Seleccionamos Predefinida y del desplegable Administración remota de registro de eventos, siguiente.
    remotinggpo07
  8. Siguiente para aceptar las nuevas reglas.
    remotinggpo08
  9. En la página de Acción: marcamos permitir la conexión y pulsamos en Finalizar.
    remotinggpo09
  10. Repetir los pasos de creación para los tipos predefinidos: Administración Remota de Servicios y Administración remota de Firewall de Windows.
    remotinggpo10

2008 R2: Automatizando tareas administrativas: powershell(2)

Al hilo de Inicio con powershell, vamos a intentar dar algunas nociones, aunque de antemano os diré que alguien que está mucho más versado en el tema que yo puede sacaros del agluna duda en Foro scripting del WWP.

SHELL

Un Shell es un interfaz que permite a los usuarios interactuar con el Sistema Operativo. No se considera una aplicación debido a su innegable naturaleza, pero es como cualquier otro proceso en ejecución del sistema. La diferencia entre uno y otro es que el propósito del Shell es permitir a los usuarios la ejecución de OTRAS aplicaciones. En algunos S.O. (UNIX, LinuX, VMS…), el Shell es un interfaz de línea de comandos (CLI), en otros (Windows, MAC OS) es un interfaz gráfico (GUI).

Tanto CLI como GUI tienen beneficios como inconvenientes. Muchos CLI permiten potentes comandos encadenados, salidas o resultados de la aplicación de un comando hacia otro comando, se conoce como PIPELINE o entubamiento. Los GUI sin embargo, necesitan que sus comandos sean autónomos de por sí (contenidos en sí mismo). Además, la mayoría de GUI son fáciles para navegar en contra de los CLI, donde el conocimiento del shell es un requisito necesario para encadenar comandos y navegar fluídamente. Así qué, la elección de qué Shell usar depende de nuestro nivel de confort y cuál será el mejor para llevar a cabo la tarea manual.

Si alguien quiere empaparse de la Historia de los SHell,  la wikipedia.

Vista rápida de powershell

WSH se introdujo como estándar en Windows, queriéndose ofrecer como una alternativa robusta y eficiente a los scripts de DOSShell. Desafortunadamente WSH presenta muchos retos sin llegar realmente a la experiencia de Shell que UNIX y Linux ofrecen y que muchos administradores envidiaban o envidian aún…

Jeffrey Snover, que por cierto conocí en Redmon durante su primera presentación de powershell en el Microsoft MVP Global Summit 2008, es el arquitecto junto a otros del Team de powershell. Ellos han hecho posible lo que Windows pedía: un CLI fuerte, seguro y robusto para administrar el sistema. Diseñado como un shell de acceso completo a las bases de Windows mediante .NET Framework, COM y otros métodos. Proporciona también un entorno de ejecución familiar, fácil y seguro. Powershell, su nombre quiere indicar power into windows shell, la potencia en el shell de Windows. Aquéllos deseosos de automatizar tareas deben indagar en este shell, que auna la potencia de WSH  con la familiaridad de un CLI.

Powershell proporciona un lenguaje de scripting nativo potente, tanto que los scripts pueden portarse a todos los Windows sin preocupaciones de si un lenguaje particular está o no instalado. Antes, un administrador podía tener preparados scripts en WSH, Perl, Python, VBScript, JScript, u otro, para encontrarse que en el equipo a ejecutarse no tenía el intérprete instalado. Y en los de casa ya ni comentarlo. Powershell soluciona este problema, ya que no necesita intérpretes no nativos; también nos evita la búsqueda de equivalentes a comandos para realizar simples operaciones y codificarlos en archivos cmd. Por último, powershell aborda el problema de seguridad de WSH proporcionando una plataforma para un scripting seguro. Centrándose en características e seguridad como la firma de script, extensiones no ejecutables y directivas de ejecución (muy restrictivas de forma predeterminada).

Para cualquiera que necesite automatizar tareas administrativas en un sistema Windows, Powershell proporciona una inyección de potencia muy necesaria, para que administradores o técnicos de scripting en sistemas Windows se conviertan en expertos, lo que es altamente recomendable. Después de todo, powershell puede utilizarse eficientemente en la automatización de tareas de Windows, Active Directory, Terminal Services, SQL Server, Exchange Server, IIS y muchos productos que son de terceros.

Usos

* Podemos crear, eliminar, modificar y establecer permisos en archivos y carpetas.

* Listar, detener, iniciar, reiniciar e incluso modificar Servicios.

* Listar, detener e iniciar procesos.

* Usar WMI no sólo en Windows, sino en diversas plataformas como IIS o TS.

* Usar los componentes existentes de COM para realizar un extenso rango de tareas.

* Añadir y quitar roles y características.

Características de powershell

Powershell se desvía de las interfaces de administración actuales de Windows. Como tal, se ha construido desde la base para incluir una serie de características que hacen de la administración, desde la CLI y la basada en scripts, más fácil. Algunas características clave:

  • 240 cmdlets (herramientas en línea de comandos)
  • Un lenguaje de script diseñado para fàcil lectura y uso.
  • Compatible con scripting actual, línea de comandos e interfaces de automatización, como WMI, ADSI, .NET Framework, ADO, y tantos otros.
  • Sigue una estricta convención de nombres en los comandos, basada en un formato verbo-sustantivo.
  • Compatible con diferentes sistemas operativos Windows, XP con SP2 o posterior, Windows Server 2003 con SP1 o posterior, Windows Vista, Windows 2008, Windows 7 y Windows 2008 R2.
  • Proporciona acceso directo y exploración del Registro de Windows, del almacenamiento de certificados, y el sistema de archivos usando un conjunto común de comandos.
  • Está basado en objetos, que permite a los datos ser entubados entre comandos.
  • Es extensible, que permite a terceros construir sobre el mismo y extender los interfaces de powershell para administrar Windows y otras plataformas Microsoft.
  • Desde su versión powershell 2.0 contiene la habilidad de administrar roles y características, AD domain services, AD rights management services, Applocker, BITS, Group Policy, IIS, etc…
  • Un depurador, con el que podemos identificar errores o ineficacias en scripts, funciones, comandos y expresiones mientras están siendo ejecutadas a través de un conjunto de cmdlets de depuración o con el ISE (Integrated Scripting Environment).
  • Un interfaz GUI multipestaña de desarrollo. Aquí podemos escribir, comprobar y depurar scripts. Incluye edición multilínea, tabulación, colorido sintáctico, ejecución selectiva, ayuda sensible al contexto y compatibilidad para lenguajes de derecha a izquierda.
  • Trabajos en segundo plano que nos permiten ejecutar comandos y scripts asíncronamente.
  • Permite incluir funciones de script, podemos crear nuestros propios cmdlets sin necesidad de compilar.
  • Incluye una característica denominada Módulos, que permite paquetes de cmdlets, proveedores, funciones, variables y álias ser empaquetados y poder compartirlos con facilidad con otros.
  • Se ha añadido además la compatibilidad de comandos remotos, lo que nos permite automatizar la administración de sistemas remotos mediante una consola única de Powershell.

¿Puedo ejecutar scripts powershell 1.0 en powershell 2.0?

Lo necesario

Para trabajar con powershell necesitamos entender los comandos básicos, cómo acceder a powershell y cómo trabajar desde la línea de comandos, cosa que muchos ya conoceréis.

Para acceder a Powershell:

- Inicio, todos los programas, Accesorios, Windows Powershell. Tenemos el ISE o directamente Windows powershell.

powershell-01

- También desde Inicio, escribimos powershell en buscar programas y archivos y ENTER.

powershell01

- Finalmente podemos ir a Inicio, ejecutar, escribir CMD y ENTER, desde la línea de comandos escribimod powershell y ENTER de nuevo.

powershell-03

La interfaz de línea de comandos (CLI).

La sintaxis para el uso de powershell desde la CLI es muy parecido a cualquier otro Shell. El componente principal de un comando de powershell es el propio nombre del comando a ejecutar. Este comando puede ser mucho más específico mediante el uso de parámetros y argumentos para parámetros. Lo que hace que el formato sea como:

> [comando]

> [comando]-[parámetro]

> [comando]-[parámetro]-[parámetro] [argumentoX]

> [comando]-[parámetro]-[parámetro] [argumentoX],[argumentoY]

Cuando usamos powershell un parámetro es una variable que puede aceptar el comando, un script o una función. Un argumento es un valor asignado a un parámetro. Aunque estos términos son con frecuencia intercambiados, es de ayuda recordar estás definiciones.

Moverse por el CLI.

Como con todos los Shell basados en CLI, hay una serie de operaciones asociadas a diversas teclas cuando se usa la consola de powershell.

Teclas

Operación

flechas izq y der Mueve el cursor a izquierda y derecha dentro de la línea actual del comando.
flechas  arr y aba Mueve el cursor por la lista de comandos recientemente escritos.
Re Pág Muestra por pantalla el primer comando en el historial de comandos.
Av Pág Muestra por pantalla el último comando en el historial de comandos.
Inicio Mueve el cursor al inicio de la línea de comando.
Insertar Conmuta entre el modo insertar y el de sobreimprimir texto.
Fin Mueve el cursor al final de la línea de comando.
Supr Elimina el carácter en la posición actual del cursor.
Borrar Elimina el carácter inmediatamente precedente a la posición actual del cursor.
F3 Muestra el comando anterior.
F4 Elimina un número especificado de carácteres desde el cursor actual.
F5 Se mueve atrás en el historial de comandos.
F7 Muestra una lista de los comandos escritos recientemente en un cuadro emergente dentro del shell, podemos navegar con las flechas arriba y abajo para seleccionar uno de ellos, pulsando INTRO se ejcuta de nuevo.powershellF7
F8 Movimiento hacia atrás, por el historial de comandos con comandos que coincidan con el texto introducido en la línea de comandos.
F9 Pregunta por un número de comando y lo ejecuta. (Desde el historial de comandos; el número es mostrado en la lista por F7)
TAB Autocompleta secuencias de comandos. Mayús+TAB se mueve atrás a través de una lista potencial de coincidencias.

La mayoría de lo visto en la tabla era nativo del command prompt CMD, lo que nos hace más fácil la adopción del shell de powershell.

Tipos

Cuando se ejecuta un comando en powershell el intérprete de comandos busca el nombre del comando para averiguar la tarea a realizar. Este proceso incluye determinar el tipo de comando y cómo porcesarlo. Hay cuatro tipos de comandos en Powershell: cmdlets, comandos de función, comandos de script y comandos nativos.

CMDLET

Es el primer tipo de comando, comandlet, que es parecido a los comandos de otros shells basados en CLI. La diferencia es que los cmdlets se implementan mediante las classes .NET compiladas dentro de Librerías de Enlace Dinámico (DLL) y cargadas en el runtime de powershell.Esto significa que no hay una clase fija de cmdlets desarrollados; cualquiera puede usar el SDK para desarrollar sus propios cmdlets personalizados y extender la funcionalidad de Powershell.

Un cmdlet se nombra siempre como un verbo+sustantivo separado por un guión (-). El verbo especifica la acción que el cmdlet llevará a cabo, y el sustantivo el objeto con el que operar. Por ejemplo:

powershellCMDLET

Durante la ejecución de cmdlets debemos tomar en cuenta algunas consideraciones. En conjunto, Powershell fue creado de forma en que su sintáxis es tolerante y fácil. Powershell también intenta rellenar los espacios en blanco.

> Siempre se estructuran en un formato verbo+sustantivo no plural.

> Los parámetros y argumentos son posicionales: verbo+sustantivo parámetro/argumento

> Muchos de los argumentos pueden sustituirse por comodines: get-service w*

> Se permiten nombres de parámetros parciales.

Un cmdlet ejecuta un registro a la vez.

FUNCIONES

Otro tipo de comando. Estos proporcionan una forma de asignar un nombre a una lista de comandos. Son similares a las funciones y procedimientos de otros lenguajes de programación. La principal diferencia entre un script y una función es que con un script se inicia una nueva instancia del Shell y las primeras se ejecutan en la actual instancia del mismo Shell.

(Las funciones definidas en la línea de comandos tienen efecto sólo durante la sesión actual de powershell. De ámbito local y no se aplican a nuevas sesiones de powershell.)

Aunque una función definida en la línea de comandos es una forma útil de crear series de comandos dinámicamente en el entorno de powershell, estas funciones se eliminan de la memoria cuando se cierra o reinicia powershell. Por lo tanto, aunque la creación de funciones complejas dinámicamente es posible, escribirlas como scripts es más práctico. Un ejemplo e función:

powershellFUNCTIONS

En powershell 2.0 se ha añadido unacaracterística denominada funciones avanzadas. Su premisa básica es habilitar a los administradores y desarrolladores el acceso a la misma funcionalidad de un cmdlet compilado, pero directamente a través del lenguaje de script de powershell. Por ejemplo:

powershellFUNCTIONSAVANCED

SCRIPTS

Tercer tipo de comandos, son comandos de Powershell almacenados en archivos ps1. La principal diferencia con las funciones es que los scripts se almacenan en disco y pueden llamarse en cualquier momento.

Se pueden ejecutar en una sesión de powershell o desde el prompt CMD. En el primer caso escribimos el nombre del script sin extensión. Al nombre pueden seguirle diversos parámetros. El shell ejecutará el primer ps1 que coincida con dicho nombre de los que se encuentran en la VARIABLE DE ENTORNO DE Powershell ($ENV).

Desde CMD, o ir al directorio donde se encuentra el script o usar el camino absoluto:

powershellSCRIPTS

Un detalle importante sobre los scripts de powershell es sobre las restricciones de su seguridad predeterminada. Por defecto no está habilitada la ejecución de scripts.

Esto se controla con el cmdlet Set-ExecutionPolicy.

Comandos NATIVOS

El último de los tipos de comandos, un comando nativo consiste en un programa externo que el sistema puede ejecutar. Ya que para ejecutar un comando nativo hay que crear un nuevo proceso, es el menos eficiente de los tipos. Estos suelen tener sus propios parámetros para el proceso, y normalmente son distintos a powershell.

Integración con .NET

La mayoría de shell operan en un entorno basado en texto, lo que significa que hay que manipular la salida para propósitos de automatización. Microsoft sin embargo ha cambiado esto con Powershell y en lugar de transportar datos en texto plano, los recupera en forma de objetos de .NET, lo que hace posible a los comandos o cmdlets acceder a los métodos y propiedades del objeto directamente. Lo cual simplifica el uso del shell. Simplemente nos referimos a los objetos y los manipulamos según nuestras necesidades.

La reflection es una característica de .NET Framework que permite a los desarrolladores examinar objetos y recuperar sus métodos, propiedades, campos y el resto. Ya que Powershell está construido sobre .NET Framework, nos porporciona dicha característica también con el cmdlet get-member. Este cmdlet analiza un objeto o colección de objetos que le pasamos mediane el pipeline. Por ejemplo:

powershellreflection

Los desarrolladores se refieren a este proceso como interrogación a un objeto. Puede ser muy útil para entender métodos y propiedades del objeto sin buscar en MSDN o Internet.

También hay que aprender sobre ETS(Extended Type System), las clases y métodos estáticos y el tipo de aceleradores; yo me lío bastante con tanto desarrollo Picant l'ullet

Próximamente veremos el acceso remoto y el ISE de powershell.

Directivas: Tareas administrativas 01

Antes de administrar Directivas debemos tener instaladas las herramientas, en Windows Server 2008 R2 lo están por defecto en los controladores de dominio, pero en otros sistemas deben instalarse manualmente.

Windows Server 2008 R2

Iniciamos sesión en el equipo.

Administrador del servidor, de las herramientas administrativas.

Accedemos al nodo de Características del árbol izquierdo.

Pinchamos en Agregar características del panel derecho.

Bajamos en la lista ofrecida hasta Administración de directivas y marcamos la casilla de verificación. Siguiente.

Aceptamos la selección y pinchamos en instalar.

Al finalizar la instalación cerramos la mmc.

Windows 7

Para administrar las directivas de grupo del dominio desde un Windows 7 debemos descargar e instalar como administrador las RSAT o Remote Server Administration Tools para Windows 7. Una vez lo tenemos instalado:

Iniciamos sesión en el equipo

Abrimos el Panel de Control

Programas, pinchamos en Activa o desactiva las características de Windows

Buscamos en la lista: Herramientas de administración remota del servidor y lo expandimos

Herramientas de administración de características, marcamos la casilla de Herramientas de administración de Directivas de Grupo

Aceptamos

Una vez completado cerramos el Panel de control.

RSATonW7

Ahora ya tenemos la característica accesible desde Herramientas Administrativas. (esto también instala el módulo para powershell)

RSATonW702

Administración de Directivas de Grupo con PowerShell

Sea desde Windows 7 o desde Windows Server 2008 R2 con las herramientas de Directiva de Grupo instaladas, podemos aprovechar diversos cmdlets de PowerShell para administrar Directivas de Grupo.

Abrimos PowerShell como administrador,

powershell01

Una vez en la ventana, Import –module grouppolicy Intro

powershell02

Ahora si escribimos Get-command *GP* –commandtype cmdlet obtenemos hasta 25 diferentes cmdlets de Directiva de Grupo

powershell03

Para obtener ayuda sobre uno específico, Get –help get-gporeport por ejemplo.

powershell04

Para obtener ejemplos, añadimos –example a la instrucción de solicitud de ayuda, por ejemplo Get –help get-gporeportexample

powershell05

 

Herramientas para Directivas (w2008R2)

Microsoft proporciona diversas herramientas para que podamos crear y administrar directivas locales o de dominio. La versión del sistema determina la funcionalidad que se ofrece a los administradores en su uso. Por ejemplo: si creamos una directiva con la consola de 2008/2008 R2, la carpeta de Directivas utiliza las nuevas plantillas ADMX/ADML, mientras que en XP/2003 se carga la plantilla ADM original en la carpeta de Directivas.

Repasemos las herramientas:

  • GPMC, La consola de administración de directivas de grupo.

gpmcgpmc02

La más funcional y útil de las herramientas de que disponemos para la creación y administración de las Directivas de Grupo en AD. Fue introducida después de la versión 2003; la funcionalidad incluída en los diferentes SO produce distintas opciones y resultados al crear y administrar las Directivas de Grupo.

Es un elemento de la MMC, que podemos añadir a cualquier consola personalizada. Con la proporcionada con Windows Server 2008 R2 podemos:

    • Habilitar las GPO de inicio, y crearne de nuevas.
    • Crear nuevas directivas de grupo de dominio
    • Crear nuevas directivas de grupo usando las GPO de inicio como plantillas
    • Crear y configurar vínculos de directivas a Sites, Dominios y Unidades Organizativas.
    • Ver y administrar Directivas de Grupo en dominios en el bosque AD local y de confianza.
    • Realizar copia de seguridad y restaurar una o todas las directivas en un dominio
    • Realizar copia de seguridad y restaurar una o todas las GPO de inicio en un dominio
    • Importar directivas de grupo desde dominios externos y migrar configuraciones de seguridad usando tablas de migración para asegurar una importación correcta.
    • Administrar Exigido en vínculos de directiva, y habilitar/deshabilitarlos.
    • Configurar la herencia en Sites, dominios y UOs.
    • Administrar el estado de las directivas para controlar que nodos de la directiva están habilitados/deshabilitados.
    • Crear y vincular filtros WMI para Directivas de Grupo
    • Administrar el filtrado de seguridad de Directivas de Grupo
    • Administrar la delegación y administración de seguridad
    • Administrar el orden de procesamiento en contenedores con múltiples vínculos de directiva
    • Ver todos los valores configurados de las directivas de grupo existentes y la info adicional, revisión, filtrado, delegación, y crear informes de exportación de la configuración.
    • Generar informes en HTML como resumen de configuraciones y ajustes.
    • Ejecutar el modelado de directivas para ver  cómo se aplicarán a usuarios y/o equipos en contenedores específicos.
    • Ejecutar el conjunto de resultados y ver cómo se han aplicado a usuarios y/o equipos específicos.

  • GPOE, Editor de objetos de Directiva de Grupo.

gpoegpoe02

El editor de objetos de directiva de grupo es la herramienta que utilizamos para editar las directivas de usuario y equipo locales. Cada servidor y equipo tiene una directiva de seguridad local predeterminada. A esta directiva se accede mediante el acceso directo al elemento de la MMC de directiva local de seguridad desde Herramientas administrativas. Ahora que Vista, w7, 2008 y 2008 R2 son compatibles con múltiples directivas de grupo, el editor se utiliza para administrar o crear cualquier directiva de grupo local, aparte de la predeterminada.

El editor nos sirve para ver la configuración de seguridad, los paquetes de instalación de sfotware, directivas restrictivas, scripts de usuarios y equipos y otras.

  • GPME Editor de administración de directivas de grupo.

GPMEGPME02

Para administrar directivas de grupo, se usa este editor con la misma funcionalidad que el anterior (GPOE), y alguna otra añadida. Una de las diferencias es que se incluye no sólo el nodo de valores de directiva sino que también incluye el nodo de valores de preferencia sólo accesible en dominios. Este editor se instala en Vista y W7 descargando las herramientas RSAT del service pack concreto del SO. En Windows Server 2008 y 2008 R2 se instala desde Añadir características desde Administrar el Servidor.

  • Editor de GPO de inicio.

GPO Editor

El editor de directivas de inicio se usa para editar las GPO de inicio creadas por los administradores. Esta consola sólo muestra los nodos de las plantillas administrativas bajo las secciones de Configuración de usuario y Configuración de equipo de una GPO de inicio. De forma predeterminada, los valores disponibles en las secciones de las plantillas administrativas son aquéllas que pueden establecerse en una GPO de inicio. Se incluye en las Herramientas de administración remota de servidor, RSAT.

  • Consola de impresión.

PrintManagementConsolePrintManagementConsole02

Se introdució por primera vez en Windows Server 2003 R2, la consola de impresión se usa para la gestión y administración de impresoras de impresoras en AD, equipos y servidores locales.Podemos ver las configuraciones, configurar controladores y sus opciones, y administrar los trabajos en un equipo particular o en el entorno de AD. También nos sirve para el despliegue de impresoras para equipos y/o usuarios usanto el nodo de despliegue y que es una función que extiende la funcionalidad de las Directivas de Grupo permitiéndonos el despliegue de impresoras a conjuntos predeterminados de usuarios y/o equipos a los qué está vinculada la directiva.

  • gpupdate.exe

Es una herramienta para el símbolo de sistema que nos ayuda en la resolución de problemas de procesamiento de las Directivas y de su inicio bajo demanda. Ciertas secciones de las directivas sólo se aplicarán en el inicio de un equipo o de sesión del usuario, mientras que otras se aplicarán durante los intervalos que están programados para refrescarse. Para las configuraciones que se aplican durante el arranque del equipo o los intervalos de inicio de sesión, si la conectividad de red con los DC no está disponible en ese momento los valores no se aplicarán. Así como los equipos remotos o equipos móviles, los sistemas que están hibernados o en suspensión y aquéllos usuarios que han iniciado sesión con las credenciales cacheadas.

La herramienta pues, nos ofrece la capacidad de aplicar las directivas a equipos y usuarios de inmediato. Un uso bastante extendido es añadir gpupdate.exe al script de conexión de VPN para permitir que los valores se apliquen a equipos remotos que pertenecen a la infraestructura de AD. Algunas opciones:

gpupdate.exe /Target:{equipo|usuario} Esto permite que sólo se procese el nodo específicado de la Directiva.

gpupdate.exe /Force Esto reaplica los valores de la Directiva. No reinicia el equipo o cierra sesión de los usuarios automáticamente.

gpupdate.exe /Wait Tiempo definido para el proceso completo de la directiva, de 600 segundos a 10 minutos.

gpupdate.exe /LogOff Cierra sesión del usuario después del proceso completo de la directiva.

gpupdate.exe /Boot Reinicia el equipo después del proceso completo de la directiva.

gpupdate.exe /Sync Procesa los valores que normalmente sólo lo hacen durante el arranque del equipo o el inicio de sesión del usuario. Se requieren privilegios para reiniciar el sistema o cerrar la sesión de usuario.

  • powershell

Esto requiere un estudio más profundo, pero que sepamos que MS ha introducido unos 25 cmdlets para Directivas de Grupo, que nos permiten llevar a cabo diferentes funciones desde powershell, tales como:

> Crear Directivas y Directivas de inicio.

> Crear nuevos vínculos a Directivas.

> Restaurar e importar Directivas.

> Eliminar Directivas y vínculos de directivas.

> Leer y/o establecer propiedades de una UO para que herede o bloquee las Directivas del contenedor padre.

> Renombrar Directivas.

> Crear informes de valores y configuraciones de Directiva.

> Generar informe de RSoP.

> Establecer permisos de administración de Directiva y su delegación.

> Establecer los valores y su preferencia que se almacena en el Registro.

Quizás lo importante en cuanto a powershell es saber que para que administremos o realicemos informes de cualquier Directiva, debemos conocer el GUID de la misma o el nombre exacto, y que aún hay cosas que no se pueden hacer desde powershell.

  • Microsoft Desktop Optimización Pack

Contiene diversas herramientas y características extra, pero sólo está disponible para Software Assurance.

  • Migrar plantillas ADM al nuevo formato ADMX

Desde sistemas anteriores a Windows Server 2008, es una herramienta que puede descargarse desde http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=15058

  • GPLogView

http://blogs.technet.com/b/grouppolicy/archive/2007/02/08/gplogview.aspx

Monitorizar o generar informes en texto, xml y html.

  • El todo registro del Visor de sucesos.

En Windows 7 y 2008 R2 se añaden multitud de eventos respecto a las Directivas.