System Center

Windows PowerShell in System Center Operations Manager

Marco Shaw

 

Panoramica:

• La shell dei comandi di OpsMgr
• Il provider di monitoraggio di OpsMgr
• Automazione di comuni operazioni di gestione
• Alcuni esempi reali di Windows PowerShell

Indice

La shell dei comandi di OpsMgr
Il provider di monitoraggio di OpsMgr
Automazione delle operazioni comuni
Il mondo reale
Conclusioni

System Center Operations Manager 2007 (OpsMgr) consente agli amministratori di accedere a Windows PowerShell, un nuovo e potente linguaggio di script utile per l'automazione delle operazioni. Dalla data di rilascio al pubblico, nel novembre 2006, questo software è stato scaricato più di due milioni di volte.

In quest'articolo parlerò di Windows PowerShell® e della sua applicazione a Operations Manager. Tratterò alcune delle attività comuni che Windows PowerShell può aiutare a realizzare in tutta semplicità e in modo automatico. Inoltre, proporrò alcuni siti Web che forniscono script utili e spiegazioni. Ho raccolto pareri e post da svariati blog di esperti di Windows PowerShell.

Sebbene Microsoft abbia iniziato a rilasciare versioni CTP (Community Technology Preview) di Windows PowerShell 2.0, queste non sono ancora da considerare adatte a un ambiente di produzione e non sono state testate con OpsMgr.

La shell dei comandi di OpsMgr

In OpsMgr, si può accedere a Windows PowerShell attraverso la shell dei comandi. Questa è simile all'ambiente di Windows PowerShell predefinito, ma in più carica un file di console e uno script che inizializza l'ambiente con cmdlet e funzioni di OpsMgr e una connessione predefinita.

È possibile avviare la shell dei comandi dall'icona nel menu Start di OpsMgr o facendo clic col pulsante destro del mouse sul nome di un computer nella console dell'interfaccia utente di OpsMgr (vedere Figura 1). In questo modo ci si troverà direttamente nel percorso dell'unità di monitoraggio di OpsMgr (che discuterò a breve).

Figura 1 Apertura della shell dei comandi dall'interfaccia utente di OpsMgr (fare clic sull'immagine per ingrandirla)

Windows PowerShell si interfaccia con OpsMgr attraverso un SDK. Per la felicità degli amministratori, sono già disponibili molti cmdlet per le attività più comuni da automatizzare o da eseguire dalla riga di comando. Se non esiste un cmdlet per una particolare attività, è possibile utilizzare Windows PowerShell per interagire con l'SDK.

I comandi messi a disposizione dalla shell dei comandi di Operations Manager sono contenuti in uno snap-in, una DLL che viene caricata da Windows PowerShell e che contiene dei cmdlet per l'amministrazione di OpsMgr. Lo snap-in contiene inoltre il provider di monitoraggio di Windows PowerShell per Operations Manager. Noto anche come provider di monitoraggio, questo strumento consente l'esplorazione di connessioni, gruppi e oggetti, quasi come si naviga in un file system.

Come illustrato in Figura 2, è possibile ottenere un elenco di tutti i cmdlet propri di OpsMgr utilizzando il cmdlet Get-OperationsManager­Command. (Nella prima versione questa era una funzione che non supportava il completamento tramite tab; dopo l'introduzione del SP1 è diventato un cmdlet.) La versione originale di Operations Manager conteneva 74 cmdlet, mentre con OpsMgr SP1 il numero è arrivato a 87.

Figura 2 Ottenere l'elenco dei cmdlet di OpsMgr (fare clic sull'immagine per ingrandirla)

Il provider di monitoraggio di OpsMgr

Utilizzando il cmdlet Set-Location o l'alias cd, è possibile navigare attraverso lo schema dei gruppi e dei computer. Lo schema di base dell'unità di controllo è simile a questo:

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

Da qui è possibile raggiungere oggetti più specifici. Notare che in questo esempio sto trattando un ambiente di base con soltanto un server di gestione singolo. Il primo server di gestione installato in un gruppo di gestione è chiamato server di gestione radice (RMS).

Dopo essere stata avviata, la shell dei comandi crea un'unità chiamata Monitoring e mappa l'unità alla directory principale del provider di monitoraggio di OperationsManager. Per concludere, imposta la posizione o il percorso attuale alla directory principale dell'unità di monitoraggio. A questo punto la shell dei comandi ricerca nel registro di sistema il nome dell'RMS predefinito al quale connettersi. Se la connessione all'RMS viene stabilita, la posizione o il percorso attuale vengono impostati alla connessione o all'RMS, come illustrato in Figura 3.

