Problemen met de Log Analytics-agent voor Windows oplossen
Dit artikel bevat hulp bij het oplossen van fouten die kunnen optreden met de Log Analytics-agent voor Windows in Azure Monitor en stelt mogelijke oplossingen voor om deze op te lossen.
Hulpprogramma voor het oplossen van problemen met Log Analytics
De Log Analytics-agent voor het hulpprogramma voor probleemoplossing voor Windows is een verzameling PowerShell-scripts die zijn ontworpen om problemen met de Log Analytics-agent te vinden en diagnosticeren. Deze wordt automatisch bij de installatie opgenomen bij de agent. Het uitvoeren van het hulpprogramma moet de eerste stap zijn bij het diagnosticeren van een probleem.
Het hulpprogramma voor probleemoplossing gebruiken
Open de PowerShell-prompt als beheerder op de computer waarop de Log Analytics-agent is geïnstalleerd.
Ga naar de map waar het hulpprogramma zich bevindt:
cd "C:\Program Files\Microsoft Monitoring Agent\Agent\Troubleshooter"Voer het hoofdscript uit met behulp van deze opdracht:
.\GetAgentInfo.ps1Selecteer een scenario voor probleemoplossing.
Volg de instructies op de console. Houd er rekening mee dat voor traceringslogboekstappen handmatige tussenkomst is vereist om het verzamelen van logboeken te stoppen. Wacht op basis van de reproduceerbaarheid van het probleem tot de tijdsduur en selecteer 's' om het verzamelen van logboeken te stoppen en ga verder met de volgende stap.
De locatie van het resultatenbestand wordt geregistreerd wanneer het is voltooid en er wordt een nieuw verkennervenster geopend.
Installatie
Het hulpprogramma voor probleemoplossing wordt automatisch opgenomen bij de installatie van de Log Analytics-agent build 10.20.18053.0 en hoger.
Scenario's die worden behandeld
Het hulpprogramma voor probleemoplossing controleert de volgende scenario's:
- De agent rapporteert geen gegevens of heartbeatgegevens ontbreken.
- De implementatie van de agentextensie mislukt.
- De agent loopt vast.
- De agent verbruikt een hoog CPU- of geheugengeheugen.
- Installatie- en verwijderingsfouten.
- Aangepaste logboeken hebben problemen.
- OMS Gateway heeft problemen.
- Prestatiemeteritems hebben problemen.
- Agentlogboeken kunnen niet worden verzameld.
Notitie
Voer het hulpprogramma voor probleemoplossing uit wanneer u een probleem ondervindt. Als u de logboeken in eerste instantie hebt, kan ons ondersteuningsteam uw probleem sneller oplossen.
Belangrijke bronnen voor probleemoplossing
Om u te helpen bij het oplossen van problemen met betrekking tot de Log Analytics-agent voor Windows, registreert de agent gebeurtenissen in het Windows-gebeurtenislogboek, met name onder Toepassing en Services\Operations Manager.
Connectiviteitsproblemen
Als de agent communiceert via een proxyserver of firewall, zijn er mogelijk beperkingen die communicatie van de broncomputer en de Azure Monitor-service verhinderen. Als communicatie wordt geblokkeerd vanwege een onjuiste configuratie, kan de registratie met een werkruimte mislukken tijdens het installeren van de agent of het configureren van de agent na de installatie om te rapporteren aan een andere werkruimte. Agentcommunicatie kan mislukken na een geslaagde registratie. In deze sectie worden de methoden beschreven voor het oplossen van dit type probleem met de Windows-agent.
Controleer of de firewall of proxy is geconfigureerd om de volgende poorten en URL's toe te staan die in de volgende tabel worden beschreven. Controleer ook of HTTP-inspectie niet is ingeschakeld voor webverkeer. Het kan een beveiligd TLS-kanaal tussen de agent en Azure Monitor voorkomen.
| Agentresource | Poorten | Richting | HTTPS-inspectie omzeilen |
|---|---|---|---|
| *.ods.opinsights.azure.com | Poort 443 | Uitgaand | Ja |
| *.oms.opinsights.azure.com | Poort 443 | Uitgaand | Ja |
| *.blob.core.windows.net | Poort 443 | Uitgaand | Ja |
| *.agentsvc.azure-automation.net | Poort 443 | Uitgaand | Ja |
Zie Azure Government-beheer voor informatie over firewalls die vereist zijn voor Azure Government. Als u van plan bent om azure Automation Hybrid Runbook Worker te gebruiken om verbinding te maken met en te registreren bij de Automation-service voor het gebruik van runbooks of beheeroplossingen in uw omgeving, moet deze toegang hebben tot het poortnummer en de URL's die worden beschreven in Uw netwerk configureren voor de Hybrid Runbook Worker.
Er zijn verschillende manieren waarop u kunt controleren of de agent succesvol communiceert met Azure Monitor:
Schakel de Azure Log Analytics Agent Health-evaluatie in de werkruimte in. Bekijk in het dashboard Status van agent de kolom Aantal niet-reagerende agents om snel te zien of de agent wordt vermeld.
Voer de volgende query uit om te bevestigen dat de agent een heartbeat verzendt naar de werkruimte waarnaar deze is geconfigureerd. Vervang door
<ComputerName>de werkelijke naam van de machine.Heartbeat | where Computer like "<ComputerName>" | summarize arg_max(TimeGenerated, * ) by ComputerAls de computer met de service communiceert, moet de query een resultaat retourneren. Als de query geen resultaat heeft geretourneerd, controleert u eerst of de agent is geconfigureerd om te rapporteren aan de juiste werkruimte. Als deze juist is geconfigureerd, gaat u verder met stap 3 en zoekt u in het Windows-gebeurtenislogboek om te bepalen of de agent het probleem vasthoudt waardoor het mogelijk niet kan communiceren met Azure Monitor.
Een andere methode om een verbindingsprobleem te identificeren, is door het hulpprogramma TestCloud Verbinding maken iviteit uit te voeren. Het hulpprogramma wordt standaard geïnstalleerd met de agent in de map %SystemRoot%\Program Files\Microsoft Monitoring Agent\Agent. Ga vanaf een opdrachtprompt met verhoogde bevoegdheid naar de map en voer het hulpprogramma uit. Het hulpprogramma retourneert de resultaten en geeft aan waar de test is mislukt. Het is bijvoorbeeld gerelateerd aan een bepaalde poort of URL die is geblokkeerd.
Filter het Operations Manager-gebeurtenislogboek op GebeurtenisbronnenHealth Service Modules, HealthService en Service Verbinding maken or en filter op Waarschuwing op gebeurtenisniveauen fout om te bevestigen of er gebeurtenissen uit de volgende tabel zijn geschreven. Als dat het geval is, bekijkt u de oplossingsstappen die zijn opgenomen voor elke mogelijke gebeurtenis.
Gebeurtenis-id Source Beschrijving Oplossing 2133 & 2129 Health Service Verbinding maken ion to the service from the agent failed. Deze fout kan optreden wanneer de agent niet rechtstreeks of via een firewall of proxyserver kan communiceren met de Azure Monitor-service. Controleer de proxy-instellingen van de agent of of de netwerkfirewall of proxy TCP-verkeer van de computer naar de service toestaat. 2138 Health Service-modules Voor de proxy is verificatie vereist. Configureer de proxy-instellingen voor de agent en geef de gebruikersnaam/het wachtwoord op die is vereist voor verificatie bij de proxyserver. 2129 Health Service-modules Verbinding is mislukt. Tls-onderhandeling is mislukt. Controleer de TCP/IP-instellingen van uw netwerkadapter en de proxy-instellingen van de agent. 2127 Health Service-modules Fout bij het verzenden van gegevens ontvangen foutcode. Als het alleen periodiek gedurende de dag gebeurt, kan het een willekeurige anomalie zijn die kan worden genegeerd. Bewaak om te begrijpen hoe vaak het gebeurt. Als dit de hele dag vaak gebeurt, controleert u eerst de netwerkconfiguratie en proxy-instellingen. Als de beschrijving HTTP-foutcode 404 bevat en het de eerste keer is dat de agent probeert gegevens naar de service te verzenden, bevat deze een 500-fout met een interne 404-foutcode. De foutcode 404 betekent 'niet gevonden', wat aangeeft dat het opslaggebied voor de nieuwe werkruimte nog steeds wordt ingericht. Bij de volgende nieuwe poging worden gegevens naar de werkruimte geschreven zoals verwacht. Een HTTP-fout 403 kan duiden op een probleem met machtigingen of referenties. Meer informatie is opgenomen in de 403-fout om het probleem op te lossen. 4000 App-connector DNS-naamomzetting is mislukt. Het internetadres dat wordt gebruikt bij het verzenden van gegevens naar de service, kan niet worden omgezet op de computer. Dit probleem kan dns-resolver-instellingen zijn op uw computer, onjuiste proxy-instellingen of een tijdelijk DNS-probleem met uw provider. Als dit periodiek gebeurt, kan dit worden veroorzaakt door een tijdelijk probleem met betrekking tot het netwerk. 4001 App-connector Verbinding maken van de service is mislukt. Deze fout kan optreden wanneer de agent niet rechtstreeks of via een firewall of proxyserver kan communiceren met de Azure Monitor-service. Controleer de proxy-instellingen van de agent of of de netwerkfirewall of proxy TCP-verkeer van de computer naar de service toestaat. 4002 App-connector De service heeft HTTP-statuscode 403 geretourneerd als reactie op een query. Neem contact op met de servicebeheerder voor de status van de service. De query wordt later opnieuw geprobeerd. Deze fout wordt geschreven tijdens de eerste registratiefase van de agent. U ziet een URL die lijkt op https:// workspaceID.oms.opinsights.azure.com/AgentService.svc/AgentTopologyRequest>.< Een 403-foutcode betekent 'verboden' en kan worden veroorzaakt door een verkeerd getypte werkruimte-id of -sleutel. De datum en tijd zijn mogelijk ook onjuist op de computer. Als de tijd +/- 15 minuten vanaf de huidige tijd is, mislukt de onboarding. U kunt dit probleem oplossen door de datum en/of tijd van uw Windows-computer bij te werken.
Problemen met het verzamelen van gegevens
Nadat de agent is geïnstalleerd en rapporteert aan de geconfigureerde werkruimte of werkruimten, kan het ontvangen van configuratie en het verzamelen of doorsturen van prestaties, logboeken of andere gegevens naar de service stoppen, afhankelijk van wat is ingeschakeld en gericht op de computer. U moet het volgende bepalen:
- Is het een bepaald gegevenstype of alle gegevens die niet beschikbaar zijn in de werkruimte?
- Wordt het gegevenstype opgegeven door een oplossing of opgegeven als onderdeel van de configuratie van de werkruimtegegevensverzameling?
- Hoeveel computers worden beïnvloed? Rapporteert één computer of meerdere computers aan de werkruimte?
- Werkte het en stopte het op een bepaald tijdstip van de dag, of is het nooit verzameld?
- Is de zoekquery voor logboeken die u syntactisch gebruikt?
- Heeft de agent ooit de configuratie ontvangen van Azure Monitor?
De eerste stap bij het oplossen van problemen is om te bepalen of de computer een heartbeat-gebeurtenis verzendt.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
Als de query resultaten retourneert, moet u bepalen of een bepaald gegevenstype niet wordt verzameld en doorgestuurd naar de service. Dit probleem kan worden veroorzaakt doordat de agent geen bijgewerkte configuratie van de service ontvangt of een ander symptoom dat voorkomt dat de agent normaal werkt. Voer de volgende stappen uit om verdere problemen op te lossen.
Open een opdrachtprompt met verhoogde bevoegdheid op de computer en start de agentservice opnieuw door in te voeren
net stop healthservice && net start healthservice.Open het Gebeurtenislogboek van Operations Manager en zoek naar gebeurtenis-id's7023, 7024, 7025, 7028 en 1210 uit de HealthService van de gebeurtenisbron. Deze gebeurtenissen geven aan dat de agent de configuratie van Azure Monitor heeft ontvangen en dat ze de computer actief controleren. De beschrijving van de gebeurtenis voor gebeurtenis-id 1210 geeft ook op de laatste regel alle oplossingen en inzichten op die zijn opgenomen in het bereik van bewaking op de agent.
Wacht enkele minuten. Als u de verwachte gegevens niet ziet in de queryresultaten of visualisatie, afhankelijk van of u de gegevens uit een oplossing of Insight bekijkt, zoekt u vanuit het Operations Manager-gebeurtenislogboek naar Statusservice- en Health Service-modules voor gebeurtenisbronnen. Filter op waarschuwing en fout op gebeurtenisniveauom te bevestigen of deze gebeurtenissen uit de volgende tabel heeft geschreven.
Gebeurtenis-id Source Beschrijving Oplossing 8000 HealthService Met deze gebeurtenis wordt opgegeven of een werkstroom met betrekking tot prestaties, gebeurtenissen of ander gegevenstype dat wordt verzameld, niet kan worden doorgestuurd naar de service voor opname naar de werkruimte. Gebeurtenis-id 2136 van bron HealthService wordt samen met deze gebeurtenis geschreven en kan aangeven dat de agent niet kan communiceren met de service. Mogelijke oorzaken zijn een onjuiste configuratie van de proxy- en verificatie-instellingen, netwerkstoring of de netwerkfirewall of proxy staat TCP-verkeer van de computer naar de service niet toe. 10102 en 10103 Health Service-modules De gegevensbron kan niet worden omgezet in de werkstroom. Dit probleem kan optreden als de opgegeven prestatiemeteritem of het opgegeven exemplaar niet op de computer bestaat of onjuist is gedefinieerd in de instellingen voor werkruimtegegevens. Als dit een door de gebruiker opgegeven prestatiemeteritem is, controleert u of de opgegeven gegevens de juiste indeling hebben en aanwezig zijn op de doelcomputers. 26002 Health Service-modules De gegevensbron kan niet worden omgezet in de werkstroom. Dit probleem kan optreden als het opgegeven Windows-gebeurtenislogboek niet bestaat op de computer. Deze fout kan veilig worden genegeerd als de computer niet verwacht dat dit gebeurtenislogboek is geregistreerd. Als dit een door de gebruiker opgegeven gebeurtenislogboek is, controleert u of de opgegeven informatie juist is.
Vastgemaakte certificaatproblemen met oudere Microsoft Monitoring Agents - Wijziging die fouten veroorzaakt
Overzicht van wijzigingen in basis-CA
Vanaf 30 juni 2023 accepteert Log Analytics-back-end geen verbindingen meer van MMA die verwijzen naar een verouderd basiscertificaat. Deze MMA's zijn oudere versies vóór de Winter 2020-release (Log Analytics Agent) en vóór SCOM 2019 UR3 (SCOM). Elke versie, Bundel: 10.20.18053/ Extensie: 1.0.18053.0 of hoger, heeft geen problemen, evenals een versie boven SCOM 2019 UR3. Een agent die ouder is dan die wordt onderbroken en niet meer werkt en uploadt naar Log Analytics.
Wat verandert er precies?
Als onderdeel van een voortdurende beveiligingsinspanningen in verschillende Azure-services, wordt Azure Log Analytics officieel overgeschakeld van de Baltimore CyberTrust CA Root naar de DigiCert Global G2 CA Root. Deze wijziging heeft invloed op TLS-communicatie met Log Analytics als het nieuwe DigiCert Global G2 CA-basiscertificaat ontbreekt in het besturingssysteem of de toepassing verwijst naar de oude Baltimore Root-CA. Dit betekent dat Log Analytics geen verbindingen meer accepteert van MMA die gebruikmaken van deze oude basis-CA nadat deze buiten gebruik is gesteld.
Oplossingsproducten
Mogelijk hebt u de melding voor wijziging die fouten veroorzaken ontvangen, zelfs als u de Microsoft Monitoring Agent niet persoonlijk hebt geïnstalleerd. Dat komt doordat verschillende Azure-producten gebruikmaken van de Microsoft Monitoring Agent. Als u een van deze producten gebruikt, wordt dit mogelijk beïnvloed door gebruik te maken van de Windows Log Analytics-agent. Voor deze producten met koppelingen hieronder vindt u mogelijk specifieke instructies waarvoor u een upgrade naar de nieuwste agent moet uitvoeren.
- VM Insights
- System Center Operations Manager (SCOM)
- System Center Service Manager (SCSM)
- Microsoft Defender voor Server
- Microsoft Defender voor Eindpunt
- Azure Sentinel
- Hybrid Worker op basis van Een Azure Automation-agent
- Azure Automation-Wijzigingen bijhouden en inventaris
- Azure Automation-updatebeheer
Agents identificeren en opnieuw toewijzen
Voor implementaties met een beperkt aantal agents raden we u ten zeerste aan om uw agent per knooppunt te upgraden via deze beheerinstructies.
Voor implementaties met meerdere knooppunten hebben we een script geschreven waarmee eventuele betrokken mma's per abonnement worden gedetecteerd en vervolgens worden bijgewerkt naar de nieuwste versie. Deze scripts moeten opeenvolgend worden uitgevoerd, te beginnen met UpdateMMA.ps1 en UpgradeMMA.ps1. Afhankelijk van de computer kan het uitvoeren van het script enige tijd duren. PowerShell 7 of hoger is nodig om een time-out te voorkomen.
UpdateMMA.ps1 Dit script doorloopt VM's in uw abonnementen, controleer op bestaande MMA's die zijn geïnstalleerd en genereer vervolgens een CSV-bestand met agents die moeten worden bijgewerkt.
UpgradeMMA.ps1 Dit script gebruikt de . CSV-bestand dat is gegenereerd in UpdateMMA.ps1 om alle belangrijke MMA's te upgraden.
Het kan even duren voordat beide scripts zijn voltooid.
# 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"
}
}