Quería compartir con ustedes esta nota publicada en el blog de Microsoft “Hey, Scripting Guy! Blog” por Ed Wilson. La nota original esta en ingles, pero aquí les hago llegar una traducción. Realmente es muy buen material y puede ayudarnos con nuestras tareas de administración diarias.

Espero que les sea de interés. Saludos, Roberto Di Lello.
——-

The Admin’s First Steps: Testing Service Health

Resumen: Richard Siddaway habla sobre el uso de Windows PowerShell para automatizar las pruebas de salud a través de su patrimonio servidor.

Hey, Scripting Guy! Acabo de empezar a usar Windows PowerShell para administrar mis sistemas, y me han pedido que pruebe el servicio de salud en mis servidores. ¿Cómo puedo hacer eso? —GK -GK

Hola GK, Honorario del scripting, Richard Siddaway, aquí hoy-en reemplazo de mi buen amigo, el chico del scripting. Estás de suerte. Hoy, tengo una solución a esta cuestión como parte de mi serie sobre cómo un administrador puede empezar a hacer un uso productivo de Windows PowerShell.

Una cosa que usted verá en esta serie es que estoy usando una amplia gama de técnicas: guiones, flujos de trabajo, archivos CSV para datos, tablas hash para los datos. La idea es triple:

1. Para mostrar la mayor cantidad de técnicas diferentes, consejos y trucos que puedo.
2. Hay que destacar que casi siempre hay varias formas de lograr el resultado final con Windows PowerShell. ¿Estoy afirmando que la forma en que muestro es el mejor? Muy definitivamente no. Lo que ocurre es que el que yo pensé que era mejor cuando me senté a resolver el problema.
3. Para pasar a través del proceso de desarrollo, desde el concepto a una herramienta de administración utilizable.

Exchange Server 2007 fue el primer producto importante de la gestión que se basa en Windows PowerShell. Entre la serie de cmdlets que Exchange Server 2007 entrega era Test-ServiceHealth. Esta pequeña joya ha sido pasado por alto en la masa de la literatura de Exchange, pero la idea detrás de esto es grande: Pone a prueba un servidor de Exchange para determinar si los servicios requeridos se están ejecutando. Esto no proporciona un control de salud completo, pero si sabemos que los servicios se están ejecutando, se elimina una gran cantidad de temas. Si se ejecuta la prueba de forma remota, se obtiene un bono porque has implícitamente probado la conectividad de red a la máquina.

Te voy a mostrar cómo seguir en la tradición de los grandes administradores y robar ese concepto que se utilizará como base de una herramienta que se puede implementar en su entorno para probar otros tipos de servidores y sus servicios, de la misma forma. Podemos agregar Exchange Server en el si así lo desea mezclar a ti mismo, pero voy a usar un controlador de dominio, un sistema SQL Server y un servidor web como mis ejemplos.

Sospecho que ha utilizado Get-Service y está familiarizado con su salida (truncado aquí por razones de brevedad):

Get-Service
Status   Name               DisplayName                          
Running  AdobeARMservice    Adobe Acrobat Update Service 

Lo que no puede haber hecho es éste:

Get-Service -Name BITS,W32Time, WinRM

Status   Name               DisplayName
Running  BITS               Background Intelligent Transfer Ser…
Stopped  W32Time            Windows Time
Running  WinRM              Windows Remote Management (WS-Manag…

Los nombres de los servicios que desea ver se utiliza como filtro, por lo que restringir los datos devueltos. Observe que se utiliza el nombre real, no el nombre para mostrar. El mismo resultado se podría lograr mediante el uso de Where-Object:

$services = ‘BITS’, ‘W32Time’, ‘WinRM’
Get-Service | where Name -in $services

Filtrado después de que el hecho de no es tan eficiente, especialmente cuando se trata de máquinas remotas. Podemos llevar esto un paso más allá y poner los servicios en una lista antes de llamar a Get-Service:

$services = ‘BITS’, ‘W32Time’, ‘WinRM’
Get-Service -Name  $services

La única diferencia es que hay que poner entre comillas los nombres. En esta etapa, usted tiene la base de la prueba de la salud del servicio. Vamos a definir los servicios que desea utilizar para cada tipo de servidor:

Controlador de dominio

• Active Directory Web Services (ADWS)
• Active Directory Domain Services (NTDS)
• Key Distribution Center Service (KDC)
• Windows Time Service (W32Time)

SQL Server SQL Server

• Distributed Transaction Coordinator (MSDTC)
• SQL Server (MSSQLSERVER)
• SQL Server Agent (SQLSERVERAGENT)
• SQL Server Integration Services (MsDtsServer100)

Web server Servidor Web

• IIS Admin Service (IISADMIN)
• Windows Process Activation Service (WAS)
• WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc)
• World Wide Web Publishing Service (W3SVC)

