System Center

O Windows PowerShell no System Center Operations Manager

Marco Shaw

 

Visão geral:

• O shell de comando do OpsMgr
• O provedor de monitoramento do OpsMgr
• Automação de tarefas administrativas comuns
• Alguns exemplos reais de uso do Windows PowerShell

Sumário

O shell de comando do Operations Manager
O provedor de monitoramento do OpsMgr
Automação de tarefas comuns
Exemplos reais
Conclusão

O OpsMgr (System Center Operations Manager 2007) permitiu aos administradores o acesso ao Windows PowerShell, uma nova e poderosa linguagem de scripts para a automação de tarefas. Desde seu lançamento, em novembro de 2006, já foi baixado mais de dois milhões de vezes.

Neste artigo, abordarei o Windows PowerShell® e como ele se aplica ao Operations Manager. Tratarei de algumas tarefas comuns que o Windows PowerShell pode ajudá-lo a realizar de forma muito mais simples e automatizada, e também indicarei alguns sites que fornecem scripts e explicações úteis. Reuni publicações em blogs e idéias de muitos especialistas que utilizam atualmente o Windows PowerShell.

Embora a Microsoft já tenha começado a lançar as versões CTP (Community Technology Preview) do Windows PowerShell 2.0, essas versões ainda não estão prontas para a produção, não foram testadas com o OpsMgr e não devem ser instaladas em um sistema de produção.

O shell de comando do Operations Manager

No OpsMgr, o Windows PowerShell é acessado por meio do shell de comando, que é semelhante ao ambiente padrão do Windows PowerShell, exceto pelo fato de carregar um arquivo de console e um script que inicializa o ambiente com os cmdlets, as funções e uma conexão padrão do OpsMgr.

Você pode iniciar o shell de comando a partir de um ícone no menu Iniciar do OpsMgr ou clicando com o botão direito do mouse em um nome de computador no console da interface do usuário do OpsMgr (veja a Figura 1). Isso o colocará diretamente no caminho da unidade Monitoring do OpsMgr (que abordarei em breve).

Figura 1. Abrindo o shell de comando a partir da interface do usuário do OpsMgr (clique na imagem para ampliá-la)

O Windows PowerShell faz interface com o OpsMgr via SDK do OpsMgr. Felizmente para os administradores, já foram fornecidos cmdlets para muitas das tarefas que eles geralmente gostariam de automatizar ou concluir usando uma linha de comando. Se não houver um cmdlet para uma tarefa específica, é possível usar o Windows PowerShell para interagir com o SDK.

Os comandos fornecidos pelo shell de comando do Operations Manager estão contidos em um snap-in — uma DLL carregada pelo Windows PowerShell que contém cmdlets para a administração do OpsMgr. O snap-in inclui também o provedor OperationsManagerMonitoring do Windows PowerShell. Essa ferramenta, também conhecida como provedor de monitoramento, permite a navegação em conexões, grupos e objetos de monitoramento, de forma muito semelhante à navegação no sistema de arquivos.

É possível obter uma lista de todos os cmdlets específicos do OpsMgr usando o cmdlet Get-OperationsManagerCommand, conforme mostrado na Figura 2 (na primeira versão, essa era uma função que não oferecia suporte à conclusão de tabulação; tornou-se um cmdlet no SP1). A versão original do Operations Manager incluía 74 cmdlets; já o OpsMgr SP1 tem 87.

Figura 2. Obtendo uma lista de cmdlets do OpsMgr (clique na imagem para ampliá-la)

O provedor de monitoramento do OpsMgr

Utilizando o cmdlet Set-Location ou o alias cd, você pode navegar pelo layout de grupos e computadores. O layout de base da unidade Monitoring padrão tem esta aparência:

Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)

Partindo daqui, você pode obter objetos mais específicos. Observe que estou lidando apenas com um ambiente simples neste caso, onde há um único servidor de gerenciamento. O primeiro servidor de gerenciamento instalado em um grupo de gerenciamento é conhecido como RMS (Servidor de Gerenciamento Raiz).

Quando o shell de comando é iniciado, ele cria uma unidade chamada Monitoring, mapeia essa unidade para a raiz do provedor OperationsManagerMonitoring e, por fim, define o local ou o caminho atual na raiz da unidade Monitoring. Então, o shell de comando procura, no Registro, o nome do RMS padrão ao qual deverá conectar-se. Se a conexão com o RMS for bem-sucedida, o local ou o caminho atual será definido com o nome da conexão, ou do RMS, conforme mostrado na Figura 3.

