Felsöka Azure Stack HCI-registrering

Artikel
09/25/2024

Gäller för: Azure Stack HCI, version 22H2

Viktigt!

Felsökningsinstruktioner som anges i den här artikeln gäller för en äldre version, Azure Stack HCI, version 22H2. Information om hur du felsöker nya distributioner som kör den senaste allmänt tillgängliga versionen, Azure Stack HCI, version 23H2, finns i Få support för Azure Stack HCI-distributionsproblem.

Felsökning av Azure Stack HCI-registreringsproblem kräver att du tittar på både PowerShell-registreringsloggar och hcisvc-felsökningsloggar från varje server i klustret.

Samla in PowerShell-registreringsloggar

Register-AzStackHCI När cmdletarna och Unregister-AzStackHCI körs skapas loggfiler med namnet RegisterHCI_{yyyymmdd-hhss}.log och UnregisterHCI_{yyyymmdd-hhss}.log för varje försök. Du kan ange loggkatalogen för dessa loggfiler med hjälp av parametern -LogsDirectory i cmdleten Register-AzStackHCI och anropa Get-AzStackHCILogsDirectory för att hämta platsen. Som standard skapas dessa filer i C:\ProgramData\AzureStackHCI\Registration. För PowerShell-modulversion 2.1.2 eller tidigare skapas dessa filer i arbetskatalogen för PowerShell-sessionen där cmdletarna körs.

Som standard ingår inte felsökningsloggar. Om det finns ett problem som behöver ytterligare felsökningsloggar ställer du in felsökningsinställningen på Fortsätt genom att köra följande cmdlet innan du kör Register-AzStackHCI eller Unregister-AzStackHCI:

$DebugPreference = 'Continue'

Samla in lokala hcisvc-loggar

Om du vill aktivera felsökningsloggar för hcisvc kör du följande kommando i PowerShell på varje server i klustret:

wevtutil.exe sl /q /e:true Microsoft-AzureStack-HCI/Debug

Så här hämtar du loggarna:

Get-WinEvent -Logname Microsoft-AzureStack-HCI/Debug -Oldest -ErrorAction Ignore

Det gick inte att registrera. Det gick inte att generera ett självsignerat certifikat på noder {Node1,Node2}. Det gick inte att ange och verifiera registreringscertifikatet på noder {Node1,Node2}

Förklaring av feltillstånd:

Under registreringen måste varje server i klustret vara igång med utgående Internetanslutning till Azure. Cmdleten Register-AzStackHCI pratar med varje server i klustret för att etablera certifikat. Varje server använder sitt certifikat för att göra ett API-anrop till HCI-tjänster i molnet för att verifiera registreringen.

Om registreringen misslyckas kan följande meddelande visas: Det gick inte att registrera. Det gick inte att generera ett självsignerat certifikat på noder {Node1,Node2}. Det gick inte att ange och verifiera registreringscertifikatet på noder {Node1,Node2}

Om det finns nodnamn efter att det inte gick att generera självsignerat certifikat på noder i felmeddelandet kunde systemet inte generera certifikatet på dessa servrar.

Åtgärd:

Kontrollera att varje server som anges i meddelandet ovan är igång. Du kan kontrollera statusen för hcisvc genom att köra sc.exe query hcisvc och starta den om det behövs med start-service hcisvc.
Kontrollera att varje server som anges i felmeddelandet har anslutning till den dator där cmdleten Register-AzStackHCI körs. Kontrollera detta genom att köra följande cmdlet från datorn som Register-AzStackHCI körs, med hjälp av New-PSSession för att ansluta till varje server i klustret och kontrollera att den fungerar:
```
New-PSSession -ComputerName {failing nodes}
```

Om det finns nodnamn efter att det inte gick att ange och verifiera registreringscertifikatet på noderna i felmeddelandet kunde tjänsten generera certifikatet på servrarna, men servern/servrarna kunde inte anropa HCI-molntjänst-API:et. Så här felsöker du:

Kontrollera att varje server har den internetanslutning som krävs för att kommunicera med Azure Stack HCI-molntjänster och andra nödvändiga Azure-tjänster som Microsoft Entra-ID och att den inte blockeras av brandväggar. Se Brandväggskrav för Azure Stack HCI.
Prova att köra cmdleten Invoke-AzStackHciConnectivityValidation från modulen AzStackHCI.EnvironmentChecker och kontrollera att den lyckas. Den här cmdleten anropar hälsoslutpunkten för HCI-molntjänster för att testa anslutningen.
Titta på hcisvc-felsökningsloggarna på varje nod som anges i felmeddelandet.
- Det är OK att meddelandet ExecuteWithRetry-åtgärden AADTokenFetch misslyckades med ett nytt försöksfel visas några gånger innan det antingen misslyckas med ExecuteWithRetry-åtgärden AADTokenFetch misslyckades efter att alla återförsök eller ExecuteWithRetry-åtgärden AADTokenFetch lyckades försöka igen.
- Om åtgärden ExecuteWithRetry AADTokenFetch misslyckades efter alla återförsök i loggarna kunde systemet inte hämta Microsoft Entra-token från tjänsten även efter alla återförsök. Det finns ett associerat Microsoft Entra-undantag som loggas med det här meddelandet.
- Om du ser AADSTS700027: Klientkontroll innehåller en ogiltig signatur. [Orsak – Den nyckel som används har upphört att gälla. Tumavtryck för nyckeln som används av klienten: {SomeThumbprint}, Hittade nyckeln "Start=06/29/2021 21:13:15, End=06/29/2023 21:13:15", detta är ett problem med hur tiden anges på servern. Kontrollera UTC-tiden på alla servrar genom att köra [System.DateTime]::UtcNow i PowerShell och jämför den med den faktiska UTC-tiden. Om tiden inte är korrekt anger du rätt tider på servrarna och försöker registrera dig igen.

Att ta bort HCI-resursen från portalen och registrera samma kluster igen orsakar problem

Förklaring av feltillstånd:

Om du uttryckligen har tagit bort Azure Sack HCI-klusterresursen från Azure Portal utan att först avregistrera klustret från Windows Admin Center eller PowerShell, resulterar borttagning av en HCI Azure Resource Manager-resurs direkt från portalen i ett resurstillstånd för dåligt kluster. Avregistrering ska alltid utlösas inifrån HCI-klustret med hjälp av cmdleten Unregister-AzStackHCI för en ren avregistrering. I det här avsnittet beskrivs rensningssteg för scenarier där HCI-klusterresursen togs bort från portalen.

Åtgärd:

Logga in på den lokala HCI-klusterservern med autentiseringsuppgifterna för klusteranvändaren.
Kör cmdleten Unregister-AzStackHCI i klustret för att rensa klusterregistreringstillståndet och klustrets Arc-tillstånd.
- Om avregistreringen lyckas går du till Microsoft Entra ID > Appregistreringar (Alla program) och söker efter namnmatchningen clusterName och clusterName.arc. Ta bort de två app-ID:na om de finns.
- Om avregistreringen misslyckas med felet FEL: Det gick inte att inaktivera Azure Arc-integrering på nodnamnet <>kan du prova att köra cmdleten Disable-AzureStackHCIArcIntegration på noden. Om noden är i ett tillstånd där Disable-AzureStackHCIArcIntegration det inte går att köra noden tar du bort noden från klustret och försöker köra cmdleten Unregister-AzStackHCI igen. Logga in på varje enskild nod:
  1. Ändra katalogen till den plats där Arc-agenten är installerad: cd 'C:\Program Files\AzureConnectedMachineAgent\'.
  2. Hämta statusen för arcmagent.exe och ta reda på vilken Azure-resursgrupp den beräknas till: .\azcmagent.exe show. Utdata för det här kommandot visar resursgruppsinformationen.
  3. Tvinga bort Arc-agenten från noden: .\azcmagent.exe disconnect --force-local-only.
  4. Logga in på Azure Portal och ta bort Arc-for-Server-resursen från resursgruppen som fastställdes i steg ii.

Användaren har tagit bort app-ID:t av misstag

Förklaring av feltillstånd:

Om klustret är frånkopplat i mer än 8 timmar är det möjligt att de associerade Microsoft Entra-appregistreringarna som representerar HCI-klustret och Arc-registreringarna kan ha tagits bort av misstag. För att HCI-kluster- och Arc-scenarier ska fungera korrekt skapas två appregistreringar i klientorganisationen under registreringen.

Om app-ID<clustername>:t tas bort visar klusterresursen Azure-anslutning i Azure Portal Frånkopplad – Klustret är inte i anslutet tillstånd på mer än 8 timmar. Titta på HCIsvc-felsökningsloggarna på noden: felmeddelandet är Program med identifieraren "<ID>" hittades inte i katalogen "Standardkatalog". Detta kan inträffa om programmet inte har installerats av administratören för klientorganisationen eller godkänts av någon användare i klientorganisationen. Du kan ha skickat din autentiseringsbegäran till fel klientorganisation.
Om <clustername>.arc det skapas under Arc-aktiveringen tas inga synliga fel bort under normal drift. Den här identiteten krävs endast under registrering och avregistreringsprocesser. I det här scenariot misslyckas avregistreringen med felet Det gick inte att inaktivera Azure Arc-integrering på nodnodnamn<>. Prova att köra cmdleten Disable-AzureStackHCIArcIntegration på noden. Om noden är i ett tillstånd där cmdleten Disable-AzureStackHCIArcIntegration inte kunde köras tar du bort noden från klustret och försöker köra cmdleten Unregister-AzStackHCI igen.

Om du tar bort något av dessa program kan du inte kommunicera från HCI-klustret till molnet.

Åtgärd:

Om endast <clustername> AppId tas bort utför du en reparationsregistrering i klustret för att konfigurera Microsoft Entra-programmen:
```
Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -RepairRegistration
```
När du reparerar registreringen återskapas nödvändiga Microsoft Entra-program samtidigt som annan information bevaras, till exempel resursnamn, resursgrupp och andra registreringsval.
Om app-ID <clustername>.arc :t tas bort visas inga synliga fel i loggarna. Avregistreringen misslyckas om <clustername>.arc den tas bort. Om avregistreringen misslyckas följer du samma åtgärd som beskrivs i det här avsnittet.

Fel om att principen är slut

Förklaring av feltillstånd:

Om ett tidigare registrerat kluster visar statusen OutOfPolicy kan ändringar i systemkonfigurationen leda till att registreringsstatusen för Azure Stack HCI faller ur principen.

Systemändringar kan till exempel omfatta, men är inte begränsade till:

Inaktivering av inställningar för säker start med konflikter på den registrerade noden.
Rensning av TPM (Trusted Platform Module).
En betydande ändring av systemtiden.

Kommentar

Azure Stack HCI 21H2 med KB5010421 och senare versioner kommer att försöka återställa automatiskt från OutOfPolicy-tillståndet . Mer information om den aktuella OutOfPolicy-statusen och annan information finns i händelseloggen Microsoft-AzureStack-HCI/Admin.

Vilka "OutOfPolicy"-händelse-ID-meddelanden kan jag förvänta mig att se under registreringen?

Det finns tre typer av händelse-ID-meddelanden: information, varningar och fel.

Följande meddelanden var uppdateringar med Azure Stack HCI 21H2 med KB5010421 och visas inte om denna KB inte är installerad.

Informationshändelse-ID

Informationshändelse-ID-meddelanden som inträffar under registreringen. Granska och följ igenom eventuella förslag i meddelandet:

(Information) Händelse-ID 592: "Azure Stack HCI har initierat en reparation av sina data. Ingen ytterligare åtgärd från användaren krävs just nu."
(Information) Händelse-ID 594: "Azure Stack HCI påträffade ett fel vid åtkomst till dess data. Kontrollera vilka noder som påverkas om hela klustret är OutOfPolicy (kör Get-AzureStackHCI) och kör Unregister-AzStackHCI i klustret, starta om och kör sedan Register-AzStackHCI. Om endast den här noden påverkas tar du bort den här noden från klustret, startar om och väntar på att reparationen ska slutföras och återansluter sedan till klustret."

Varningshändelse-ID

Med varningsmeddelanden slutförs inte registreringens status. Det kan finnas eller kanske inte är ett problem. Granska först händelse-ID-meddelandet innan du utför några felsökningssteg.

(Varning) Händelse-ID 585: "Azure Stack HCI kunde inte förnya licensen från Azure. Om du vill få mer information om det specifika felet aktiverar du händelsekanalen Microsoft-AzureStack-HCI/Debug."

Kommentar

Möjliga fördröjningar vid återupprättande av en fullständig anslutning till Azure förväntas efter lyckad automatisk reparation och kan leda till att händelse-ID 585 visas. Detta påverkar inte arbetsbelastningar eller licensiering av noden. Det vill: det finns fortfarande en installerad licens, såvida inte noden var borta från 30-dagarsfönstret innan den automatiska reparationen.

Kommentar

I vissa fall kanske Azure Stack HCI inte lyckas med automatisk återställning. Detta kan inträffa när registreringsstatusen för alla noder i klustret inte har någon princip. Vissa manuella steg krävs. Se händelse-ID-meddelandena för Microsoft-AzureStack-HCI/Admin .

Felhändelse-ID

Händelse-ID-felmeddelanden identifierar ett fel i registreringsprocessen. Felmeddelandet innehåller instruktioner för hur du löser felet.

(Fel) Händelse-ID 591: "Azure Stack HCI kunde inte ansluta till Azure. Om du fortsätter att se det här felet kan du försöka köra Register-AzStackHCI igen med parametern -RepairRegistration ."
(Fel) Händelse-ID 594: "Azure Stack HCI påträffade ett fel vid åtkomst till dess data. Om du vill reparera kontrollerar du vilka noder som påverkas – om hela klustret är OutOfPolicy (kör Get-AzureStackHCI), kör Unregister-AzStackHCI på klustret, startar om och kör Register-AzStackHCIsedan . Om endast den här noden påverkas tar du bort den här noden från klustret, startar om, väntar tills reparationen har slutförts och återansluter sedan klustret.”

Kluster- och Arc-resursen i Azure Portal finns men get-AzureStackHCI-statusen säger "Inte ännu" registrerad

Förklaring av feltillstånd:

Det här problemet orsakas av avregistrering av ett HCI-kluster med fel molnmiljö eller felaktig prenumerationsinformation. Om en användare kör cmdleten Unregister-AzStackHCI med felaktiga -EnvironmentName eller -SubcriptionId parametrar för ett kluster tas klustrets registreringstillstånd bort från själva det lokala klustret, men klustret och Arc-resurserna i Azure Portal finns fortfarande i den ursprungliga miljön eller prenumerationen.

Till exempel:

Fel -EnvironmentName <value>: Du har registrerat klustret i -EnvironmentName AzureUSGovernment som i följande exempel. Standardvärdet -EnvironmentName är "Azurecloud". Du körde till exempel:
```
Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -EnvironmentName AzureUSGovernment
```
Men sedan körde du cmdleten Unregister-AzStackHCI med -EnvironmentName Azurecloud (standardvärdet) enligt följande:
```
Unregister-AzStackHCI -SubscriptionId "<subscription_ID>"
```
Fel -SubscriptionId <value>: Du har registrerat klustret med -SubscriptionId "<subscription_id_1>" följande:
```
Register-AzStackHCI  -SubscriptionId "<subscription_id_1>"
```
Men sedan körde du cmdleten Unregister-AzStackHCI för ett annat prenumerations-ID:
```
Unregister-AzStackHCI -SubscriptionId "<subscription_id_2>"
```

Åtgärd:

Ta bort klustret och Arc-resurserna från portalen.
Gå till Microsoft Entra ID > Appregistreringar (Alla program) och sök efter namnmatchningen <clusterName> och <clusterName>.arcta sedan bort de två app-ID:t.

Utfärdande av Sync-AzureStackHCI omedelbart efter omstart av noderna i klustret resulterar i att Arc-resursen tas bort

Förklaring av feltillstånd:

Om du utför en census-synkronisering före nodsynkronisering kan det leda till att synkroniseringen skickas till Azure, som inte innehåller noden. Detta resulterar i att Arc-resursen för noden tas bort. Cmdleten Sync-AzureStackHCI får endast användas för att felsöka HCI-klustrets molnanslutning. HCI-klustret har en liten uppvärmningstid efter en omstart för att stämma av klustertillståndet. Därför ska du inte köra Sync-AzureStackHCI strax efter omstarten av en nod.

Åtgärd:

På Azure Portal loggar du in på noden som visas som Inte installerad.

Koppla från Arc-agenten med följande två kommandon:

cd "C:\Program Files\AzureConnectedMachineAgent"

sedan...

.\azcmagent.exe disconnect --force-local-only

Reparera registreringen:

Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1  -RepairRegistration

Efter reparationsåtgärden återgår noden till ett anslutet tillstånd.

Registreringen har slutförts men Azure Arc-anslutningen i portalen säger Inte installerad

Scenario 1

Förklaring av feltillstånd:

Detta kan inträffa om den nödvändiga rollen Azure Connected Machine Resource Manager tas bort från HCI-resursprovidern i resursgruppen Arc-for-Server.

Du hittar behörigheten under bladet Åtkomstkontroll i resursgruppen i Azure Portal. Följande bild visar behörigheten:

Åtgärd:

Kör cmdleten för reparationsregistrering:

Register-AzStackHCI -TenantId "<tenant_ID>" -SubscriptionId "<subscription_ID>" -ComputerName Server1  -RepairRegistration

Scenario 2

Förklaring av feltillstånd:

Det här meddelandet kan också bero på ett tillfälligt problem som ibland uppstår när du utför Azure Stack HCI-registrering. När det händer Register-AzStackHCI visar cmdleten följande varningsmeddelande:

Åtgärd:

Vänta i 12 timmar efter registreringen för att problemet ska lösas automatiskt.

Scenario 3

Förklaring av feltillstånd:

Detta kan också inträffa när proxyn inte är korrekt konfigurerad för en anslutning till Azure ARC-molntjänster från HCI-noder. Du kan se följande fel i Arc-agentloggarna:

Åtgärd:

Lös problemet genom att följa riktlinjerna för att uppdatera proxyinställningarna. Registrera sedan Azure Stack HCI-klustret igen.

Det går inte att rotera certifikat i Fairfax och Mooncake

Förklaring av feltillstånd:

Från Azure Portal visar klusterresursen Azure Connection Frånkopplad.
Titta på HCIsvc-felsökningsloggarna på noden. Felmeddelandet är ett undantag: AADSTS700027: Verifieringen av klientkontrollen misslyckades.
Felet kan också visas eftersom RotateRegistrationCertificate misslyckades: Ogiltig målgrupp.

Åtgärd:

Utför en reparationsregistrering i klustret för att lägga till nya certifikat i Microsoft Entra-programmet:

Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -RepairRegistration

När du reparerar registreringen genereras nya ersättningscertifikat i Microsoft Entra-programmet, samtidigt som annan information bevaras, till exempel resursnamn, resursgrupp och andra registreringsalternativ.

OnPremisesPasswordValidationTimeSkew

Förklaring av feltillstånd:

Genereringen av Microsoft Entra-token misslyckas med ett tidsfel om den lokala nodtiden är för långt från synkronisering med sann aktuell tid (UTC). Microsoft Entra-ID returnerar följande fel:

AADSTS80013: OnPremisesPasswordValidationTimeSkew – Autentiseringsförsöket kunde inte slutföras på grund av tidsförskjutning mellan den dator som kör autentiseringsagenten och AD. Åtgärda problem med tidssynkronisering.

Åtgärd:

Se till att tiden synkroniseras till en känd och korrekt tidskälla.

Det gick inte att hämta token för klientorganisationen med fel

Förklaring av feltillstånd:

Om användarkontot som används för registrering ingår i flera Microsoft Entra-klienter måste du ange -TenantId under klusterregistreringen och avregistreringen. Annars misslyckas det med felet Det går inte att hämta token för klientorganisationen med fel. Du måste använda multifaktorautentisering för att få åtkomst till klientorganisationen. Kör igen Connect-AzAccount med ytterligare parameter -TenantId.

Åtgärd:

För klusterregistrering anger du parametern -TenantId :

Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -TenantId <Tenant_ID>

För avregistrering anger du parametern -TenantId :

Unregister-AzStackHCI -ComputerName ClusterNode1 -SubscriptionId "<subscription ID GUID>" -ResourceName HCI001 -TenantId <Tenant_ID>

En eller flera klusternoder kan inte ansluta till Azure

Förklaring av feltillstånd:

Det här problemet uppstår när en eller flera klusternoder hade anslutningsproblem efter registreringen och inte kunde ansluta till Azure på länge. Även efter lösningen av anslutningsproblem kan noderna inte återansluta till Azure på grund av de utgångna certifikaten.

Åtgärd:

Logga in på den frånkopplade noden.
Kör Disable-AzureStackHCIArcIntegration.
Kontrollera statusen för ARC-integreringen genom att köra Get-AzureStackHCIArcIntegration och se till att den nu står "Inaktiverad" för den frånkopplade noden:
Logga in på Azure Portal och ta bort Azure Resource Manager-resursen som representerar Arc-servern för den här noden.
Logga in på den frånkopplade noden igen och kör Enable-AzureStackHCIArcIntegration.
Kör Sync-AzureStackHCI på noden.

Jobbfel vid försök att skapa en virtuell dator

Förklaring av feltillstånd:

Om klustret inte har registrerats med Azure vid distributionen, eller om klustret är registrerat men inte har anslutit till Azure på mer än 30 dagar, tillåter systemet inte att nya virtuella datorer skapas eller läggs till. När detta inträffar visas följande felmeddelande när du försöker skapa virtuella datorer:

There was a failure configuring the virtual machine role for 'vmname'. Job failed. Error opening "vmname" clustered roles. The service being accessed is licensed for a particular number of connections. No more connections can be made to the service at this time because there are already as many connections as the service can accept.

Åtgärd:

Registrera ditt HCI-kluster med Azure. Information om hur du registrerar klustret finns i anvisningarna i dokumentationen register-AzStackHCI.

Använda en gemensam resursgrupp för kluster- och Arc-for-Server-resurser

Den senaste PowerShell-modulen har stöd för att ha en gemensam resursgrupp för både kluster- och Arc-for-Server-resurser, eller med någon befintlig resursgrupp för Arc-for-Server-resurser.

För kluster som registrerats med PowerShell-modulversion 1.4.1 eller tidigare kan du utföra följande steg för att använda den nya funktionen:

Avregistrera klustret genom att köra Unregister-AzStackHCI från en av noderna. Se Avregistrera Azure Stack HCI med PowerShell.
Installera den senaste PowerShell-modulen: Install-Module Az.StackHCI -Force.
Kör Register-AzStackHCI genom att skicka lämpliga parametrar för -ResourceGroupName och -ArcForServerResourceGroupName.

Kommentar

Om du använder en separat resursgrupp för Arc-for-Server-resurser rekommenderar vi att du använder en resursgrupp med Arc-for-Server-resurser som endast är relaterade till Azure Stack HCI. Azure Stack HCI-resursprovidern har behörighet att hantera andra Arc-for-Server-resurser i ArcServerResourceGroup.

Dela via

Felsöka Azure Stack HCI-registrering

Samla in PowerShell-registreringsloggar

Samla in lokala hcisvc-loggar

Det gick inte att registrera. Det gick inte att generera ett självsignerat certifikat på noder {Node1,Node2}. Det gick inte att ange och verifiera registreringscertifikatet på noder {Node1,Node2}

Att ta bort HCI-resursen från portalen och registrera samma kluster igen orsakar problem

Användaren har tagit bort app-ID:t av misstag

Fel om att principen är slut

Vilka "OutOfPolicy"-händelse-ID-meddelanden kan jag förvänta mig att se under registreringen?

Informationshändelse-ID

Varningshändelse-ID

Felhändelse-ID

Kluster- och Arc-resursen i Azure Portal finns men get-AzureStackHCI-statusen säger "Inte ännu" registrerad

Utfärdande av Sync-AzureStackHCI omedelbart efter omstart av noderna i klustret resulterar i att Arc-resursen tas bort

Registreringen har slutförts men Azure Arc-anslutningen i portalen säger Inte installerad

Scenario 1

Scenario 2

Scenario 3

Det går inte att rotera certifikat i Fairfax och Mooncake

OnPremisesPasswordValidationTimeSkew

Det gick inte att hämta token för klientorganisationen med fel

En eller flera klusternoder kan inte ansluta till Azure

Jobbfel vid försök att skapa en virtuell dator

Använda en gemensam resursgrupp för kluster- och Arc-for-Server-resurser

Nästa steg

Feedback

Ytterligare resurser