Figura 3 La posizione della shell dei comandi viene impostata all'RMS (fare clic sull'immagine per ingrandirla)

Automazione delle operazioni comuni

Vediamo adesso come Windows PowerShell può controllare alcune delle attività di gestione più comuni.

Controllare la modalità di manutenzione Qualunque sia l'operazione che si vuole eseguire, generalmente si vogliono specificare la data e l'ora di esecuzione. Darò adesso un breve sguardo al cmdlet Get-Date per illustrare la semplicità di questa operazione. Nella Figura 4 vengono mostrati alcuni esempi.

Figura 4 Utilizzo del cmdlet Get-Date (fare clic sull'immagine per ingrandirla)

Come si può vedere ho creato una variabile $date che contiene un oggetto con l'ora corrente. Successivamente, ho utilizzato alcuni dei metodi documentati e supportati dall'oggetto per mostrare come è possibile ottenere facilmente la data e l'ora, cinque minuti o cinque ore più avanti. Se avessi voluto ottenere un'ora precedente, avrei digitato semplicemente (-5) invece di (5).

Se si vogliono bloccare tutti gli avvisi provenienti da un computer, è possibile attivare la modalità di manutenzione. Se non si vuole agire su un computer o su un gruppo, OpsMgr 2007 consente di porre solamente un servizio di Windows® o anche un particolare database in modalità di manutenzione. Esistono tre cmdlet che si occupano in particolare delle operazioni con la modalità di manutenzione: Get-MaintenanceWindow, New-MaintenanceWindow e Set-MaintenanceWindow.

Per porre un computer in modalità di manutenzione dalla shell dei comandi, selezionare il computer o il controllo desiderato utilizzando il provider di monitoraggio e richiamare il cmdlet New-MaintenanceWindow, come illustrato in Figura 5. Come si vede, quest'azione pone il computer denominato Denver.contoso.com in modalità di manutenzione. Ho inoltre impostato l'ora di avvio della finestra di manutenzione sull'ora corrente e l'ora di interruzione esattamente a un'ora dopo. Notare che ponendo un computer in modalità di manutenzione utilizzando questo metodo non verranno interrotti tutti gli avvisi, poiché tutte le istanze di HealthService e HealthService­Watcher per quest'oggetto sono ancora attivate.

Figura 5 Utilizzo del cmdlet New-MaintenanceWindow (fare clic sull'immagine per ingrandirla)

Boris Yanushpolsky, Program Manager nel team di Microsoft Ops­Mgr, ha fornito dell'utilissimo codice di Windows PowerShell che può essere utilizzato per porre tutti gli oggetti che fanno riferimento a un computer in modalità di manutenzione. Egli ha anche spiegato come utilizzare questo codice dopo avere creato uno script. Per avere più informazioni su questo argomento, visitare il suo blog a blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.

A volte è necessario determinare se degli oggetti si trovano erroneamente in modalità di manutenzione. Tuttavia in casi come questo, scorrere tutti gli oggetti potrebbe essere un'operazione eccessivamente pesante da eseguire. Boris Yanushpolsky ci viene fortunatamente in soccorso ancora una volta con uno script di Windows PowerShell che utilizza l'SDK di OpsMgr. È possibile copiare il codice direttamente da un post del suo blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) e incollarlo in una finestra della shell dei comandi. In questo modo si otterrà un elenco di tutti gli oggetti che si trovano in modalità di manutenzione.

Quando un oggetto è in modalità di manutenzione, si potrebbe volere terminare il periodo di manutenzione prima dell'ora precedentemente specificata. Conoscendo bene Windows PowerShell, si potrebbe essere tentati di cercare un cmdlet che contenga le parole "remove" o "stop". In realtà, il cmdlet da utilizzare in questo caso è Set-MaintenanceWindow, come mostrato in Figura 6.

Figura 6 Utilizzo di Set-MaintenanceWindow per modificare l'ora di interruzione (fare clic sull'immagine per ingrandirla)

Gestione degli agenti Molto spesso gli amministratori lavorano con gli agenti. Esistono sei cmdlet e una funzione (in questa versione) che operano con gli agenti. È possibile ottenere un elenco degli agenti con questo comando:

Get-Command *-agent*

Dopo il rilascio della versione SP1, Install-AgentBy­Name viene fornito come cmdlet, piuttosto che come funzione. Si consiglia di utilizzare il cmdlet Install-AgentByName, poiché esso fornisce un livello maggiore di supporto e coerenza.