Figura 3. A localização do shell de comando é definida como o RMS (clique na imagem para ampliá-la)

Automação de tarefas comuns

Vejamos como o Windows PowerShell é capaz de lidar com algumas das tarefas administrativas mais comuns.

Controlar o modo de manutenção Seja qual for a tarefa que esteja gerenciando, geralmente você desejará especificar a data e a hora em que ela deverá ocorrer. Farei uma descrição resumida do cmdlet Get-Date para mostrar como isso é fácil. A Figura 4 mostra alguns exemplos.

Figura 4. Usando o cmdlet Get-Date (clique na imagem para ampliá-la)

Como você pode ver, criei uma variável $date que contém um objeto representando a hora atual. Então, usei alguns métodos documentados com suporte do objeto para mostrar como se pode obter facilmente a data e a hora cinco minutos depois, e também cinco horas depois. Se eu quisesse obter valores do passado, simplesmente usaria (-5) em vez de (5).

Quando precisa bloquear todos os alertas de um computador, você pode habilitar o modo de manutenção. O OpsMgr 2007 permite colocar um serviço do Windows®, ou mesmo um banco de dados específico, no modo de manutenção, em vez de colocar um computador ou um grupo inteiro. Há três cmdlets que lidam especificamente com as tarefas do modo de manutenção: Get-MaintenanceWindow, New-MaintenanceWindow e Set-MaintenanceWindow.

Para colocar um computador no modo de manutenção a partir do shell de comando, navegue até o computador ou o objeto de monitoramento desejado usando o provedor de monitoramento e invoque o cmdlet New-MaintenanceWindow, conforme mostrado na Figura 5. Como você pode ver, essa ação coloca o computador chamado Denver.contoso.com em modo de manutenção. Também defini a hora de início da janela de manutenção para entrar em vigor imediatamente, e a hora de término para entrar em vigor exatamente uma hora depois. Observe que colocar um computador em modo de manutenção usando esse método não interrompe todos os alertas, pois as instâncias HealthService e HealthServiceWatcher do objeto ainda estão habilitadas.

Figura 5. Usando o cmdlet New-MaintenanceWindow (clique na imagem para ampliá-la)

Boris Yanushpolsky, gerente de programa da equipe do Microsoft OpsMgr, forneceu um código muito útil do Windows PowerShell, que pode ser usado para colocar todos os objetos relacionados a um computador em modo de manutenção, e explicou como usá-lo depois que você criar um script. Para ler mais sobre o assunto, visite seu blog em blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.

Algumas vezes, é preciso determinar se há objetos no modo de manutenção que não deveriam estar. No entanto, percorrer todos os objetos na tentativa de descobrir isso pode ser uma empreitada muito trabalhosa. Felizmente, Boris Yanushpolsky mais uma vez traz a solução, com um script do Windows PowerShell que usa o SDK do OpsMgr. Você pode obter o código diretamente na postagem do seu blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) e colá-lo em uma janela do shell de comando para obter uma listagem de todos os objetos em modo de manutenção.

Quando um objeto estiver em modo de manutenção, talvez você queira encerrar o período de manutenção antes da hora de término originalmente especificada. Se você está familiarizado com o Windows PowerShell, talvez espere um cmdlet com um verbo de interrupção ou remoção, mas na verdade deve usar Set-MaintenanceWindow, como na Figura 6.

Figura 6. Usando Set-MaintenanceWindow para alterar a hora de término (clique na imagem para ampliá-la)

Gerenciar agentes Os administradores normalmente trabalham com agentes, e há seis cmdlets e uma função (no momento do lançamento) para lidar com diversas tarefas relacionadas a agentes. Você pode obter uma lista deles com este comando:

Get-Command *-agent*

No momento do lançamento do SP1, Install-AgentByName é fornecido como um cmdlet, e não como uma função. É recomendável que você use o cmdlet Install-AgentByName, pois ele proporciona uma base melhor em termos de suporte e consistência.

A ajuda interna incluída no shell de comando traz alguns bons exemplos de uso dos cmdlets Install-Agent e Uninstall-Agent. Roger Sprague, engenheiro sênior de design de software da equipe do Microsoft OpsMgr, postou em seu blog um método alternativo, reproduzido na Figura 7 (veja a postagem original em blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).

