Řešení potíží s agentem Log Analytics pro Windows
Tento článek obsahuje nápovědu k řešení chyb, ke kterým může docházet u agenta Log Analytics pro Windows ve službě Azure Monitor a navrhuje možná řešení těchto chyb.
Nástroj pro řešení potíží s Log Analytics
Agent Log Analytics pro Nástroj pro řešení potíží s Windows je kolekce skriptů PowerShellu, které pomáhají najít a diagnostikovat problémy s agentem Log Analytics. Po instalaci je automaticky součástí agenta. Spuštění nástroje by mělo být prvním krokem při diagnostice problému.
Použití nástroje pro řešení potíží
Otevřete příkazový řádek PowerShellu jako správce na počítači, na kterém je nainstalovaný agent Log Analytics.
Přejděte do adresáře, kde se nástroj nachází:
cd "C:\Program Files\Microsoft Monitoring Agent\Agent\Troubleshooter"Spuštění hlavního skriptu pomocí tohoto příkazu:
.\GetAgentInfo.ps1Vyberte scénář řešení potíží.
Postupujte podle pokynů v konzole. Všimněte si, že kroky trasování protokolů vyžadují ruční zásah k zastavení shromažďování protokolů. Na základě reprodukovatelnosti problému počkejte na dobu trvání a výběrem možnosti "s" zastavte shromažďování protokolů a pokračujte dalším krokem.
Umístění souboru výsledků se zaprotokoluje po dokončení a otevře se nové okno průzkumníka.
Instalace
Nástroj pro řešení potíží se automaticky zahrne při instalaci agenta Log Analytics build 10.20.18053.0 a dále.
Probírané scénáře
Nástroj pro řešení potíží kontroluje následující scénáře:
- Agent nevykazuje data nebo chybí data prezenčních signálů.
- Nasazení rozšíření agenta selhává.
- Agent se chybově ukončí.
- Agent spotřebovává vysoké využití procesoru nebo paměti.
- Selhání instalace a odinstalace
- Vlastní protokoly mají problémy.
- U brány OMS došlo k problémům.
- Čítače výkonu mají problémy.
- Protokoly agenta se nedají shromažďovat.
Poznámka:
Pokud dojde k problému, spusťte nástroj pro řešení potíží. Počáteční protokoly nám pomůžou náš tým podpory rychleji vyřešit váš problém.
Důležité zdroje řešení potíží
Aby vám pomohl s řešením problémů souvisejících s agentem Log Analytics pro Windows, agent protokoluje události do protokolu událostí Systému Windows, konkrétně v části Aplikace a služby\Operations Manager.
Problémy s připojením
Pokud agent komunikuje přes proxy server nebo bránu firewall, můžou být omezení, která brání komunikaci ze zdrojového počítače a služby Azure Monitor. Pokud je komunikace zablokovaná kvůli chybné konfiguraci, může registrace pracovního prostoru selhat při pokusu o instalaci agenta nebo konfiguraci agenta po nastavení pro hlášení do jiného pracovního prostoru. Komunikace agenta může po úspěšné registraci selhat. Tato část popisuje metody řešení tohoto typu problému s agentem windows.
Pečlivě zkontrolujte, jestli je brána firewall nebo proxy server nakonfigurovaná tak, aby povolovala následující porty a adresy URL popsané v následující tabulce. Ověřte také, že pro webový provoz není povolená kontrola HTTP. Může zabránit zabezpečenému kanálu TLS mezi agentem a Azure Monitorem.
| Prostředek agenta | Porty | Směr | Obejití kontroly protokolu HTTPS |
|---|---|---|---|
| *.ods.opinsights.azure.com | Port 443 | Odchozí | Ano |
| *.oms.opinsights.azure.com | Port 443 | Odchozí | Ano |
| *.blob.core.windows.net | Port 443 | Odchozí | Ano |
| *.agentsvc.azure-automation.net | Port 443 | Odchozí | Ano |
Informace o bráně firewall vyžadované pro Azure Government najdete v tématu Správa služby Azure Government. Pokud plánujete používat funkci Hybrid Runbook Worker služby Azure Automation k připojení ke službě Automation a registraci k používání runbooků nebo řešení pro správu ve vašem prostředí, musí mít přístup k číslu portu a adresám URL popsaným v části Konfigurace sítě pro funkci Hybrid Runbook Worker.
Existuje několik způsobů, jak ověřit, jestli agent úspěšně komunikuje se službou Azure Monitor:
Povolte posouzení stavu agenta Azure Log Analytics v pracovním prostoru. Na řídicím panelu Stav agenta zobrazte sloupec Počet nereagujících agentů , abyste rychle zjistili, jestli je agent uvedený.
Spuštěním následujícího dotazu ověřte, že agent odesílá prezenční signál do pracovního prostoru, do kterého je nakonfigurovaný pro hlášení. Nahraďte
<ComputerName>skutečným názvem počítače.Heartbeat | where Computer like "<ComputerName>" | summarize arg_max(TimeGenerated, * ) by ComputerPokud počítač úspěšně komunikuje se službou, měl by dotaz vrátit výsledek. Pokud dotaz nevrátil výsledek, nejprve ověřte, že je agent nakonfigurovaný tak, aby hlásil správný pracovní prostor. Pokud je správně nakonfigurovaná, přejděte ke kroku 3 a v protokolu událostí Windows vyhledejte, jestli agent protokoluje problém, který mu může bránit v komunikaci se službou Azure Monitor.
Dalším způsobem identifikace problému s připojením je spuštěním nástroje TestCloud Připojení ivity. Nástroj se ve výchozím nastavení nainstaluje s agentem ve složce %SystemRoot%\Program Files\Microsoft Monitoring Agent\Agent. Z příkazového řádku se zvýšenými oprávněními přejděte do složky a spusťte nástroj. Nástroj vrátí výsledky a zvýrazní, kde došlo k selhání testu. Například to mohlo souviset s určitým portem nebo adresou URL, která byla blokovaná.
Vyfiltrujte protokol událostí Operations Manageru podle modulů služby Health Service, HealthService a Service Připojení or a vyfiltrujte podle upozornění na úrovniudálostí a chyby a ověřte, jestli obsahuje zapsané události z následující tabulky. Pokud ano, projděte si kroky řešení zahrnuté pro každou možnou událost.
ID události Source Popis Rozlišení 2133 & 2129 Služba Health Service Připojení do služby z agenta se nezdařilo. K této chybě může dojít, když agent nemůže komunikovat přímo nebo přes bránu firewall nebo proxy server se službou Azure Monitor. Ověřte nastavení proxy serveru agenta nebo ověřte, že síťová brána firewall nebo proxy server umožňují přenosy TCP z počítače do služby. 2138 Moduly služby Health Service Proxy server vyžaduje ověření. Nakonfigurujte nastavení proxy serveru agenta a zadejte uživatelské jméno a heslo potřebné k ověření pomocí proxy serveru. 2129 Moduly služby Health Service Připojení se nezdařilo. Vyjednávání protokolu TLS se nezdařilo. Zkontrolujte nastavení tcp/IP síťového adaptéru a nastavení proxy agenta. 2127 Moduly služby Health Service Při odesílání dat došlo k chybě s kódem chyby. Pokud se to stane jen pravidelně během dne, může se jednat o náhodnou anomálii, kterou lze ignorovat. Monitorujte, abyste pochopili, jak často k tomu dochází. Pokud k tomu dochází často během dne, nejprve zkontrolujte konfiguraci sítě a nastavení proxy serveru. Pokud popis obsahuje kód chyby HTTP 404 a při prvním pokusu agenta odesílat data do služby, bude obsahovat chybu 500 s vnitřním kódem chyby 404. Kód chyby 404 znamená nenalezené, což znamená, že oblast úložiště pro nový pracovní prostor je stále zřízená. Při dalším opakování se data úspěšně zapisují do pracovního prostoru podle očekávání. Chyba HTTP 403 může znamenat problém s oprávněním nebo přihlašovacími údaji. Další informace jsou součástí chyby 403, která vám pomůže tento problém vyřešit. 4000 Konektor služby Překlad názvů DNS se nezdařil. Počítač nemohl přeložit internetovou adresu použitou při odesílání dat do služby. Tento problém může být nastavením překladače DNS na vašem počítači, nesprávným nastavením proxy serveru nebo dočasným problémem s DNS u vašeho poskytovatele. Pokud k tomu dojde pravidelně, může to být způsobeno přechodným problémem souvisejícím se sítí. 4001 Konektor služby Připojení ion do služby se nezdařil. K této chybě může dojít, když agent nemůže komunikovat přímo nebo přes bránu firewall nebo proxy server se službou Azure Monitor. Ověřte nastavení proxy serveru agenta nebo ověřte, že síťová brána firewall nebo proxy server umožňují přenosy TCP z počítače do služby. 4002 Konektor služby Služba vrátila stavový kód HTTP 403 v reakci na dotaz. Zkontrolujte stav služby u správce služeb. Dotaz se bude opakovat později. Tato chyba se zapíše během počáteční fáze registrace agenta. Zobrazí se adresa URL podobná https:// workspaceID.oms.opinsights.azure.com/AgentService.svc/AgentTopologyRequest>.< Kód chyby 403 znamená "zakázáno" a může být způsoben chybným zadáním ID nebo klíče pracovního prostoru. Datum a čas mohou být také v počítači nesprávné. Pokud je čas od aktuálního času +/- 15 minut, onboarding selže. Chcete-li tento problém vyřešit, aktualizujte datum a/nebo čas počítače s Windows.
Problémy se shromažďováním dat
Po instalaci agenta a hlášení do nakonfigurovaného pracovního prostoru nebo pracovních prostorů může přestat přijímat konfiguraci a shromažďovat nebo předávat výkon, protokoly nebo jiná data do služby v závislosti na tom, co je povolené a cílí na počítač. Potřebujete určit:
- Jedná se o konkrétní datový typ nebo všechna data, která nejsou v pracovním prostoru dostupná?
- Je datový typ určený řešením nebo zadaný jako součást konfigurace shromažďování dat pracovního prostoru?
- Kolik počítačů se to týká? Jedná se o jeden počítač nebo více počítačů, které se hlásí do pracovního prostoru?
- Fungovalo to a zastavilo se v určité denní době, nebo se nikdy neshromažďovalo?
- Je dotaz prohledávání protokolu, který používáte syntakticky správný?
- Obdržel agent někdy svou konfiguraci ze služby Azure Monitor?
Prvním krokem při řešení potíží je určení, jestli počítač odesílá událost prezenčních signálů.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
Pokud dotaz vrátí výsledky, musíte určit, jestli se konkrétní datový typ neshromažďuje a nepředává službě. Příčinou tohoto problému může být to, že agent nedostává aktualizovanou konfiguraci ze služby nebo nějaký jiný příznak, který brání normálnímu fungování agenta. Při dalším řešení potíží proveďte následující kroky.
Na počítači otevřete příkazový řádek se zvýšenými oprávněními a restartujte službu agenta zadáním
net stop healthservice && net start healthservicepříkazu .Otevřete protokol událostí Operations Manageru a vyhledejte ID událostí7023, 7024, 7025, 7028 a 1210 ze služby HealthService zdrojeudálostí. Tyto události značí, že agent úspěšně přijímá konfiguraci ze služby Azure Monitor a aktivně monitoruje počítač. Popis události pro ID události 1210 také určí na posledním řádku všechna řešení a Přehledy, které jsou zahrnuté v rozsahu monitorování agenta.
Počkejte několik minut. Pokud ve výsledcích dotazu nebo vizualizaci nevidíte očekávaná data, v závislosti na tom, jestli si prohlížíte data z řešení nebo přehledu, v protokolu událostí Operations Manageru vyhledejte moduly HealthService a Health Service. Vyfiltrujte upozornění na úrovniudálostí a chybu a ověřte, jestli obsahuje zapsané události z následující tabulky.
ID události Source Popis Rozlišení 8000 HealthService Tato událost určí, jestli pracovní postup související s výkonem, událostí nebo jiným shromážděným datovým typem nemůže předat službě pro příjem dat do pracovního prostoru. ID události 2136 ze zdrojové služby HealthService je zapsáno společně s touto událostí a může indikovat, že agent nemůže komunikovat se službou. Možné důvody můžou být chybné konfigurace nastavení proxy serveru a ověřování, výpadku sítě nebo síťové brány firewall nebo proxy serveru nepovolují přenosy TCP z počítače do služby. 10102 a 10103 Moduly služby Health Service Pracovní postup nemohl přeložit zdroj dat. K tomuto problému může dojít, pokud zadaný čítač výkonu nebo instance v počítači neexistuje nebo je nesprávně definován v nastavení dat pracovního prostoru. Pokud se jedná o čítač výkonu zadaný uživatelem, ověřte, zda zadané informace mají správný formát a existují na cílových počítačích. 26002 Moduly služby Health Service Pracovní postup nemohl přeložit zdroj dat. K tomuto problému může dojít v případě, že zadaný protokol událostí systému Windows v počítači neexistuje. Tuto chybu je možné bezpečně ignorovat, pokud počítač nemá zaregistrovaný tento protokol událostí. Jinak pokud se jedná o protokol událostí zadaný uživatelem, ověřte správnost zadaných informací.
Problémy s připnutým certifikátem u starších agentů Microsoft Monitoring Agents – Zásadní změna
Přehled změn kořenové certifikační autority
Od 30. června 2023 už back-end Log Analytics nepřijímá připojení z MMA, která odkazují na zastaralý kořenový certifikát. Tyto agenty MMA jsou starší verze před verzí Winter 2020 (Log Analytics Agent) a před SCOM 2019 UR3 (SCOM). Libovolná verze, sada: 10.20.18053 / Rozšíření: 1.0.18053.0 nebo novější, nebudou mít žádné problémy ani žádné verze nad SCOM 2019 UR3. Jakýkoli agent starší, než je ten, který přestane fungovat a už nefunguje a nahraje do Log Analytics.
Co přesně se mění?
V rámci průběžného úsilí o zabezpečení napříč různými službami Azure se Služba Azure Log Analytics oficiálně přepne z kořenové certifikační autority Baltimore CyberTrust na kořen certifikační autority DigiCert Global G2. Tato změna ovlivní komunikaci protokolu TLS s Log Analytics, pokud v operačním systému chybí nový kořenový certifikát CA DigiCert Global G2 nebo aplikace odkazuje na starou kořenovou certifikační autoritu Baltimore. To znamená, že Služba Log Analytics už nebude přijímat připojení z MMA, která po vyřazení používají tuto starou kořenovou certifikační autoritu.
Produkty řešení
Možná jste obdrželi oznámení o změně způsobující chybu, i když jste nenainstalovali agenta Microsoft Monitoring Agent. Důvodem je to, že různé produkty Azure využívají agenta Microsoft Monitoring Agent. Pokud používáte některý z těchto produktů, může vás to ovlivnit, protože využívají agenta Windows Log Analytics. Pro tyto produkty s odkazy níže mohou existovat konkrétní pokyny, které budou vyžadovat upgrade na nejnovějšího agenta.
- Přehledy virtuálních počítačů
- System Center Operations Manager (SCOM)
- System Center Service Manager (SCSM)
- Microsoft Defender for Server
- Microsoft Defender for Endpoint
- Azure Sentinel
- Hybrid Worker založený na agentech Azure Automation
- Azure Automation Sledování změn a inventář
- Azure Automation – Update Management
Identifikaceach
Pro nasazení s omezeným počtem agentů důrazně doporučujeme upgradovat agenta na uzel pomocí těchto pokynů pro správu.
Pro nasazení s více uzly jsme napsali skript, který zjistí všechny ovlivněné chyby MMA na předplatné a následně je upgraduje na nejnovější verzi. Tyto skripty se musí spouštět postupně, počínaje aktualizací UpdateMMA.ps1 a pak UpgradeMMA.ps1. V závislosti na počítači může skript chvíli trvat. Ke spuštění PowerShellu 7 nebo vyššího je potřeba, aby nedocházelo k vypršení časového limitu.
UpdateMMA.ps1 Tento skript projde virtuálními počítači ve vašich předplatných, zkontroluje nainstalované agenty MMA a pak vygeneruje soubor .csv agentů, kteří je potřeba upgradovat.
UpgradeMMA.ps1 Tento skript bude používat . Soubor CSV vygenerovaný v updateMMA.ps1 pro upgrade všech zásadních MMA.
Dokončení obou těchto skriptů může chvíli trvat.
# UpdateMMA.ps1
# This script is to be run per subscription, the customer has to set the az subscription before running this within the terminal scope.
# This script uses parallel processing, modify the $parallelThrottleLimit parameter to either increase or decrease the number of parallel processes
# PS> .\UpdateMMA.ps1 GetInventory
# The above command will generate a csv file with the details of VM's and VMSS that require MMA upgrade.
# The customer can modify the csv by adding/removing rows if needed
# Update the MMA by running the script again and passing the csv file as parameter as shown below:
# PS> .\UpdateMMA.ps1 Upgrade
# If you don't want to check the inventory, then run the script wiht an additional -no-inventory-check
# PS> .\UpdateMMA.ps1 GetInventory & .\UpdateMMA.ps1 Upgrade
# This version of the script requires Powershell version >= 7 in order to improve performance via ForEach-Object -Parallel
# https://docs.microsoft.com/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.1
if ($PSVersionTable.PSVersion.Major -lt 7)
{
Write-Host "This script requires Powershell version 7 or newer to run. Please see https://docs.microsoft.com/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.1."
exit 1
}
$parallelThrottleLimit = 16
$mmaFixVersion = [version]"10.20.18053.0"
function GetVmsWithMMAInstalled
{
param(
$fileName
)
$vmList = az vm list --show-details --query "[?powerState=='VM running'].{ResourceGroup:resourceGroup, VmName:name}" | ConvertFrom-Json
if(!$vmList)
{
Write-Host "Cannot get the VM list, this script can only detect the running VM's"
return
}
$vmsCount = $vmList.Length
$vmParallelThrottleLimit = $parallelThrottleLimit
if ($vmsCount -lt $vmParallelThrottleLimit)
{
$vmParallelThrottleLimit = $vmsCount
}
if($vmsCount -eq 1)
{
$vmGroups += ,($vmList[0])
}
else
{
# split the vm's into batches to do parallel processing
for ($i = 0; $i -lt $vmsCount; $i += $vmParallelThrottleLimit)
{
$vmGroups += , ($vmList[$i..($i + $vmParallelThrottleLimit - 1)])
}
}
Write-Host "Detected $vmsCount Vm's running in this subscription."
$hash = [hashtable]::Synchronized(@{})
$hash.One = 1
$vmGroups | Foreach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$len = $using:vmsCount
$hash = $using:hash
$_ | ForEach-Object {
$percent = 100 * $hash.One++ / $len
Write-Progress -Activity "Getting VM Inventory" -PercentComplete $percent
$vmName = $_.VmName
$resourceGroup = $_.ResourceGroup
$responseJson = az vm run-command invoke --command-id RunPowerShellScript --name $vmName -g $resourceGroup --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
if($responseJson)
{
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$extensionName = az vm extension list -g $resourceGroup --vm-name $vmName --query "[?name == 'MicrosoftMonitoringAgent'].name" | ConvertFrom-Json
if ($extensionName)
{
$installType = "Extension"
}
else
{
$installType = "Installer"
}
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VM"
'Install_Type' = $installType
'Version' = $mmaVersion
"Instance_Id" = ""
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
}
}
}
function GetVmssWithMMAInstalled
{
param(
$fileName
)
# get the vmss list which are successfully provisioned
$vmssList = az vmss list --query "[?provisioningState=='Succeeded'].{ResourceGroup:resourceGroup, VmssName:name}" | ConvertFrom-Json
$vmssCount = $vmssList.Length
Write-Host "Detected $vmssCount Vmss running in this subscription."
$hash = [hashtable]::Synchronized(@{})
$hash.One = 1
$vmssList | Foreach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$len = $using:vmssCount
$hash = $using:hash
$percent = 100 * $hash.One++ / $len
Write-Progress -Activity "Getting VMSS Inventory" -PercentComplete $percent
$vmssName = $_.VmssName
$resourceGroup = $_.ResourceGroup
# get running vmss instance ids
$vmssInstanceIds = az vmss list-instances --resource-group $resourceGroup --name $vmssName --expand instanceView --query "[?instanceView.statuses[1].displayStatus=='VM running'].instanceId" | ConvertFrom-Json
if ($vmssInstanceIds.Length -gt 0)
{
$isMMAExtensionInstalled = az vmss extension list -g $resourceGroup --vmss-name $vmssName --query "[?name == 'MicrosoftMonitoringAgent'].name" | ConvertFrom-Json
if ($isMMAExtensionInstalled )
{
# check an instance in vmss, if it needs an MMA upgrade. Since the extension is installed at VMSS level, checking for bad version in 1 instance should be fine.
$responseJson = az vmss run-command invoke --command-id RunPowerShellScript --name $vmssName -g $resourceGroup --instance-id $vmssInstanceIds[0] --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmssName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VMSS"
'Install_Type' = "Extension"
'Version' = $mmaVersion
"Instance_Id" = ""
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
else
{
foreach ($instanceId in $vmssInstanceIds)
{
$responseJson = az vmss run-command invoke --command-id RunPowerShellScript --name $vmssName -g $resourceGroup --instance-id $instanceId --scripts '@UpgradeMMA.ps1' --parameters "functionName=GetMMAVersion" --output json | ConvertFrom-Json
$mmaVersion = $responseJson.Value[0].message
if ($mmaVersion)
{
$csvObj = New-Object -TypeName PSObject -Property @{
'Name' = $vmssName
'Resource_Group' = $resourceGroup
'Resource_Type' = "VMSS"
'Install_Type' = "Installer"
'Version' = $mmaVersion
"Instance_Id" = $instanceId
}
$csvObj | Export-Csv $using:fileName -Append -Force
}
}
}
}
}
}
function Upgrade
{
param(
$fileName = "MMAInventory.csv"
)
Import-Csv $fileName | ForEach-Object -ThrottleLimit $parallelThrottleLimit -Parallel {
$mmaVersion = [version]$_.Version
if($mmaVersion -lt $using:mmaFixVersion)
{
if ($_.Install_Type -eq "Extension")
{
if ($_.Resource_Type -eq "VMSS")
{
# if the extension is installed with a custom name, provide the name using the flag: --extension-instance-name <extension name>
az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --force-update --vmss-name $_.Name --resource-group $_.Resource_Group --no-wait --output none
}
else
{
# if the extension is installed with a custom name, provide the name using the flag: --extension-instance-name <extension name>
az vm extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --force-update --vm-name $_.Name --resource-group $_.Resource_Group --no-wait --output none
}
}
else {
if ($_.Resource_Type -eq "VMSS")
{
az vmss run-command invoke --command-id RunPowerShellScript --name $_.Name -g $_.Resource_Group --instance-id $_.Instance_Id --scripts '@UpgradeMMA.ps1' --parameters "functionName=UpgradeMMA" --output none
}
else
{
az vm run-command invoke --command-id RunPowerShellScript --name $_.Name -g $_.Resource_Group --scripts '@UpgradeMMA.ps1' --parameters "functionName=UpgradeMMA" --output none
}
}
}
}
}
function GetInventory
{
param(
$fileName = "MMAInventory.csv"
)
# create a new file
New-Item -Name $fileName -ItemType File -Force
GetVmsWithMMAInstalled $fileName
GetVmssWithMMAInstalled $fileName
}
switch ($args.Count)
{
0 {
Write-Host "The arguments provided are incorrect."
Write-Host "To get the Inventory: Run the script as: PS> .\UpdateMMA.ps1 GetInventory"
Write-Host "To update MMA from Inventory: Run the script as: PS> .\UpdateMMA.ps1 Upgrade"
Write-Host "To do the both steps together: PS> .\UpdateMMA.ps1 GetInventory & .\UpdateMMA.ps1 Upgrade"
}
1 {
$funcname = $args[0]
Invoke-Expression "& $funcname"
}
2 {
$funcname = $args[0]
$funcargs = $args[1]
Invoke-Expression "& $funcname $funcargs"
}
}