Felsöka problem i Azure Stack Hub

  • Artikel

Det här dokumentet innehåller felsökningsinformation för Azure Stack Hub-integrerade miljöer. Om du vill ha hjälp med Azure Stack Development Kit kan du läsa asdk-felsökning eller få hjälp av experter på MSDN-forumet för Azure Stack Hub.

Vanliga frågor och svar

De här avsnitten innehåller länkar till dokument som beskriver vanliga frågor som skickas till Microsoft Support.

Att tänka på innan du köper

Uppdateringar och diagnostik

Operativsystem och storlekar som stöds för virtuella gästdatorer

Azure Marketplace

Hantera kapacitet

Minne

Om du vill öka den totala tillgängliga minneskapaciteten för Azure Stack Hub kan du lägga till ytterligare minne. I Azure Stack Hub kallas din fysiska server även för en skalningsenhetsnod. Alla noder för skalningsenhet som hör till samma skalningsenhet måste ha samma mängd minne.

Kvarhållningsperiod

Med inställningen för kvarhållningsperiod kan en molnoperatör ange en tidsperiod i dagar (mellan 0 och 9999 dagar) under vilken ett borttaget konto potentiellt kan återställas. Standardkvarhållningsperioden är inställd på 0 dagar. Om värdet anges till 0 innebär det att alla borttagna konton omedelbart har slut på kvarhållning och markeras för periodisk skräpinsamling.

Säkerhet, efterlevnad och identitet

Hantera RBAC

En användare i Azure Stack Hub kan vara läsare, ägare eller deltagare för varje instans av en prenumeration, resursgrupp eller tjänst.

Om de inbyggda rollerna för Azure-resurser inte uppfyller organisationens specifika krav, kan du skapa egna anpassade roller. För den här självstudien skapar du en anpassad roll med namnet Reader Support Tickets (Läsare av supportbegäranden) med hjälp av Azure PowerShell.

Hantera användning och fakturering som molnlösningsleverantör

Välj den typ av konto för delade tjänster som du använder för Azure Stack Hub. De typer av prenumerationer som kan användas för registrering av en Azure Stack Hub för flera klientorganisationer är:

  • Molnlösningsleverantör
  • Partner Shared Services-prenumeration

Hämta mått för skalningsenhet

Du kan använda PowerShell för att få information om stämpelanvändning utan hjälp från Microsoft Support. Så här hämtar du stämpelanvändning:

  1. Skapa en PEP-session.

  2. Kör följande kommando:

    Test-AzureStack

  3. Avsluta PEP-sessionen.

  4. Kör följande med ett Invoke-Command-anrop:

    Get-AzureStackLog -FilterByRole SeedRing

  5. Extrahera seedring .zip. Du kan hämta valideringsrapporten från MAPPEN ERCS där du körde Test-AzureStack.

Mer information finns i Azure Stack Hub Diagnostics.

Felsöka virtuella datorer

Återställ lösenord för virtuell Linux-dator

Om du glömmer lösenordet för en virtuell Linux-dator och alternativet Återställ lösenord inte fungerar på grund av problem med VMAccess-tillägget kan du utföra en återställning enligt följande steg:

  1. Välj en virtuell Linux-dator som ska användas som en virtuell återställningsdator.

  2. Logga in på användarportalen:

    1. Anteckna vm-storleken, nätverkskortet, den offentliga IP-adressen, NSG:n och datadiskarna.
    2. Stoppa den berörda virtuella datorn.
    3. Ta bort den berörda virtuella datorn.
    4. Koppla disken från den berörda virtuella datorn som en datadisk på den virtuella återställningsdatorn (det kan ta några minuter innan disken är tillgänglig).

  3. Logga in på den virtuella återställningsdatorn och kör följande kommando:

    sudo su -
mkdir /tempmount
fdisk -l
mount /dev/sdc2 /tempmount /*adjust /dev/sdc2 as necessary*/
chroot /tempmount/
passwd root /*substitute root with the user whose password you want to reset*/
rm -f /.autorelabel /*Remove the .autorelabel file to prevent a time consuming SELinux relabel of the disk*/
exit /*to exit the chroot environment*/
umount /tempmount

  4. Logga in på användarportalen:

    1. Koppla från disken från den virtuella återställningsdatorn.
    2. Återskapa den virtuella datorn från disken.
    3. Se till att överföra den offentliga IP-adressen från den tidigare virtuella datorn, koppla datadiskarna osv.

Du kan också ta en ögonblicksbild av den ursprungliga disken och skapa en ny disk från den i stället för att utföra ändringarna direkt på den ursprungliga disken. Mer information finns i de här ämnena:

Licensaktiveringen misslyckas för Windows Server 2012 R2 under etableringen

I det här fallet går det inte att aktivera Windows och du ser en vattenstämpel i det nedre högra hörnet på skärmen. De WaSetup.xml loggarna som finns under C:\Windows\Panther innehåller följande händelse:

<Event time="2019-05-16T21:32:58.660Z" category="ERROR" source="Unattend">
    <UnhandledError>
        <Message>InstrumentProcedure: Failed to execute 'Call ConfigureLicensing()'. Will raise error to caller</Message>
        <Number>-2147221500</Number>
        <Description>Could not find the VOLUME_KMSCLIENT product</Description>
        <Source>Licensing.wsf</Source>
    </UnhandledError>
</Event>

Om du vill aktivera licensen kopierar du AVMA-nyckeln (Automatic Virtual Machine Activation) för den SKU som du vill aktivera.

Utgåva AVMA-nyckel
Datacenter Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

Kör följande kommando på den virtuella datorn:

slmgr /ipk <AVMA_key>

Fullständig information finns i Aktivering av virtuella datorer.

