Dela via


Åtgärda fel för resurs som inte hittades

Den här artikeln beskriver felet du ser när en resurs inte kan hittas under en åtgärd. Vanligtvis visas det här felet när du distribuerar resurser med en Bicep-fil eller En Azure Resource Manager-mall (ARM-mall). Du ser också det här felet när du utför hanteringsuppgifter och Azure Resource Manager kan inte hitta den nödvändiga resursen. Om du till exempel försöker lägga till taggar till en resurs som inte finns får du det här felet.

Symptome

Det finns två felkoder som anger att resursen inte kan hittas. Felet NotFound returnerar ett resultat som liknar:

Code=NotFound;
Message=Cannot find ServerFarm with name exampleplan.

Felet ResourceNotFound returnerar ett resultat som liknar:

Code=ResourceNotFound;
Message=The Resource 'Microsoft.Storage/storageAccounts/{storage name}' under resource
group {resource group name} was not found.

Orsak

Resource Manager måste hämta egenskaperna för en resurs, men det går inte att hitta resursen i din prenumeration.

Lösning 1: Kontrollera resursegenskaper

Om du utför en hanteringsuppgift och får det här felet kontrollerar du de värden som du har angett för resursen. De tre värdena som ska kontrolleras är:

  • Resursnamn
  • Namn på resursgrupp
  • Prenumeration

Om du använder PowerShell eller Azure CLI kontrollerar du att du kör kommandon i prenumerationen som innehåller resursen. Du kan ändra prenumerationen med Set-AzContext eller az account set. Många kommandon tillhandahåller en prenumerationsparameter som gör att du kan ange en annan prenumeration än den aktuella kontexten.

Om du inte kan verifiera egenskaperna loggar du in på Microsoft Azure-portalen. Leta upp den resurs som du försöker använda och granska resursnamnet, resursgruppen och prenumerationen.

Lösning 2: Ange beroenden

Om du får det här felet när du distribuerar en mall kan du behöva lägga till ett beroende. Resource Manager optimerar distributioner genom att skapa resurser parallellt, när det är möjligt.

När du till exempel distribuerar en webbapp måste App Service-planen finnas. Om du inte har angett att webbappen är beroende av App Service-planen skapar Resource Manager båda resurserna samtidigt. Webbappen misslyckas med ett fel om att App Service-planresursen inte kan hittas eftersom den inte finns ännu. Du kan förhindra det här felet genom att ange ett beroende i webbappen.

Använd ett implicit beroende i stället för funktionen resourceId . Beroendet skapas med hjälp av en resurs symboliska namn och ID-egenskap.

Till exempel använder webbappens serverFarmId-egenskap servicePlan.id för att skapa ett beroende av App Service-planen.

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  properties: {
    serverFarmId: servicePlan.id
  }
}

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  ...

För de flesta distributioner är det inte nödvändigt att använda dependsOn för att skapa ett explicit beroende.

Undvik att ange beroenden som inte behövs. Onödiga beroenden förlänger distributionens varaktighet eftersom resurserna inte distribueras parallellt. Du kan också skapa cirkulära beroenden som blockerar distributionen.

Distributionsordning

När du ser beroendeproblem måste du få insikt i ordningen på resursdistributionen. Du kan använda portalen för att visa ordningen på distributionsåtgärderna:

  1. Logga in på portalen.

  2. I resursgruppens Översikt väljer du länken för distributionshistoriken.

    Skärmbild av Azure-portalen som markerar länken till en resursgrupps distributionshistorik i avsnittet Översikt.

  3. För det distributionsnamn som du vill granska väljer du Relaterade händelser.

    Skärmbild av Azure-portalen som visar ett distributionsnamn med länken Relaterade händelser markerad i distributionshistoriken.

  4. Granska händelsesekvensen för varje resurs. Var uppmärksam på statusen för varje åtgärd och dess tidsstämpel. Följande bild visar till exempel tre lagringskonton som distribuerats parallellt. Observera att de tre distributionerna av lagringskontot startade samtidigt.

    Skärmbild av aktivitetsloggen i Azure-portalen som visar tre lagringskonton som distribuerats parallellt, med deras tidsstämplar och statusar.

    Nästa bild visar tre lagringskonton som inte distribueras parallellt. Det andra lagringskontot beror på det första lagringskontot och det tredje lagringskontot är beroende av det andra lagringskontot. Det första lagringskontot har etiketten Startad, Godkänd och Lyckades innan nästa startas.

    Skärmbild av aktivitetsloggen i Azure-portalen som visar tre lagringskonton som distribuerats i sekventiell ordning, med deras tidsstämplar och statusar.

Lösning 3: Hämta extern resurs

Bicep använder det symboliska namnet för att skapa ett implicit beroende av en annan resurs. Det befintliga nyckelordet refererar till en distribuerad resurs. Om en befintlig resurs finns i en annan resursgrupp än den resurs som du vill distribuera tar du med omfånget och använder funktionen resourceGroup .

I det här exemplet distribueras en webbapp som använder en befintlig App Service-plan från en annan resursgrupp.

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' existing = {
  name: hostingPlanName
  scope: resourceGroup(rgname)
}

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: siteName
  properties: {
    serverFarmId: servicePlan.id
  }
}

Lösning 4: Hämta hanterad identitet från resurs

Om du distribuerar en resurs med en hanterad identitet måste du vänta tills resursen har distribuerats innan du hämtar värden på den hanterade identiteten. Använd ett implicit beroende för den resurs som identiteten tillämpas på. Den här metoden säkerställer att resursen och den hanterade identiteten distribueras innan Resource Manager använder beroendet.

Du kan hämta huvud-ID och klient-ID för en hanterad identitet som tillämpas på en virtuell dator. Om en virtuell maskinresurs till exempel har ett symboliskt namn vm, använder du följande syntax:

vm.identity.principalId

vm.identity.tenantId

Lösning 5: Kontrollera funktioner

Du kan använda en resurss symboliska namn för att hämta värden från en resurs. Du kan referera till ett lagringskonto i samma resursgrupp eller en annan resursgrupp med ett symboliskt namn. Om du vill hämta ett värde från en distribuerad resurs använder du det befintliga nyckelordet. Om en resurs finns i en annan resursgrupp använder du scope med funktionen resourceGroup . I de flesta fall behövs inte referensfunktionen .

Följande exempel refererar till ett befintligt lagringskonto i en annan resursgrupp.

resource stgAcct 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
  name: stgname
  scope: resourceGroup(rgname)
}

Lösning 6: Efter borttagning av resurs

När du tar bort en resurs kan det ta en kort stund när resursen visas i portalen men inte är tillgänglig. Om du väljer resursen får du ett felmeddelande om att resursen inte hittas.

Skärmbild av Azure-portalen som visar en borttagen resurs med felmeddelandet

Uppdatera portalen så ska den borttagna resursen tas bort från listan över tillgängliga resurser. Om en borttagen resurs fortsätter att visas som tillgänglig i mer än några minuter kontaktar du supporten.