Esse script funciona bem com o OpsMgr RTM (você precisa estar localizado na raiz do provedor de monitoramento — neste artigo, é monitoring:\oxford.contoso.com), mas falha com o OpsMgr SP1. Para fazê-lo funcionar com o OpsMgr SP1, é preciso trocar o primeiro comando da Figura 7 pelo seguinte:

 $managementServer = Get-RootManagementServer

Figura 7. Instalando um 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

Neste ponto, o agente é instalado no sistema remoto que deve ser monitorado, mas ainda há uma última etapa, na qual o servidor de gerenciamento deve realmente aceitar o novo agente, antes que ele seja completamente monitorado. Se nenhuma ação adicional for realizada, o servidor de monitoramento aceitará automaticamente o novo agente para monitoramento. Mas esse processo de aceitação também pode ser acelerado com o uso do cmdlet Get-AgentPendingAction. Esta única linha de código irá acelerar o processo de aceitação do agente:

Get-AgentPendingAction | Where Object {$_.AgentName –like 
'computer*'} | Approve-AgentPendingAction

Canalizando isso para Reject-AgentPendingAction, em vez de Approve-AgentPendingAction, você pode bloquear a aceitação do agente pelo servidor do OpsMgr, se a ação ainda estiver pendente. Se não estiver pendente, use o cmdlet Uninstall-Agent.

Como já mencionei, também é possível usar Install-AgentByName para especificar um computador diretamente na linha de comando onde o agente deve ser instalado.

Trabalhar com pacotes de gerenciamento Há quatro cmdlets para ajudá-lo a lidar com várias tarefas relacionadas a pacotes de gerenciamento. Você pode listá-los usando:

Get-Command –noun ManagementPack

Este comando simples apresenta os pacotes de gerenciamento atualmente instalados e seus números de versão:

Get-ManagementPack | Format-Table –autosize

Agora, utilizarei o shell de comando para instalar dois pacotes de gerenciamento comuns com estes instaladores:

• Internet Information Services System Center Operations Manager2007 Management Pack.msi
• Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.

Uma vez que meu objetivo é mostrar a forma como o shell de comando pode tornar mais simples as tarefas cotidianas, farei isso usando a menor quantidade possível de comandos (conforme mostrado na Figura 8). Eu poderia ter alterado o procedimento de instalação para passar o sinalizador silencioso para o instalador (os arquivos .msi), mas preferi selecionar manualmente o local onde os arquivos seriam extraídos.

Figura 8. Instalando pacotes de gerenciamento (clique na imagem para ampliá-la)

Em seguida, preciso instalar as bibliotecas comuns, o que pode ser feito com o seguinte:

Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Depois, instalo os outros pacotes de gerenciamento necessários:

Get-ChildItem –Path C:\MPs –filter *200?.mp | 
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Conforme mostrado na Figura 9, a ajuda interna do shell de comando traz um ótimo exemplo de uso do cmdlet Export-ManagementPack para exportar pacotes de gerenciamento sem lacre. Se você quiser exportar todos os pacotes de gerenciamento, altere esta linha:

 $mps=Get-ManagementPack | 
Where-Object {$_.Sealed –eq $false} 

 $mps=Get-ManagementPack

Figura 9. Exportando um pacote de gerenciamento (clique na imagem para ampliá-la)

Manipular funções de usuários O cmdlet Get-UserRole oferece alguns recursos para a administração de usuários. No entanto, por estranho que pareça, não vem com um cmdlet Set complementar e, em geral, você não vai utilizá-lo para fazer edições ou atualizações (de acordo com a documentação do SDK do Windows PowerShell). Como você pode ver na Figura 10, eu primeiro obtenho uma listagem das atuais funções de usuários, para depois adicionar um usuário ao grupo de operadores somente leitura (veja a Figura 11).

Figura 10. Exibindo funções de usuários (clique na imagem para ampliá-la)

Figura 11. Adicionando um usuário (clique na imagem para ampliá-la)

Habilitar o ACS (Audit Collection Services) O ACS é um novo recurso opcional do Operations Manager 2007 que, em suma, proporciona uma forma centralizada para lidar com informações de auditoria de segurança. O ACS não é habilitado por padrão e, em geral, pode ser configurado mais tarde, em uma fase futura da implementação do OpsMgr.

Quando chega a hora de habilitar uma grande quantidade de agentes para o ACS, o Windows PowerShell ajuda a automatizar a configuração. Na versão beta do OpsMgr, a Microsoft forneceu um script para habilitar o ACS em todos os agentes. Neale Browne, contribuidora e blogger do SystemCenterForum.org, levou essa questão um passo adiante e acrescentou suporte para parâmetros adicionais.

