System Center
Windows PowerShell en System Center Operations Manager
Marco Shaw
De un vistazo:
- Shell de comandos de OpsMgr
- Proveedor de supervisión de OpsMgr
- Automatización de tareas administrativas habituales
- Algunos ejemplos reales de Windows PowerShell
Contenido
Shell de comandos de Operations Manager
El proveedor Monitoring de OpsMgr
Automatización de tareas habituales
El mundo real
Conclusión
System Center Operations Manager 2007 (OpsMgr) ha concedido acceso a los administradores a Windows PowerShell, un lenguaje de scripts nuevo y eficaz que permite automatizar tareas. En noviembre de 2006 se realiza el lanzamiento público y desde entonces se ha descargado más de dos millones de veces.
En este artículo hablaré de Windows PowerShell® y explicaré cómo se aplica a Operations Manager. Explicaré algunas de las tareas habituales que Windows PowerShell le puede ayudar a realizar de una forma más sencilla y automatizada, e indicaré algunos sitios web que proporcionan scripts y explicaciones útiles. He reunido información y entradas de blog de numerosos expertos que usan Windows PowerShell en la actualidad.
Aunque Microsoft ha comenzado el lanzamiento de versiones CTP (Community Technology Preview) de Windows PowerShell 2.0, dichas versiones no están preparadas para su uso en producción, además no se han probado con OpsMgr y no deben instalarse en un sistema de producción.
Shell de comandos de Operations Manager
En OpsMgr, se obtiene acceso a Windows PowerShell a través del shell de comandos, que es parecido al entorno predeterminado de Windows PowerShell, con la diferencia de que carga un archivo de consola y un script que inicializa el entorno con cmdlets de OpsMgr, con funciones y con una conexión predeterminada.
Puede iniciar el shell de comandos desde un icono en el menú Inicio de OpsMgr o haciendo clic con el botón secundario del mouse en un nombre de equipo en la consola de interfaz de usuario de OpsMgr (consulte la figura 1). Esto le sitúa directamente en la ruta de acceso de la unidad Monitoring de OpsMgr (que describiré en breve).
Figura 1 Abrir el shell de comandos desde la interfaz de usuario de OpsMgr (haga clic en la imagen para ampliarla)
Windows PowerShell interactúa con OpsMgr a través del SDK de OpsMgr. Por suerte para los administradores, ya se han proporcionado cmdlets para numerosas tareas que normalmente se automatizarían o se llevarían a cabo desde una línea de comandos. Si no hay un cmdlet para una determinada tarea, puede usar Windows PowerShell para interactuar con el SDK.
Los comandos que proporciona el shell de comandos de Operations Manager se incluyen en un complemento, una DLL que se carga con Windows PowerShell y que contiene cmdlets para la administración de OpsMgr. El complemento también incluye el proveedor OperationsManagerMonitoring de Windows PowerShell. Esta herramienta, también denominada proveedor Monitoring, permite la navegación por conexiones, grupos y objetos de supervisión; esta navegación se asemeja bastante a la que se realiza por el sistema de archivos.
Puede obtener una lista de todos los cmdlets específicos de OpsMgr con el cmdlet Get-OperationsManagerCommand, tal como se muestra en la figura 2. En la primera versión era una función que no admitía la posibilidad de completar con el tabulador y en la versión con SP1 se convirtió en cmdlet. El lanzamiento original de Operations Manager incluía 74 cmdlets, mientras que OpsMgr SP1 tiene 87.
Figura 2 Obtención de una lista de cmdlets de OpsMgr (haga clic en la imagen para ampliarla)
El proveedor Monitoring de OpsMgr
Con el cmdlet Set-Location, o el alias cd, puede desplazarse por el diseño de grupos y equipos. El diseño base de la unidad Monitoring predeterminada es similar al siguiente:
Monitoring:\->RMS->Groups (as defined in OpsMgr)
->Computers(as defined in OpsMgr)
Desde aquí, puede llegar a objetos más específicos. Tenga en cuenta que en este caso estoy considerando únicamente un entorno simple en el que hay un solo servidor de administración. El primer servidor de administración instalado en un grupo de administración se denomina servidor de administración raíz (RMS).
Cuando se inicia el shell de comandos, éste crea una unidad denominada Monitoring, asigna la unidad a la raíz del proveedor OperationsManagerMonitoring y, finalmente, establece la ruta de acceso o la ubicación actual en la raíz de la unidad Monitoring. A continuación, el shell de comandos busca en el Registro el nombre del RMS predeterminado con el que se va a conectar. Si la conexión al RMS se realiza correctamente, la ubicación o la ruta de acceso actual se establece en el nombre de la conexión, o RMS, tal como se muestra en la figura 3.
Figura 3 La ubicación del shell de comandos se establece en el RMS (haga clic en la imagen para ampliarla)
Automatización de tareas comunes
Veamos cómo Windows PowerShell maneja algunas de las tareas administrativas más habituales.
Controlar el modo de mantenimiento No importa la tarea con la que esté lidiando, normalmente querrá especificar la fecha y hora en las que se va producir. Vamos a echar un vistazo rápido al cmdlet Get-Date para que vea lo fácil que puede ser. En la figura 4 se muestran algunos ejemplos.
Figura 4 Uso del cmdlet Get-Date (haga clic en la imagen para ampliarla)
Como puede ver, he creado una variable $date que contiene un objeto que representa la hora actual. A continuación, he usado algunos métodos documentados admitidos por el objeto para mostrar lo sencillo que resulta obtener la fecha y la hora cinco minutos más tarde y cinco horas después. Si deseara obtener valores del pasado, simplemente usaría (-5) en vez de (5).
Cuando necesite bloquear todas las alertas procedentes de un equipo, puede habilitar el modo de mantenimiento. OpsMgr 2007 permite establecer un servicio de Windows®, o incluso una determinada base de datos, en modo de mantenimiento en vez de un equipo o grupo entero. Hay tres cmdlets que tratan específicamente tareas de modo de mantenimiento: Get-MaintenanceWindow, New-MaintenanceWindow y Set-MaintenanceWindow.
Si desea poner un equipo en el modo de mantenimiento desde el shell de comandos, vaya al equipo u objeto de supervisión que desee usando el proveedor Monitoring e invoque el cmdlet New-MaintenanceWindow, tal como se muestra en la figura 5. Como puede ver, esta acción establece el equipo denominado Denver.contoso.com en modo de mantenimiento. Por otra parte, he definido la hora de inicio del período de mantenimiento para que surta efecto de forma inmediata y la hora de finalización para se produzca exactamente una hora después. Tenga en cuenta cuando se establece un equipo en modo de mantenimiento mediante este método no se detienen todas las alertas, ya que las instancias HealthService y HealthServiceWatcher del objeto siguen habilitadas.
Figura 5 Uso del cmdlet New-MaintenanceWindow (haga clic en la imagen para ampliarla)
Boris Yanushpolsky, administrador de programas del equipo de Microsoft OpsMgr, ha proporcionado código de Windows PowerShell muy útil que se puede usar para definir todos los objetos que hacen referencia a un equipo en modo de mantenimiento y ha explicado cómo usarlo una vez creado un script. Para obtener más información, consulte su blog en blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
A veces es necesario determinar si los objetos están en un modo de mantenimiento en el que no deberían estar. Recorrer todos los objetos para intentar averiguarlo puede convertirse en toda una odisea. Afortunadamente, Boris Yanushpolsky acude al rescate de nuevo con un script de Windows PowerShell que usa el SDK de OpsMgr. Puede copiar el código directamente desde su mensaje en el blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) y pegarlo en una ventana del shell de comandos para obtener una lista de todos los objetos que están en modo de mantenimiento.
Cuando un objeto está en modo de mantenimiento, es posible que desee finalizar el período de mantenimiento antes de la hora de finalización especificada inicialmente. Si está familiarizado con Windows PowerShell, aunque normalmente espere un cmdlet con un verbo stop o remove, en realidad debe usar Set-MaintenanceWindow, tal como se muestra en la figura 6.
Figura 6 Uso de Set-MaintenanceWindow para cambiar la hora de finalización (haga clic en la imagen para ampliarla)
Administrar agentes Los administradores trabajan a menudo con agentes y hay seis cmdlets y una función (en esta versión) que tratan distintas tareas relacionadas con agentes. El siguiente comando le permite obtener una lista de los mismos:
Get-Command *-agent*
En la versión SP1, Install-AgentByName se empaqueta como un cmdlet en lugar de una función. Se recomienda usar el cmdlet Install-AgentByName, ya que proporciona una mejor base para la asistencia y la coherencia.
La ayuda integrada que se incluye con el shell de comandos proporciona algunos ejemplos excelentes sobre el uso de los cmdlets Install-Agent y Uninstall-Agent. Roger Sprague, ingeniero sénior de diseño de software en el equipo de Microsoft OpsMgr, ha publicado un método alternativo en su blog, que se reproduce en la figura 7 (consulte el mensaje original en blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Este script funciona correctamente con OpsMgr RTM (debe ubicarse en la raíz del proveedor de supervisión, en este caso es monitoring:\oxford.contoso.com), pero no lo hace con OpsMgr SP1. Para que funcione con OpsMgr SP1, el primer comando de la figura 7 se debe cambiar por el siguiente:
$managementServer = Get-RootManagementServer
Figura 7 Instalación de un agente
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true
# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3
# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig
# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
En este punto, el agente se instala en el sistema remoto que se debe supervisar, pero todavía hay un último paso donde el servidor de administración debe aceptar realmente el nuevo agente antes de que se supervise por completo. Si no se realiza ninguna acción adicional, el servidor de supervisión aceptará automáticamente al nuevo agente para supervisión. También se puede efectuar un seguimiento rápido de este proceso de aceptación mediante el cmdlet Get-AgentPendingAction. Este cmdlet de una sola línea realizará un seguimiento rápido del proceso de aceptación del agente:
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Al canalizarlo a Reject-AgentPendingAction, en vez de a Approve-AgentPendingAction, se puede bloquear la aceptación de este agente por parte del servidor de OpsMgr, si la acción todavía está pendiente. Si no está pendiente, use el cmdlet Uninstall-Agent en su lugar.
Según he mencionado, también puede usar Install-AgentByName para especificar un equipo directamente en la línea de comandos donde se instalará el agente.
Trabajar con módulos de administración Hay cuatro cmdlets que le ayudarán a tratar las distintas tareas de los módulos de administración. Puede enumerarlos con:
Get-Command –noun ManagementPack
Este comando sencillo proporciona los módulos de administración instalados actualmente y sus números de versión:
Get-ManagementPack | Format-Table –autosize
A continuación voy a usar el shell de comandos para instalar dos módulos de administración habituales con estos instaladores:
- Internet Information Services System Center Operations Manager2007 Management Pack.msi
- Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Debido a que mi objetivo es mostrar cómo el shell de comandos puede facilitar tareas periódicas, voy a hacerlo usando el menor número posible de comandos (como se muestra en la figura 8). Podría haber cambiado este procedimiento de instalación para pasar el marcador silencioso al instalador (los archivos .msi), pero quería seleccionar la ubicación en la que se extraerán manualmente los archivos.
Figura 8 Instalación de módulos de administración (haga clic en la imagen para ampliarla)
A continuación, necesito instalar las bibliotecas comunes, lo que puedo hacer del siguiente modo:
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
{Install-ManagementPack –filePath $_.FullName}
El siguiente paso es instalar los otros módulos de administración necesarios:
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
{Install-ManagementPack –filePath $_.FullName}
Tal como se muestra en la figura 9, la ayuda integrada del shell de comandos ofrece un ejemplo excelente del uso del cmdlet Export-ManagementPack para exportar los módulos de administración sin sellar. Cambie la siguiente línea si desea exportar todos los módulos administración:
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}
$mps=Get-ManagementPack
Figura 9 Exportación de un módulo de administración (haga clic en la imagen para ampliarla)
Manipular las funciones de usuario El cmdlet Get-UserRole proporciona funcionalidad para administrar usuarios pero, curiosamente, no incluye un cmdlet Set complementario, y normalmente no se usa para realizar modificaciones o actualizaciones (según la documentación del SDK de Windows PowerShell). Como se puede ver en la figura 10, primero se obtiene una lista de las funciones actuales de usuario y, a continuación, se agrega un usuario al grupo Read-Only Operators (consulte la figura 11).
Figura 10 Presentación de las funciones de usuario (haga clic en la imagen para ampliarla)
Figura 11 Adición de un usuario (haga clic en la imagen para ampliarla)
Habilitar los servicios de recopilación de auditorías (ACS) ACS es una nueva característica opcional de Operations Manager 2007 que, en resumen, proporciona una forma centralizada de tratar la información de auditoría de seguridad. ACS no está habilitado de forma predeterminada y normalmente se configura más adelante en una fase posterior de una implementación de OpsMgr.
Cuando llega el momento de habilitar una gran cantidad de agentes para ACS, Windows PowerShell acude al rescate para ayudar a automatizar la configuración. Durante la versión beta de OpsMgr, Microsoft proporcionó un script para habilitar ACS en todos los agentes. Neale Browne, colaborador y blogger de SystemCenterForum.org, fue un paso más allá y agregó compatibilidad para parámetros adicionales.
El sitio de SystemCenterForum.org (un sitio de la comunidad que ofrece soluciones de Microsoft® System Center) ha publicado dos scripts distintos de Windows PowerShell para automatizar la configuración de ACS. Para configurar todos los agentes de un determinado grupo, use systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Para configurar todos los agentes supervisados, descargue systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Habilitar el agente de conexiones proxy El entorno de OpsMgr puede incluir dispositivos supervisados sin agente. Estos dispositivos se deben asignar a un servidor de administración o a un dispositivo administrado por agente que proporcionará la supervisión remota. Puede encontrar una descripción detallada sobre el uso de un script de Windows PowerShell para configurar una gran cantidad de agentes en systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Una versión actualizada del script está disponible en systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip.
Hay otras condiciones en las que determinados módulos de administración requieren que un agente se configure para actuar también como proxy. Consulte la documentación del módulo de administración para obtener más detalles.
El mundo real
A continuación se presentan algunos ejemplos reales para demostrar cómo Windows PowerShell puede ayudar en la automatización.
Resolver alertas ¿Alguna vez ha tenido que eliminar varias alertas de un determinado equipo? Tal vez se produjo un error en una aplicación o las alertas no se resolvieron activamente. El siguiente un comando de una sola línea resolverá todas las alertas que tengan un estado de resolución de cero:
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
El siguiente ejemplo realiza la misma tarea que el primero, pero se ejecutará más rápidamente en un entorno de mayor tamaño con más alertas pendientes:
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
Esta diferencia de rendimiento se debe a que, cuando se usa el parámetro de criterios, el valor pasado se proporciona directamente a la base de datos SQL Server® y sólo se devuelven los datos relevantes. De este modo se reducen los objetos que se deben pasar a la consola de Windows PowerShell.
Ahora dispone de una forma rápida de quitar todas las alertas pendientes de un equipo. En función de sus requisitos, puede establecer el comando para que se ejecute de forma automática.
Por último, este comando rápido le permite ver todas las alertas de un día específico:
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
Puede modificar fácilmente el valor de fecha y canalizar la salida al cmdlet Resolve-Alert.
Probar alertas Es posible que a veces desee supervisar determinados eventos en el Visor de eventos de Windows y probarlos. Estas dos líneas crearán una entrada rápida del registro de eventos:
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
"Test using PowerShell")
Sin embargo, se escribirá de forma predeterminada en el registro de eventos de Operations Manager, que probablemente no es el lugar donde se espera que se registre un determinado evento. Afortunadamente, Stefan Stranger, ingeniero de campo principal en Microsoft, ha escrito un script para crear eventos en el Visor de eventos de Windows y proporcionar más flexibilidad a la hora escribir en un determinado registro. Encontrará el script en go.microsoft.com/fwlink/?LinkId=120308. (Stefan ha empaquetado el script en un archivo .cab. Deberá descargar el archivo y, a continuación, hacer clic con el botón secundario en él para extraer el script.)
Lo único que se debe tener en cuenta con el script de Stefan es que el valor especificado para el origen del evento determina en qué registro se escribirá la entrada. Tal vez la forma más sencilla de asegurarse que una alerta se dirige al registro adecuado es abrir el Visor de eventos de Windows y buscar el origen de la entrada más reciente.
Establecer el propietario En ocasiones puede resultar útil establecer el propietario de una alerta automáticamente. A continuación se describe una forma sencilla de hacerlo desde el shell de comandos:
$alert = Get-Alert
-id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
La primera línea de este código obtiene el identificador de un determinado objeto de alerta y lo pasa a la variable $alert. En la segunda línea, dicha variable se usa para establecer el propietario y, por último, la actualización se aplica a la base de datos de OpsMgr. Si comprueba el propietario de la alerta con el siguiente comando, verá que ha cambiado:
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Para establecer el propietario de un conjunto de alertas completo, puede simplificar el código del siguiente modo:
Get-Alert | ForEach-Object {$_.Set_
Owner("Administrator");
$_.Update("Owner set")}
Restaurar el estado de supervisión Es muy probable que se encuentre con agentes que se encuentran en un estado "no supervisado". En este caso, es posible que necesite restaurar todos los agentes a un estado supervisado completo rápidamente y, a continuación, intentar determinar lo que ha sucedido. Al ejecutar el script de la figura 12 directamente desde el shell de comandos se debe restaurar la supervisión completa de los agentes afectados.
Figura 12 Restablecimiento del almacén del servicio de mantenimiento
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
Start-Task -Asynchronous
Pop-Location
}
Observe el código de la figura 12. Después de declarar una variable, obtengo una lista de todos los agentes de este RMS y filtro los que parecen tener problemas. A continuación, llamo una tarea asincrónicamente que restablece el almacén del servicio de mantenimiento en todos los agentes de la lista filtrada.
Asociar alertas a módulos de administración En la figura 13 se muestra cómo obtener una lista de todas las alertas nuevas, así como el módulo de administración al que está asociada cada una.
El código requirió algunos ajustes para garantizar que se podían resolver todos los nombres de módulo de administración. Los cmdlets usados variarán en función de si la alerta procede de una regla o de un monitor. (Tenga en cuenta que en la figura 13 necesité implementar una solución temporal para el cmdlet Get-Monitor. Desde OpsMgr SP1, el cmdlet admite un nuevo parámetro de identificador, lo que simplifica ligeramente el código.)
Figura 13 Búsqueda del módulo de administración
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
@{Label="MP"
Expression={If(!($_.IsMonitorAlert)){
ForEach-Object {
((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
}
Else{
ForEach-Object {
$id=$_.ProblemId
((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
}
}
}
Informes sencillos Al actualizar el entorno, puede resultar útil auditar las versiones de todos los agentes instalados. Sólo se necesita un script sencillo para imprimir un informe estupendo:
Get-Agent| `
Format-Table DisplayName,@{ `
Label="Version"
Expression={ `
switch ($_.Version){
"6.0.5000.0" {"RTM"}
"6.0.6246.0" {"SP1 (RC)"}
"6.0.6278.0" {"SP1 (RTM)"}
}
}
}
En la figura 14 se muestra el resultado del script. Este script es una versión ampliada de los ejemplos proporcionados en systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Figura 14 Resultado que muestra las versiones de algunos agentes (haga clic en la imagen para ampliarla)
Programar una tarea Es posible que desee ejecutar un script de Windows PowerShell de forma periódica. Supongamos que usa un equipo cliente para conectarse y administrar el servidor OpsMgr y tiene las herramientas de administración de OpsMgr instaladas localmente. Consideremos, por ejemplo, que desea ejecutar el informe de versiones de agente diariamente y guardar el resultado en un archivo que se denomine con la fecha actual. Puede usar el programador de tareas de Windows integrado para ejecutar el script desde el equipo local.
Para ello, sólo tiene que configurar una tarea nueva con el programa establecido como powershell.exe (normalmente se encuentra en C:\Windows\System32\WindowsPowerShell\v1.0). Una vez creada la tarea, edítela y establezca el comando para que se ejecute de forma parecida a:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
–Command "& {& 'c:\agent_report2.ps1'}"
Resulta que al final tuve que realizar unos cuantos cambios en mi código de Windows PowerShell original, tal como se puede ver en la figura 15. Tuve que agregar el complemento PowerShell de OpsMgr, crear la unidad Monitoring asociada al proveedor OperationsManagerMonitoring y crear una conexión al RMS. También cargué el script de Windows PowerShell personalizado para OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) para cargar las funciones específicas de OpsMgr.
Figura 15 Programación del script de versiones de agente
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com
Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1
$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"
Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
Label="Version"
Expression={ `
switch ($_.Version){
"6.0.5000.0" {"RTM"}
"6.0.6246.0" {"SP1 (RC)"}
"6.0.6278.0" {"SP1 (RTM)"}
}
}
} | Out-File $file
Pero eso no es todo. Tal vez haya observado que cada vez que se ejecuta la tarea, aparece una ventana de consola negra en la pantalla si algún usuario ha iniciado sesión en el sistema donde se está ejecutando el script. Encontrará un pequeño truco que se ocupa de este tema, proporcionado por Don Jones y Jeffery Hicks de Sapien, en blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Fundamentalmente necesita incluir el script en VBScript. Para ello, se usa código como el de la figura 16 en lugar de llamar el comando siguiente desde la tarea programada:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
–Command "& {& 'c:\agent_report2.ps1'}"
Figura 16 Ocultación de las pantallas emergentes
Dim objShell
Set objShell=CreateObject("WScript.Shell")
'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"
strCMD="powershell -nologo -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)
'Uncomment next line for debugging
'WScript.Echo strCMD
'use 0 to hide window
objShell.Run strCMD,0
La tarea usará en este caso el programa wscript.exe y la llamada sería similar a la siguiente:
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
Por último, se pueden crear informes automatizados y el proceso se oculta a los usuarios que han iniciado sesión.
Conclusión
En este artículo se ha realizado un breve recorrido de las nuevas características de automatización disponibles con OpsMgr 2007 y supone tan solo una mínima parte de cómo se puede usar Windows PowerShell para la administración de OpsMgr.
Me gustaría dar las gracias a todas las personas mencionadas en el artículo, así como a Pete Zerger, MVP de MOM y fundador de SystemCenterForum.org, por su valiosa ayuda.
Marco Shaw es analista de sistemas de TI para una compañía de telecomunicaciones de Canadá. Ha trabajado en el sector de TI durante más de 10 años y recientemente ha recibido un galardón de MVP de Windows PowerShell. Marco también es director adjunto de comunidad del nuevo sitio web de la comunidad de PowerShell en powershellcommunity.org. Tiene su propio blog en marcoshaw.blogspot.com.
© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.