Nota Los nombres y tipos de servicios puede variar, dependiendo de su versión de Windows.

Una de las primeras preguntas que debemos responder es: "¿Cómo voy a almacenar los nombres de servidor y la lista de servicios asociados?"

Se puede usar un archivo csv., pero luego se va a comprometer por recorrer a través de los campos de servicios o al mantener los servicios en un solo campo y dividirlos en una matriz. XML es otra alternativa, pero puede ser difícil de trabajar. Vi la siguiente técnica en el foro PowerShell.org, y pensé que podría ser útil para este escenario:

$servers = @{}
$servers += @{‘Server02’ = ‘ADWS’, ‘NTDS’, ‘Kdc’, ‘W32Time’}
$servers += @{‘W08R2SQL08’ = ‘msdtc’, ‘mssqlserver’, ‘sqlserveragent’, ‘msdtsserver100’}
$servers += @{‘WebR201’ = ‘iisadmin’, ‘was’, ‘WinHttpAutoProxySvc’, ‘w3svc’}
foreach ($key in $servers.keys){
  Get-Service -ComputerName $key -Name $servers[$key]
}

Crear una tabla hash vacía, y luego añadir una serie de tablas hash a ella donde la clave es el nombre del servidor, y el valor es una lista separada por comas de los servicios. A continuación, puede repetir las claves de tabla hash y utilizar la clave y el valor en Get-Service para recuperar los datos.

Si no te gusta la idea de poner sus datos con la secuencia de comandos, puede crear un archivo de texto que contiene los comandos para crear la tabla hash (lo llamaré servers.txt):

$servers = @{}
$servers += @{‘Server02’ = ‘ADWS’, ‘NTDS’, ‘Kdc’, ‘W32Time’}
$servers += @{‘W08R2SQL08’ = ‘msdtc’, ‘mssqlserver’, ‘sqlserveragent’, ‘msdtsserver100’}$servers += @{‘WebR201’ = ‘iisadmin’, ‘was’, ‘WinHttpAutoProxySvc’, ‘w3svc’}

A continuación, podemos modificar la secuencia de comandos para que se vea así:

Invoke-Expression (Get-Content servers.txt -raw)
foreach ($key in $servers.keys){
  Get-Service -ComputerName $key -Name $servers[$key]
}

El truco está en esta línea:

Invoke-Expression (Get-Content servers.txt -raw)

Utilizamos Get-Content para leer servers.txt. El parámetro -RAW es nueva en Windows PowerShell 3.0, y es un parámetro dinámico para el proveedor de sistema de archivos. Sólo está disponible para las unidades del sistema de archivos. The Help file states “ El archivo de Ayuda ". El parámetro -RAW ignora nuevos caracteres de línea y devuelve todo el contenido de un archivo en una cadena. De forma predeterminada, el contenido de un archivo se devuelve como una matriz de cadenas que se delimitan por el carácter de nueva línea ".

Esto significa que obtenemos una única cadena que Invoke-Expression puede ejecutar. Si se deja fuera del parámetro -RAW, obtendrá un mensaje de error.

Esto maneja los datos que vienen, pero la salida deja un poco que desear, ya que no incluye el nombre del equipo. La reacción instintiva es utilizar Add-Member para anexar el nombre del equipo en la salida. Pero antes de hacer eso, vamos a probar lo que en realidad proviene de Get-Service:

PS> Get-Service | select -f 1 | fl *
Name                : ADWS
RequiredServices    : {}
CanPauseAndContinue : False
CanShutdown         : True
CanStop             : True
DisplayName         : Active Directory Web Services
DependentServices   : {}
MachineName         : .
ServiceName         : ADWS
ServicesDependedOn  : {}
ServiceHandle       : SafeServiceHandle
Status              : Running
ServiceType         : Win32OwnProcess
Site                :
Container           :

Tenemos una propiedad llamada MachineName. En este caso, como un valor ".", Lo que indica que la máquina local. Todo lo que tenemos que hacer uso de Select-Object para anular la salida por defecto:

Invoke-Expression (Get-Content servers.txt -raw)
foreach ($key in $servers.keys){
  Get-Service -ComputerName $key -Name $servers[$key] |
  select @{N=’ComputerName’; E={$_.MachineName}},
  Name, DisplayName, Status
}

He utilizado un campo calculado para cambiar el nombre de la propiedad MachineName en ComputerName. Es posible que desee a la salida de estos datos para su uso posterior, o incluso la tubería en otro cmdlet. En ambos casos, ComputerNamees el nombre del parámetro común, por lo que la propiedad va a funcionar mejor si se cambia el nombre.

Ahora tenemos una herramienta útil para comprobar la salud de servicio en los servidores remotos. El inconveniente es que el nombre del archivo está codificado. Como último paso, vamos a hacer que un parámetro:

function test-servicehealth {
[CmdletBinding()]
param(
[parameter(Mandatory=$true,
      ValueFromPipeline=$true,
      ValueFromPipelineByPropertyName=$true)]
[ValidateScript({Test-Path -Path $_ })]
[string]$path
)
PROCESS{
Invoke-Expression (Get-Content -Path $path -Raw)
foreach ($key in $servers.keys){
  Get-Service -ComputerName $key -Name $servers[$key] |
  select @{N=’ComputerName’; E={$_.MachineName}},
  Name, DisplayName, Status
}
} # End process
}

El script se ha convertido en una función avanzada. Guardemos el código como testservicehealth.ps1 y fuente de punto a que se cargue la función, o incorporarlo en su módulo de caja de herramientas de administración. Esto significa que usted puede utilizar la función como un cmdlet. Se acepta la entrada a través del parámetros -path:

test-servicehealth -path .\servers.txt
‘servers.txt’ | test-servicehealth

La función toma un solo parámetro (-path), que es obligatorio. Cuando la ruta de acceso al archivo se prueba, se genera un mensaje de error si el archivo no se puede encontrar. Get-Content utiliza el valor del parámetro -path para abrir el archivo.

El código de trabajo tiene que estar en un proceso de bloque {} porque estamos aceptando la entrada del pipeline (marcamos el inicio, el proceso y el final en bloques para hacer el código más fácil de leer.) Ahora podemos tener un conjunto de archivos que contiene los diferentes conjuntos de servidores o servicios, y eligió el que usted necesita.

Se puede extender este concepto en un número de maneras:

• Añadir tipos de servidores adicionales, tales como servidor de archivos, DFS, DNS o DHCP.
• Crear una tarea programada para ejecutar el trabajo.
• Poner el resultado en un archivo HTML, Word o Excel.
• Enviar los resultados de uno o más administradores, especialmente si no fue un fracaso.
• Si los servicios no se están ejecutando, reinicie el servicio o incluso la máquina.

GK, eso es todo lo que hay que usar Windows PowerShell para comprobar el estado del servicio en sus servidores. La próxima vez, voy a tener otra idea para que usted intente y cuando traiga una mayor automatización en su entorno. Mientras tanto, para un mensaje muy especial pruebe esto:

(72,97,112,112,121,32,66,105,114,116,104,100,97,121,32,116,111,32,82,
105,99,104,97,114,100 | foreach {[char][byte]$psitem}) -join ""

Adiós por ahora. Richard