O site SystemCenterForum.org (um site da comunidade que fornece soluções para o Microsoft® System Center) criou dois scripts diferentes para o Windows PowerShell, que estão disponíveis para automatizar a configuração do ACS. Para configurar todos os agentes de um grupo específico, use systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Para configurar todos os agentes monitorados, baixe systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.

Habilitar a atuação de agentes como proxy Seu ambiente OpsMgr pode incluir dispositivos monitorados sem agentes. Esses dispositivos precisam ser atribuídos a um servidor de gerenciamento ou a um dispositivo gerenciado por agente, que realizará o monitoramento remoto. Você encontra uma descrição detalhada do uso de um script do Windows PowerShell para configurar uma grande quantidade de agentes em systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Há uma versão atualizada do script disponível em systemcenterforum.org/wp-content/uploads/Set-AgentProxyBulk_FQDN.zip.

Existem também outras condições nas quais pacotes de gerenciamento específicos requerem que um agente seja configurado para atuar como um proxy. Consulte a documentação do pacote de gerenciamento para obter mais detalhes.

Exemplos reais

Eis aqui alguns exemplos reais para demonstrar em mais detalhes a forma como o Windows PowerShell pode auxiliar na automação.

Solucionar alertas Você já precisou excluir vários alertas de um computador específico? Talvez tenha ocorrido algo de errado em um aplicativo, ou então os alertas não estavam sendo solucionados ativamente. Este comando de uma só linha solucionará todos os alertas com estado de resolução zero:

Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null

O próximo exemplo cumpre a mesma função do anterior, mas será executado com muito mais rapidez em um ambiente maior, com mais alertas pendentes:

Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null

O motivo da diferença de desempenho é que, quando o parâmetro de critérios é usado, o valor transmitido é fornecido diretamente ao banco de dados do SQL Server®, e somente os dados relevantes são retornados. Isso reduz a quantidade de objetos a serem transmitidos de volta ao console do Windows PowerShell.

Agora, você conta com uma forma rápida de remover todos os alertas pendentes de um computador. Dependendo das suas necessidades, você poderá configurar essa função para ser executada automaticamente.

Por fim, eis um comando rápido que permite exibir todos os alertas de um dia específico:

Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''

Você pode alterar facilmente o valor da data e canalizar a saída para o cmdlet Resolve-Alert.

Testar alertas Algumas vezes, você quer monitorar determinados eventos no Visualizador de Eventos do Windows e realizar testes a partir deles. Estas duas linhas criarão uma entrada rápida no log de eventos:

 $api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")

No entanto, por padrão, a gravação será feita no log de eventos do Operations Manager, que provavelmente não é o local onde você esperaria que um evento específico fosse registrado. Felizmente, Stefan Stranger, engenheiro-chefe de campo da Microsoft, escreveu um script para criar eventos no Visualizador de Eventos do Windows que oferece mais flexibilidade, por ser capaz de gravar em um log específico. Você encontra o script em go.microsoft.com/fwlink/?LinkId=120308. (Stefan empacotou o script em um arquivo .cab; você precisará baixar o arquivo e depois clicar nele com o botão direito do mouse para extrair o script).

A única observação importante a respeito do script de Stefan é que o valor inserido para a origem do evento determina em que log a entrada será gravada. Talvez a forma mais simples de garantir que um alerta seja direcionado para o log adequado seja abrindo o Visualizador de Eventos do Windows e localizando a origem da última entrada.

Definir o proprietário Algumas vezes, pode ser útil definir automaticamente o proprietário de um alerta. Eis uma forma simples de fazer isso a partir do shell de comando:

 $alert = Get-Alert 
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")

A primeira linha desse código obtém o ID de um objeto de alerta específico e o transmite para a variável $alert. Na segunda linha, essa variável é usada para definir o proprietário, e finalmente a atualização é aplicada ao banco de dados do OpsMgr. Se você verificar o proprietário do alerta com o comando a seguir, verá a alteração:

Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner

Para definir o proprietário de todo um conjunto de alertas, você pode simplificar o código assim:

Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}

Restaurar o estado de monitoramento Provavelmente você já se deparou com agentes em um estado "não monitorado". Quando isso ocorre, pode ser preciso restaurar com rapidez todos os agentes a um estado totalmente monitorado, para depois tentar determinar o que ocorreu. A execução do script na Figura 12 diretamente no shell de comando deve restaurar o monitoramento total dos agentes afetados.