La guida fornita con la shell dei comandi contiene alcuni buoni esempi dell'utilizzo dei cmdlet Install-Agent e Uninstall-Agent. Roger Sprague, Senior Software Design Engineer nel team di Microsoft Ops­Mgr, ha pubblicato un metodo alternativo sul suo blog che ripropongo in Figura 7 (trovate il post originale su blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).

Questo script funziona in maniera ottimale con la versione RTM di OpsMgr (è necessario trovarsi nella directory principale del provider di monitoraggio, che in quest'articolo è monitoring:\oxford.contoso.com). Lo script non funziona invece con la versione SP1 di OpsMgr SP1. Per farlo funzionare con questa versione di OpsMgr, il primo comando in Figura 7 dovrebbe essere modificato come segue:

 $managementServer = Get-RootManagementServer

Figura 7 Installazione di 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

A questo punto l'agente è installato sul sistema remoto da monitorare. Prima dell'avvio del monitoraggio, il server apposito deve accettare il nuovo agente. Se non si esegue nessun'altra operazione, il server di monitoraggio accetterà automaticamente il nuovo agente da monitorare. Questo processo di accettazione può anche essere velocemente individuato utilizzando il cmdlet Get-AgentPendingAction. Questa semplice riga di codice individua velocemente il processo di accettazione dell'agente:

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

Inviando questo al Reject-AgentPending­Action, piuttosto che all'Approve-AgentPending­Action, è possibile bloccare l'accettazione di quest'agente dal server di OpsMgr, in caso l'azione sia ancora in sospeso. Se invece l'operazione è già stata eseguita, sarà necessario utilizzare il cmdlet Uninstall-Agent.

Come detto prima, è anche possibile utilizzare Install-­AgentByName per specificare il computer sul quale installare l'agente direttamente dalla riga di comando.

Lavorare con i management pack Esistono quattro cmdlet che ci aiutano con le varie operazioni sui management pack. È possibile elencarli digitando quanto segue:

Get-Command –noun ManagementPack

Questo semplice comando fornisce i management pack attualmente installati e i relativi numeri di versione:

Get-ManagementPack | Format-Table –autosize

Adesso utilizzerò la shell dei comandi per installare due comuni management pack utilizzando questi programmi di installazione:

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

Poiché il mio scopo è di mostrare come la shell dei comandi può semplificare l'esecuzione di operazioni periodiche, utilizzerò il numero minore di comandi possibile (come illustrato in Figura 8). Avrei potuto modificare la procedura di installazione e passare il flag "quiet" al programma di installazione (i file .msi), ma ho voluto scegliere la posizione dove i file sarebbero stati manualmente estratti.

Figura 8 Installazione dei management pack (fare clic sull'immagine per ingrandirla)

Adesso devo installare le librerie comuni col seguente comando:

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

Successivamente, installo gli altri management pack richiesti:

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

Come mostrato in Figura 9, la guida fornita con la shell dei comandi propone un esempio eccellente su come esportare i management pack non sottoposti a sealing, utilizzando il cmdlet Export-ManagementPack. Se si vogliono esportare tutti i management pack, modificare questa riga

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

 $mps=Get-ManagementPack

Figura 9 Esportazione di un management pack (fare clic sull'immagine per ingrandirla)

Operare con i ruoli utente Il cmdlet Get-UserRole fornisce alcune funzionalità per l'amministrazione degli utenti. Stranamente, non fornisce un cmdlet Set, sebbene generalmente non si necessiti di fare modifiche o aggiornamenti (come specificato nella documentazione dell'SDK di Windows PowerShell). Come si può vedere in Figura 10, inizialmente ottengo un elenco dei ruoli utente correnti e poi aggiungo un utente al gruppo Read-Only Operators (vedere Figura 11).

Figura 10 Visualizzazione di ruoli utente (fare clic sull'immagine per ingrandirla)

Figura 11 Aggiunta di un utente (fare clic sull'immagine per ingrandirla)

Attivazione degli Audit Collection Services (ACS) Gli ACS rappresentano una nuova funzionalità opzionale presente in Operations Manager 2007 che fornisce una modo centralizzato di trattare informazioni di controllo della protezione. Gli ACS non sono attivati per impostazione predefinita, ma possono essere configurati in occasione di una nuova distribuzione di OpsMgr.

Windows PowerShell risulta estremamente utile nel caso si volesse automatizzare l'installazione e l'attivazione di un ampio numero di agenti per gli ACS. Durante la fase beta di OpsMgr, Microsoft ha rilasciato uno script che permette di attivare gli ACS su tutti gli agenti. Neale Browne, collaboratore e blogger di SystemCenterForum.org, è andato un passo più avanti, aggiungendo il supporto per parametri aggiuntivi.

Il sito SystemCenterForum.org (una community che fornisce soluzioni per Microsoft® System Center) ha rilasciato due script per Windows PowerShell che permettono di automatizzare l'installazione degli ACS. Per installare tutti gli agenti appartenenti a un gruppo ben preciso è possibile scaricare questo file systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Per installare tutti gli agenti monitorati, scaricare systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.

Abilitare un proxy degli agenti L'ambiente di OpsMgr è in grado di contenere periferiche monitorate senza agenti. È necessario assegnare queste periferiche a un server di gestione o a una periferica gestita da agenti che fornirà il controllo remoto. In questa pagina systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell, è possibile trovare dettagli sul funzionamento di uno script di Windows PowerShell che permette di configurare numerosi agenti. Una versione aggiornata dello script è disponibile qui: systemcenterforum.org/wp-content/uploads/Set­AgentProxyBulk_FQDN.zip.

Ci sono altri casi nei quali determinati management pack richiedono l'impostazione di un agente come proxy. Per ulteriori dettagli consiglio di consultare la documentazione del management pack.

Il mondo reale

Ecco alcuni esempi reali per dimostrare ancora come Windows PowerShell può essere estremamente utile per l'automazione di operazioni.

Risoluzione di avvisi Vi siete mai trovati a dovere cancellare numerosi avvisi per un determinato computer? In alcuni casi per qualche motivo, un'applicazione non riesce a completare un'operazione o gli avvisi non vengono risolti attivamente. Ecco qui un comando di una sola riga che risolverà tutti gli avvisi il cui stato di risoluzione si trova a zero:

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

Il prossimo esempio realizza la stessa operazione del precedente, ma lo fa molto più velocemente in un ambiente più grande e con molti più avvisi:

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

La differenza di prestazioni è dovuta al parametro di criteri utilizzato. Il valore passato viene inviato direttamente al database SQL Server® e soltanto i dati rilevanti vengono restituiti. In questo modo si riduce il numero degli oggetti da restituire alla console di Windows PowerShell.

Adesso si ha a disposizione un modo veloce per rimuovere tutti gli avvisi in sospeso per un determinato computer. A seconda dell'ambiente in uso, è possibile impostare questo script per l'esecuzione automatica.

Infine, ecco un comando veloce che permette di visualizzare tutti gli avvisi per una data specifica:

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

È molto semplice modificare il valore della data ed è inoltre possibile inviare l'output al cmdlet Resolve-Alert.

Testare gli avvisi A volte si vogliono monitorare alcuni eventi nel Visualizzatore eventi di Windows e fare dei test. Queste due righe creeranno velocemente una voce nel registro degli eventi:

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

Per impostazione predefinita, questo script scriverà tuttavia sul registro eventi di Operations Manager, che non è probabilmente il primo posto dove si cerca un determinato evento. Fortunatamente, Stefan Stranger, Premier Field Engineer a Microsoft, ha scritto uno script che permette di creare eventi nel Visualizzatore eventi di Windows e fornisce maggiore flessibilità, dal momento che è capace di scrivere su un determinato registro. È possibile trovare questo script all'indirizzo go.microsoft.com/fwlink/?LinkId=120308. (Stefan ha compresso lo script in un file CAB. Sarà necessario scaricare il file e fare clic col tasto destro del mouse per estrarlo).

Si noti che utilizzando lo script di Stefan, il valore inserito per l'origine eventi determina il registro sul quale verrà effettuata la scrittura. Probabilmente il modo più facile per assicurarsi che l'avviso sia diretto verso il registro giusto è quella di aprire il Visualizzatore eventi di Windows e individuare la sorgente dell'ultima scrittura.

Impostazione del proprietario In alcuni casi può essere utile impostare automaticamente il proprietario di un avviso. Ecco qui un modo semplice per eseguire questa operazione dalla shell dei comandi:

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

La prima riga di questa porzione di codice ricava l'ID di un particolare oggetto avviso e lo passa alla variabile $alert. Nella seconda riga, questa variabile viene utilizzata per impostare il proprietario. Infine viene applicato l'aggiornamento al database di OpsMgr. Controllando il proprietario dell'avviso col seguente comando, è possibile vedere che esso è stato modificato:

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

Per impostare il proprietario per un'intera serie di avvisi, è possibile semplificare il codice come segue:

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

Ripristino dello stato di controllo Alcuni agenti non monitorati potrebbero subire dei cambiamenti. In questi casi potrebbe essere necessario ripristinare rapidamente tutti gli agenti a uno stato di controllo totale e poi cercare di determinare l'accaduto. Eseguendo lo script mostrato in Figura 12 direttamente dalla shell dei comandi si dovrebbe ripristinare il controllo totale di tutti gli agenti coinvolti.

Figura 12 Ripristino dell'archivio del servizio di integrità

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

Osservare il codice riportato in Figura 12. Dopo avere dichiarato una variabile, si ottiene un elenco di tutti gli agenti su questo RMS e vengono filtrati quelli che sembrano presentare dei problemi. Poi viene eseguita un'attività in modo asincrono per riavviare l'archivio del servizio di integrità degli agenti presenti nell'elenco filtrato.

Associare avvisi ai management pack Nella Figura 13viene mostrato come ottenere un elenco di tutti gli avvisi e i management pack ai quali sono associati.

Alcuni piccoli accorgimenti applicati al codice hanno permesso di risolvere tutti i nomi di management pack. I cmdlet utilizzati potranno variare a seconda che l'avviso sia una regola o un controllo. (Notare che nella Figura 13 è stato necessario implementare una piccola soluzione alternativa per il cmdlet di Get-Monitor. Dalla versione SP1 di OpsMgr, il cmdlet supporta un nuovo parametro ID che permette di semplificare leggermente il codice).

Figura 13 Individuare il management pack

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

Creare report facilmente Quando si aggiorna il proprio ambiente, potrebbe essere utile controllare le versioni di tutti gli agenti installati. Basta soltanto un semplice script per stampare un report:

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

Nella Figura 14 viene mostrato l'output dello script. Questo script è una versione più elaborata degli esempi presenti in questa pagina systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.

Figura 14 Output che mostra le versioni di alcuni agenti (fare clic sull'immagine per ingrandirla)

Pianificazione di un'attività In alcuni casi risulta necessario eseguire regolarmente uno script di Windows PowerShell. Poniamo che si utilizzi un client per connettersi e gestire un server di OpsMgr e che si abbiano gli strumenti di amministrazione di OpsMgr installati in locale. Supponiamo inoltre che si voglia creare un report sulla versione dell'agente ogni giorno e salvare l'output in un file, il cui nome sarà la data corrente. È possibile utilizzare l'utilità di pianificazione di Windows per eseguire lo script dal proprio computer locale.

Per fare ciò, è necessario semplicemente creare un'attività nuova, specificando powershell.exe come programma da eseguire (in genere si trova in C:\Windows\System32\WindowsPowerShell\v1.0). Successivamente, è necessario modificare l'attività e impostare il comando con qualcosa del genere:

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

Come si vede in Figura 15, è stato necessario fare alcune modifiche al codice originale di Windows PowerShell. È stato necessario aggiungere lo snap-in di PowerShell di OpsMgr, creare un'unità di controllo mappata al provider di Operations­ManagerMonitoring e infine creare una connessione all'RMS. Per avere a disposizione funzioni specifiche di OpsMgr, ho inoltre caricato lo script personalizzato di Windows PowerShell Ops­Mgr (Microsoft.Enterprise­Management.OperationsManager.ClientShell.Startup.ps1).

Figura 15 Pianificazione dello script agent-version

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

Ma non è tutto. Come si può vedere ogni volta che viene eseguita l'attività, se qualcuno ha eseguito l'accesso al computer, una finestra della console appare sullo schermo. Un piccolo trucco per evitare ciò è fornito da Don Jones e Jeffery Hicks della Sapien. Il codice è disponibile qui blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.

Fondamentalmente è necessario incorporare lo script all'interno di un VBScript. È quindi necessario è necessario utilizzare il codice mostrato in Figura 16 piuttosto che richiamare il seguente dall'attività pianificata:

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

Figura 16 Nascondere i popup

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

L'attività utilizza quindi il programma wscript.exe e il comando dovrebbe assomigliare a qualcosa del genere:

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

Infine, posso creare dei report automatici e il processo è nascosto agli utenti connessi.

Conclusioni

Ho dato uno sguardo alle nuove caratteristiche disponibili in OpsMgr 2007. Questo non è altro che una minima parte di ciò che è possibile fare con Windows PowerShell per l'amministrazione di OpsMgr.

Vorrei ringraziare tutti gli utenti citati nell'articolo, come pure Pete Zerger, fondatore di MOM MVP e SystemCenterForum.org, per il tuo notevole contributo.

Marco Shaw è un analista di sistemi informatici per un'azienda di telecomunicazioni canadese. Lavora nel mondo dell'informatica da più di 10 anni ed è stato recentemente riconosciuto come MVP per Windows PowerShell. Marco è anche vice direttore della nuova community di PowerShell powershellcommunity.org. Trovate Il suo blog su marcoshaw.blogspot.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.