En Windows Server-avbildning och ett galleriobjekt måste läggas till innan du distribuerar virtuella datorer i Azure Stack Hub.

Jag har tagit bort vissa virtuella datorer, men ser fortfarande VHD-filerna på disken

Det här beteendet är avsiktligt:

  • När du tar bort en virtuell dator tas inte virtuella hårddiskar bort. Diskar är separata resurser i resursgruppen.
  • När ett lagringskonto tas bort visas borttagningen direkt via Azure Resource Manager. Men diskarna som den kan innehålla lagras fortfarande tills skräpinsamlingen körs.

Om du ser "överblivna" virtuella hårddiskar är det viktigt att veta om de ingår i mappen för ett lagringskonto som har tagits bort. Om lagringskontot inte togs bort är det normalt att de fortfarande finns kvar.

Du kan läsa mer om hur du konfigurerar kvarhållningströskeln och återtagning på begäran i hantera lagringskonton.

Felsöka Storage

Lagringsåtertagning

Det kan ta upp till 14 timmar innan den återvunna kapaciteten visas i portalen. Utrymmesåtertagning beror på olika faktorer, inklusive användningsprocent av interna containerfiler i blockblobarkivet. Beroende på hur mycket data som tas bort finns det därför ingen garanti för mängden utrymme som kan frigöras när skräpinsamlaren körs.

Azure Storage Explorer fungerar inte med Azure Stack Hub

Om du använder ett integrerat system i ett frånkopplat scenario rekommenderar vi att du använder en certifikatutfärdare för företag (CA). Exportera rotcertifikatet i base-64-format och importera det sedan i Azure Storage Explorer. Se till att du tar bort det avslutande snedstrecket (/) från Resource Manager slutpunkten. Mer information finns i Förbereda för anslutning till Azure Stack Hub.

Felsöka App Service

Create-AADIdentityApp.ps1 skriptet misslyckas

Om det Create-AADIdentityApp.ps1 skriptet som krävs för App Service misslyckas måste du inkludera den obligatoriska -AzureStackAdminCredential parametern när du kör skriptet. Mer information finns i Förutsättningar för att distribuera App Service på Azure Stack Hub.

Felsöka Azure Stack Hub-uppdateringar

Azure Stack Hub-korrigerings- och uppdateringsprocessen är utformad för att tillåta operatörer att tillämpa uppdateringspaket på ett konsekvent och strömlinjeformat sätt. Även om det är ovanligt kan problem uppstå under korrigerings- och uppdateringsprocessen. Följande steg rekommenderas om du stöter på ett problem under korrigerings- och uppdateringsprocessen:

  1. Förutsättningar: Se till att du har följt checklistan för uppdateringsaktivitet och aktiverat proaktiv logginsamling.

  2. Följ reparationsstegen i felaviseringen som skapades när uppdateringen misslyckades.

  3. Om du inte har kunnat lösa problemet skapar du en Azure Stack Hub-supportbegäran. Se till att du har loggar som samlats in för tidsintervallet när problemet inträffade. Om en uppdatering misslyckas, antingen med en kritisk avisering eller en varning, är det viktigt att du granskar felet och kontaktar Microsofts kundtjänst enligt anvisningarna i aviseringen så att skalningsenheten inte förblir i ett feltillstånd under en längre tid. Om du lämnar en skalningsenhet i ett misslyckat uppdateringstillstånd under en längre tid kan det orsaka ytterligare problem som är svårare att lösa senare.

Vanliga problem med korrigeringar och uppdateringar i Azure Stack Hub

Gäller för: Azure Stack Hub-integrerade system

PreparationFailed

Tillämpligt: Det här problemet gäller för alla versioner som stöds.

Orsak: När du försöker installera Azure Stack Hub-uppdateringen kan statusen för uppdateringen misslyckas och ändra tillståndet till PreparationFailed. För internetanslutna system är detta vanligtvis ett tecken på att uppdateringspaketet inte kan laddas ned korrekt på grund av en svag internetanslutning.

Reparation: Du kan kringgå det här problemet genom att klicka på Installera nu igen. Om problemet kvarstår rekommenderar vi att du laddar upp uppdateringspaketet manuellt genom att följa avsnittet Installera uppdateringar .

Förekomst: Vanligt

Uppdateringen misslyckades: Kontrollera och framtvinga externa nyckelskydd på CSV:er

Tillämpligt: Det här problemet gäller för alla versioner som stöds.

Orsak: BMC-lösenordet (Baseboard Management Controller) har inte angetts korrekt.

Reparation: Uppdatera BMC-autentiseringsuppgifterna och återuppta uppdateringen.

Varningar och fel som rapporteras när uppdateringen pågår

Tillämpligt: Det här problemet gäller för alla versioner som stöds.

Orsak: När Azure Stack Hub-uppdateringen är i status Pågår kan varningar och fel rapporteras i portalen. Komponenter kan överskrida tidsgränsen för att vänta på andra komponenter under uppgraderingen, vilket resulterar i ett fel. Azure Stack Hub har en mekanism för att försöka igen eller åtgärda vissa av uppgifterna på grund av tillfälliga fel.

Reparation: När Azure Stack Hub-uppdateringen är i status Pågår kan varningar och fel som rapporteras i portalen ignoreras.

Förekomst: Vanligt

Uppdateringen 2002 misslyckades

Tillämpligt: Det här problemet gäller endast 2002-versionen.

Orsak: När du försöker uppdatera 2002 kan uppdateringen misslyckas och det här meddelandet visas: The private network parameter is missing from cloud parameters. Please use set-azsprivatenetwork cmdlet to set private networkTrace.

Reparation: Konfigurera ett privat internt nätverk.