Figura 12. Redefinindo o armazenamento do serviço de integridade

 $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 o código na Figura 12. Depois de declarar uma variável, eu obtenho uma lista de todos os agentes neste RMS e filtro os que parecem apresentar problemas. Então, chamo uma tarefa de forma assíncrona para redefinir o armazenamento do serviço de integridade de todos os agentes na lista filtrada.

Associar alertas a pacotes de gerenciamento A Figura 13mostra como obter uma lista de todos os novos alertas, além do pacote de gerenciamento ao qual cada um deles está associado.

O código exigiu o uso de alguns truques para garantir que todos os nomes de pacotes de gerenciamento pudessem ser solucionados. Os cmdlets usados variam, dependendo se o alerta vem de uma regra ou de um monitor. Observe que, na Figura 13, precisei implementar uma solução alternativa para o cmdlet Get-Monitor. No OpsMgr SP1, o cmdlet oferece suporte a um novo parâmetro de ID, que deve simplificar um pouco o código.

Figura 13. Localizando o pacote de gerenciamento

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}
         }
   }
}

Gerar relatórios com facilidade Quando você atualizar seu ambiente, talvez seja útil fazer a auditoria das versões de todos os agentes instalados. Basta um script simples para imprimir um ótimo relatório:

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)"}
    }
  }
}

A Figura 14 mostra a saída do script. Esse script é uma versão expandida dos exemplos fornecidos em systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.

Figura 14. Saída mostrando as versões de alguns agentes (clique na imagem para ampliá-la)

Programar uma tarefa Talvez você queira executar regularmente um script do Windows PowerShell. Digamos que você use um computador cliente para conectar-se e gerenciar seu servidor do OpsMgr, e que você tenha as ferramentas de administração do OpsMgr instaladas localmente. E suponha, por exemplo, que você queira executar o relatório de versão dos agentes diariamente e salvar a saída em um arquivo tendo a data atual como nome. Você pode usar o agendador de tarefas interno do Windows para executar o script a partir do seu computador local.

Para fazer isso, basta configurar uma nova tarefa com o programa definido como powershell.exe (geralmente localizado em C:\Windows\System32\WindowsPowerShell\v1.0). Depois de criar a tarefa, edite-a e configure o comando para ser executado da seguinte forma:

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe 
  –Command "& {& 'c:\agent_report2.ps1'}"

No fim das contas, precisei fazer algumas alterações no código original do Windows PowerShell, como você pode ver na Figura 15. Precisei adicionar o snap-in OpsMgr PowerShell, criar a unidade Monitoring mapeada para o provedor OperationsManagerMonitoring e criar uma conexão com o RMS. Também carrego o script do Windows PowerShell personalizado para o OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) para carregar funções específicas do OpsMgr.

Figura 15. Agendando o script de versões de agentes

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

Mas isso não é tudo. Talvez você perceba que, sempre que a tarefa é executada, uma janela de console preta aparece na tela se alguém estiver conectado ao sistema onde o script está sendo executado. Você encontra um truque simples para solucionar isso, oferecido por Don Jones e Jeffery Hicks, da Sapien, em blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.

Basicamente, você precisa encapsular o script em um VBScript. Para fazer isso, é preciso usar código como o exposto na Figura 16, em vez de chamar o seguinte na sua tarefa agendada:

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"

Figura 16. Ocultando pop-ups

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

Agora, a tarefa utilizará o programa wscript.exe, e a chamada terá uma aparência semelhante a isto:

C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs 

Finalmente, posso criar relatórios automatizados, e o processo é ocultado dos usuários conectados.

Conclusão

Esta apresentação rápida dos novos recursos de automação disponíveis no OpsMgr 2007 proporciona apenas uma noção superficial de como você pode usar o Windows PowerShell para realizar a administração do OpsMgr.

Eu gostaria de agradecer a todas as pessoas mencionadas no artigo, e também a Pete Zerger, MVP do MOM e fundador do SystemCenterForum.org, por seu valioso auxílio.

Marco Shaw é analista de sistemas de TI de uma empresa canadense de telecomunicações. Ele trabalha no setor de TI há mais de dez anos e recebeu recentemente um prêmio para MVPs do Windows PowerShell. Marco é também o diretor comunitário assistente do novo site da comunidade do PowerShell em powershellcommunity.org. Ele mantém um blog em marcoshaw.blogspot.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida.