Felsöka Integration Runtime (lokal installation)
GÄLLER FÖR:
Azure Data Factory Azure Synapse Analytics Microsoft Purview
Dricks
Prova Data Factory i Microsoft Fabric, en allt-i-ett-analyslösning för företag. Microsoft Fabric omfattar allt från dataflytt till datavetenskap, realtidsanalys, business intelligence och rapportering. Lär dig hur du startar en ny utvärderingsversion kostnadsfritt!
I den här artikeln beskrivs vanliga felsökningsmetoder för lokalt installerad integrationskörning (IR) i Azure Data Factory och Synapse-arbetsytor.
Samla in lokalt installerade IR-loggar
Azure Data Factory och Azure Synapse Analytics
För misslyckade aktiviteter som körs på en lokalt installerad IR eller en delad IR stöder tjänsten visning och uppladdning av felloggar. Om du vill hämta felrapport-ID följer du anvisningarna här och anger sedan rapport-ID:t för att söka efter relaterade kända problem.
På sidan Övervaka för tjänstgränssnittet väljer du Pipelinekörningar.
Under Aktivitetskörningar går du till kolumnen Fel och väljer den markerade knappen för att visa aktivitetsloggarna, enligt följande skärmbild:
Aktivitetsloggarna visas för den misslyckade aktivitetskörningen.
Om du vill ha mer hjälp väljer du Skicka loggar.
IR-loggarna (Share the self-hosted Integration Runtime) med Microsoft öppnas.
Välj vilka loggar du vill skicka.
- För en lokalt installerad IR kan du ladda upp loggar som är relaterade till den misslyckade aktiviteten eller alla loggar på den lokalt installerade IR-noden.
- För en delad IR kan du bara ladda upp loggar som är relaterade till den misslyckade aktiviteten.
När loggarna laddas upp behåller du ett register över rapport-ID:t för senare användning om du behöver ytterligare hjälp med att lösa problemet.
Kommentar
Loggvisning och uppladdningsbegäranden körs på alla lokala IR-instanser online. Om några loggar saknas kontrollerar du att alla lokalt installerade IR-instanser är online.
Microsoft Purview
För misslyckade Microsoft Purview-aktiviteter som körs på en lokalt installerad IR eller delad IR stöder tjänsten visning och uppladdning av felloggar från Windows-Loggboken.
Du kan söka efter eventuella fel som visas i felguiden nedan. För att få support- och felsökningsvägledning för SHIR-problem kan du behöva generera ett felrapport-ID och kontakta Microsofts support.
Följ dessa instruktioner för att generera felrapport-ID för Microsoft Support:
Innan du startar en genomsökning i Microsoft Purview-styrningsportalen:
- Gå till den dator där den lokalt installerade integrationskörningen är installerad och öppna Windows-Loggboken.
- Rensa Windows Loggboken-loggarna i avsnittet Integration Runtime. Högerklicka på loggarna och välj alternativet Rensa loggar.
- Gå tillbaka till Microsoft Purview-styrningsportalen och starta genomsökningen.
När genomsökningen visar statusEn misslyckades går du tillbaka till den virtuella SHIR-datorn eller datorn och uppdaterar loggboken i avsnittet Integration Runtime .
Aktivitetsloggarna visas för den misslyckade genomsökningskörningen.
Om du vill ha mer hjälp från Microsoft väljer du Skicka loggar.
Dela loggarna för lokalt installerad integreringskörning (SHIR) med Microsoft-fönstret öppnas.
Välj vilka loggar du vill skicka.
- För en lokalt installerad IR kan du ladda upp loggar som är relaterade till den misslyckade aktiviteten eller alla loggar på den lokalt installerade IR-noden.
- För en delad IR kan du bara ladda upp loggar som är relaterade till den misslyckade aktiviteten.
När loggarna laddas upp behåller du ett register över rapport-ID:t för senare användning om du behöver ytterligare hjälp med att lösa problemet.
Kommentar
Loggvisning och uppladdningsbegäranden körs på alla lokala IR-instanser online. Om några loggar saknas kontrollerar du att alla lokalt installerade IR-instanser är online.
Allmänt fel eller fel i lokalt installerad IR
Problem med slut på minne
Symtom
Ett OutOfMemoryException-fel (OOM) inträffar när du försöker köra en sökningsaktivitet med en länkad IR eller en lokalt installerad IR.
Orsak
En ny aktivitet kan leda till ett OOM-fel om IR-datorn har en tillfälligt hög minnesanvändning. Problemet kan orsakas av en stor mängd samtidig aktivitet, och felet beror på designen.
Lösning
Kontrollera resursanvändningen och samtidig aktivitetskörning på IR-noden. Justera den interna och utlösande tiden för aktivitetskörningar för att undvika för mycket körning på en enda IR-nod samtidigt.
Problem med gräns för samtidiga jobb
Symtom
När du försöker öka gränsen för samtidiga jobb från användargränssnittet låser sig processen i Uppdateringsstatus .
Exempelscenario: Det maximala värdet för samtidiga jobb är för närvarande inställt på 24 och du vill öka antalet så att jobben kan köras snabbare. Det minsta värde som du kan ange är 3, och det högsta värdet är 32. Du ökar värdet från 24 till 32 och väljer sedan knappen Uppdatera . Processen fastnar i Uppdateringsstatus , enligt följande skärmbild. Du uppdaterar sidan men värdet visas fortfarande som 24. Den har inte uppdaterats till 32 som förväntat.
Orsak
Gränsen för antalet samtidiga jobb beror på datorns logikkärna och minne. Försök att ändra värdet nedåt till exempelvis 24 och visa sedan resultatet.
Dricks
- Mer information om antalet logiska kärnor och hur du fastställer antalet för din dator finns i Fyra sätt att hitta antalet kärnor på i din Windows 10-processor.
- Om du vill lära dig att beräkna math.log går du till Logaritmkalkylatorn.
Problem med SSL-certifikat för lokalt installerad IR med hög tillgänglighet (HA)
Symtom
En arbetsnoden för lokalt installerad IR har rapporterat följande fel:
”Det gick inte att hämta delade tillstånd från den primära noden net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Aktivitets-ID: XXXXX Det gick inte att bygga en kedja för X.509-certifikat CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft. Certifikatet som användes har en förtroendekedja som inte kan verifieras. Ersätt certifikatet eller ändra certificateValidationMode. Återkallningsfunktionen kunde inte göra någon återkallningskontroll eftersom återkallningsservern var offline."
Orsak
När du hanterar fall som rör en SSL/TLS-handskakning kan du stöta på problem som rör verifiering av certifikatkedjan.
Lösning
Här är ett snabbt och intuitivt sätt att felsöka ett versionsfel för X.509-certifikatkedjan:
Exportera certifikatet, som måste verifieras. Det gör du så här:
a. I Windows väljer du Start, börjar skriva certifikat och väljer sedan Hantera datorcertifikat.
b. I Utforskarens vänstra ruta söker du efter det certifikat som du vill kontrollera, högerklickar på det och väljer sedan Alla aktiviteter>Exportera.
Kopiera det exporterade certifikatet till klientdatorn.
Kör följande kommando i kommandotolken på klientsidan. Se till att ersätta <certifikatsökvägen> och< utdatafilens sökväg> med de faktiska sökvägarna.
Certutil -verify -urlfetch <certificate path> > <output txt file path>Till exempel:
Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txtSök efter fel i TXT-utdatafilen. Du hittar felsammanfattningen i slutet av TXT-filen.
Till exempel:
Om du inte ser något fel i slutet av loggfilen, som du ser i följande skärmbild, kan du överväga att certifikatkedjan har skapats på klientdatorn.
Om filnamnstillägget AIA (Authority Information Access), CDP (CRL Distribution Point) eller OCSP (Online Certificate Status Protocol) har konfigurerats i certifikatfilen kan du kontrollera det på ett mer intuitivt sätt:
Hämta den här informationen genom att kontrollera certifikatinformationen enligt följande skärmbild:
Kör följande kommando. Se till att ersätta <certifikatsökvägen> med certifikatets faktiska sökväg.
Certutil -URL <certificate path>Verktyget för URL-hämtning öppnas.
Om du vill verifiera certifikat med filnamnstilläggen AIA, CDP och OCSP väljer du Hämta.
Du har skapat certifikatkedjan om certifikatstatusen från AIA är Verifierad och certifikatstatusen från CDP eller OCSP är Verifierad.
Om du misslyckas när du försöker hämta AIA eller CDP arbetar du med nätverksteamet för att förbereda klientdatorn för att ansluta till mål-URL:en. Det räcker om antingen HTTP-sökvägen eller LDAP-sökvägen (Lightweight Directory Access Protocol) kan verifieras.
Lokalt installerad IR kunde inte läsa in filen eller sammansättningen
Symtom
Följande felmeddelande visas:
”Det går inte att läsa in filen eller sammansättningen XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXX eller något av dess beroenden. Det går inte att hitta den angivna filen. Aktivitets-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”
Här är ett mer specifikt felmeddelande:
”Det går inte att läsa in filen eller sammansättningen 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX eller något av dess beroenden. Det går inte att hitta den angivna filen. Aktivitets-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”
Orsak
I Processövervakaren kan du visa följande resultat:
Dricks
I Processövervakaren kan du ange filter enligt följande skärmbild.
I föregående felmeddelande står det att DLL System.ValueTuple inte finns i den relaterade mappen Global Assembly Cache (GAC), i mappen C:\Program Files\Microsoft Integration Runtime\4.0\Gateway , eller i mappen C:\Program\Microsoft Integration Runtime\4.0\Shared .
I grund och botten läser processen in DLL först från GAC-mappen, sedan från den delade mappen och slutligen från gatewaymappen. Därför kan du läsa in DLL-filen från valfri användbar sökväg.
Lösning
Du hittar filen System.ValueTuple.dll i mappen C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan . Lös problemet genom att kopiera filen System.ValueTuple.dll till mappen C:\Program Files\Microsoft Integration Runtime\4.0\Gateway .
Du kan använda samma metod för att lösa andra problem med saknad fil eller sammansättning.
Mer information om det här problemet
Anledningen till att du ser System.ValueTuple.dll under %windir%\Microsoft.NET\assembly och %windir%\assembly är att detta är ett .NET-beteende.
I följande fel kan du tydligt se att sammansättningen System.ValueTuple saknas. Det här problemet uppstår när programmet försöker kontrollera System.ValueTuple.dll sammansättning.
"<LogProperties><ErrorInfo>[{"Code":0,"Message":"Typinitieraren för 'Npgsql.PoolManager' utlöste ett undantag.","EventType":0,"Kategori":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Kultur=neutral, PublicKeyToken=XXXXXXXXX' eller något av dess beroenden. Systemet kan inte hitta den angivna filen.","EventType":0,"Kategori":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Källa":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"
Mer information om GAC finns i Global sammansättningscache.
Autentiseringsnyckeln för lokalt installerad IR saknas
Symtom
Den lokalt installerad integrationskörningen kopplas plötsligt från utan en autentiseringsnyckel, och du ser följande felmeddelande i loggboken:
”Autentiseringsnyckeln har inte tilldelats ännu”
Orsak
- Den lokalt installerade IR-noden eller den logiska lokalt installerade IR i portalen har tagits bort.
- En ren avinstallation utfördes.
Lösning
Om ingen av ovanstående orsaker gäller kan du gå till mappen %programdata%\Microsoft\Data Transfer\DataManagementGateway för att se om konfigurationsfilen har tagits bort. Om den har tagits bort följer du anvisningarna i Netwrix-artikeln Identifiera vem som tagit bort en fil från dina Windows-filservrar.
Det går inte att använda lokalt installerad IR till att överbrygga två lokala datalager
Symtom
När du har skapat lokalt installerade IR-instanser för både käll- och måldatalager vill du ansluta dina två IR för att utföra en kopiering. Om datalagren är konfigurerade i olika virtuella nätverk, eller om datalagren inte kan förstå gatewaymekanismen, ser du något av följande fel:
- ”Källans drivrutin hittas inte i IR-målet”
- ”Källan kan inte nås av IR-målet”
Orsak
Din lokalt installerade IR är utformad som en central nod i en kopieringsaktivitet, inte en klientagent som behöver installeras för varje datalager.
I det här fallet ska du skapa den länkade tjänsten för varje datalager med samma IR, då bör IR kunna komma åt båda datalagren via nätverket. Det spelar ingen roll om din IR är installerad i källdatalagret eller måldatalagret, eller i en tredje dator. Om du skapar två länkade tjänster med olika IR men som används i samma kopieringsaktivitet används IR-målet, och du måste installera drivrutinerna för båda datalagren på IR-måldatorn.
Lösning
Installera drivrutiner för både källan och målet på IR-målet och se till att den kan komma åt källdatalagret.
Om trafiken inte kan passera genom nätverket mellan två datalager (om de till exempel är konfigurerade i två virtuella nätverk) kanske du inte kan kopiera i en enda aktivitet även om IR är installerat. Om du inte kan utföra kopieringen i en enda aktivitet kan du skapa två kopieringsaktiviteter med två IR, var och en i en VENT:
- Kopiera en IR från datalager 1 till Azure Blob Storage
- Kopiera en annan IR från Azure Blob Storage till datalager 2.
Den här lösningen kan simulera kravet att använda din IR för att skapa en brygga som ansluter två frånkopplade datalager.
Problem med synkronisering av autentiseringsuppgifter orsakar att autentiseringsuppgifter försvinner från HA
Symtom
Om datakällans autentiseringsuppgift ”XXXXXXXXXX” tas bort från den aktuella integreringskörningsnoden med nyttolasten, får du följande felmeddelande:
”När du tar bort länktjänsten på Azure Portal, eller uppgiften har fel nyttolast, ska du på nytt skapa en ny länktjänst med dina autentiseringsuppgifter.”
Orsak
Din lokalt installerade IR är skapad i HA-läge med två noder, men noderna är inte i ett synkroniseringstillstånd för autentiseringsuppgifter. Det innebär att autentiseringsuppgifterna som lagras i dispatcher-noden inte synkroniseras med andra arbetsnoder. Om redundans inträffar från dispatcher-noden till arbetsnoden och autentiseringsuppgifterna bara finns i den tidigare dispatcher-noden, misslyckas aktiviteten när du försöker komma åt autentiseringsuppgifterna och föregående fel visas.
Lösning
Det enda sättet att undvika det här problemet är att se till att de två noderna är i synkroniseringsläge för autentiseringsuppgifter. Om de inte är synkroniserade måste du ange autentiseringsuppgifterna för den nya dispatchern igen.
Det går inte att välja certifikat eftersom den privata nyckeln saknas
Symtom
Du importerar en PFX-fil till certifikatarkivet.
När du väljer certifikatet via IR Configuration Manager-gränssnittet visas följande felmeddelande:
”Det gick inte att ändra krypteringsläge för intranätskommunikation. Det är troligt att certifikatets "<certifikatnamn>" kanske inte har en privat nyckel som kan utbyta nycklar eller att processen kanske inte har åtkomsträttigheter för den privata nyckeln. Mer information finns i det inre undantaget."
Orsak
- Användarkontot har för låg behörighet och kan inte komma åt den privata nyckeln.
- Certifikatet genererades som en signatur, men inte som ett nyckelutbyte.
Lösning
Om du vill använda gränssnittet ska du använda ett konto med tillräcklig behörighet för att komma åt den privata nyckeln.
Kör följande kommando för att importera certifikatet:
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
Problem med lokalt installerade IR-noder som inte synkroniseras
Symtom
Lokalt installerade IR-noder försöker synkronisera autentiseringsuppgifterna mellan noder men fastnar i processen, och efter ett tag visas felmeddelandet nedan:
”IR-noden (lokalt installerad) försöker synkronisera autentiseringsuppgifter mellan noder. Det här kan ta några minuter.”
Kommentar
Om det här felet visas i över 10 minuter kontrollerar du anslutningen till avsändarnoden.
Orsak
Orsaken är att arbetsnoderna inte har åtkomst till de privata nycklarna. Du kan bekräfta det här i IR-loggarna nedan:
[14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.Du har inte problem med synkroniseringsprocessen när du använder autentisering med tjänstens huvudnamn i den länkade tjänsten. Men när du byter autentiseringstyp till kontonyckel börjar synkroniseringsproblemet. Det här beror på att den lokala Integration Runtime-tjänsten körs under ett tjänstkonto (NT SERVICE\DIAHostService) som måste få behörighet till den privata nyckeln.
Lösning
För att lösa det här problemet måste du ge det lokala IR-tjänstkontot (NT SERVICE\DIAHostService) behörighet till den privata nyckeln. Så här kan du göra:
Öppna Microsoft Management Console (MMC) Kör kommando.
Använd följande steg i MMC-fönstret:
- Välj Fil.
- Välj Lägg till/ta bort snapin-modul i listrutan.
- Välj Certifikat i fönstret ”Tillgängliga snapin-moduler”.
- Markera Lägga till.
- I popup-fönstret ”Snapin-modul för certifikat” väljer du Datorkonto.
- Välj Nästa.
- I fönstret ”Välj dator” väljer du Lokal dator: datorn som den här konsolen körs i.
- Välj Slutför.
- Välj OK i fönstret ”Lägg till eller ta bort snapin-moduler”.
I fönstret i MMC går du vidare med följande steg:
- I den vänstra mapplistan väljer du Konsolrot –> Certifikat (lokal dator) –> Personlig –> Certifikat.
- Högerklicka på Microsoft Intune Beta MDM.
- Välj Alla uppgifter i listrutan.
- Välj Hantera privata nycklar.
- Välj Lägg till under ”Grupp- eller användarnamn”.
- Välj NT SERVICE\DIAHostService för att ge fullständig åtkomst till det här certifikatet, tillämpa och spara.
- Välj Kontrollera namn och sedan OK.
- I fönstret ”Behörigheter” väljer du Tillämpa och sedan OK.
Felmeddelandet UserErrorJreNotFound visas när du kör en kopieringsaktivitet till Azure
Symtom
När du försöker kopiera innehåll till Microsoft Azure med hjälp av ett Java-baserat verktyg eller program (till exempel kopiera av ORC- eller Parquet-formatfiler) får du ett felmeddelande som liknar följande:
ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. (Java Runtime Environment hittades inte). Gå till
http://go.microsoft.com/fwlink/?LinkId=808605för att ladda ned och installera på din Integration Runtime-noddator (lokal installation). Observera att 64-bitars Integration Runtime kräver 64-bitars JRE och 32-bitars Integration Runtime kräver 32-bitars JRE.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': The specified module could not be found. (Det gick inte att läsa in DLL "jvm.dll": Den angivna modulen hittades inte.) (Undantag från HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridgeOrsak
Det här problemet kan ske av någon av följande orsaker:
Java Runtime Environment (JRE) är inte korrekt installerat på din Integration Runtime-server.
Din Integration Runtime-server saknar det beroende som krävs för JRE.
Som standard matchar Integration Runtime JRE-sökvägen med hjälp av registerposter. Dessa poster bör anges automatiskt under JRE-installationen.
Lösning
Följ stegen i det här avsnittet noggrant. Det kan uppstå allvarliga problem om du gör felaktiga ändringar i registret. Innan du ändrar det bör du först säkerhetskopiera registret för att kunna återställa det om problem skulle uppstå.
Åtgärda det här problemet genom att följa dessa steg för att kontrollera JR-installationens status:
Kontrollera att Integration Runtime (Diahost.exe) och JRE är installerade på samma plattform. Kontrollera följande villkor:
64-bitars JRE för 64-bitars ADF Integration Runtime bör installeras i mappen:
C:\Program Files\Java\Kommentar
Mappen är inte
C:\Program Files (x86)\Java\Java Runtime (JRE) är version 11 eller senare, från en JRE-provider som Microsoft OpenJDK 11 eller Eclipse Temurin 11. Kontrollera att JAVA_HOME-systemmiljövariabeln är inställd på JDK-mappen (inte bara JRE-mappen) du kan också behöva lägga till mappen bin i systemets PATH-miljövariabel.
Kontrollera lämpliga inställningar i registret. För att göra detta följer du stegen nedan:
I menyn Kör skriver du Regedit och trycker sedan på Retur.
Leta upp följande undernyckel i navigeringsfönstret:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.I fönstret Details (Information) bör det finnas en post för Current Version (Aktuell version) som visar JRE-versionen (till exempel 1.8).
I navigeringsfönstret letar du upp en undernyckel som är en exakt matchning för versionen (till exempel 1.8) under JRE-mappen. I informationsfönstret bör det finnas en JavaHome-post. Värdet för den här posten är JRE-installationssökvägen.
Leta upp mappen bin\server på följande sökväg:
C:\Program Files\Java\jre1.8.0_74
Kontrollera om den här mappen innehåller en jvm.dll-fil. Om den inte gör det söker du efter filen i
bin\clientmappen.
Kommentar
- Om någon av dessa konfigurationer inte är såsom det beskrivs i de här stegen kan du använda Windows-installationsprogrammet för JRE till att åtgärda problemen.
- Om alla konfigurationer i de här stegen är korrekta enligt beskrivningen kan det finnas ett VC++-körningsbibliotek som saknas i systemet. Du kan åtgärda det här problemet genom att installera VC++ 2010 Redistributable Package.
Installation av lokalt installerad IR
Registreringsfel för integrationskörning
Symtom
Ibland kanske du vill köra en lokalt installerad IR på ett annat konto av någon av följande orsaker:
- Företagspolicyn tillåter inte tjänstkontot.
- Viss autentisering krävs.
När du har ändrat tjänstkontot i tjänstfönstret kan det hända att integreringskörningen slutar fungera och du får följande felmeddelande:
"Noden Integration Runtime (lokal installation) har påträffat ett fel under registreringen. Det går inte att ansluta till värdtjänsten för Integration Runtime (lokal installation).”
Orsak
Många resurser beviljas endast till tjänstkontot. När du ändrar tjänstkontot till ett annat konto förblir behörigheterna för alla beroende resurser oförändrade.
Lösning
Gå till händelseloggen för integreringskörning för att kontrollera felet.
Om felet i händelseloggen är ”UnauthorizedAccessException” gör du följande:
Kontrollera DIAHostService-inloggningstjänstkontot i Windows-tjänstpanelen.
Kontrollera om inloggningstjänstkontot har läs-/skrivbehörighet för mappen %programdata%\Microsoft\DataTransfer\DataManagementGateway .
Om tjänstinloggningskontot inte har ändrats bör det ha läs-/skrivbehörighet som standard.
Om du har ändrat tjänstkontot för inloggning kan du åtgärda problemet genom att göra följande:
a. Utför en ren avinstallation av den nuvarande lokalt installerade integreringskörningen.
b. Installera bitar för lokalt installerad IR.
c. Ändra tjänstkontot genom att göra följande:i. Gå till installationsmappen för lokalt installerad IR och växla sedan till mappen Microsoft Integration Runtime\4.0\Shared.
ii. Öppna ett kommandotolkfönster med utökade privilegier. Ersätt <användare> och <lösenord> med ditt eget användarnamn och lösenord och kör sedan följande kommando:
dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
iii. Om du vill ändra till LocalSystem-kontot måste du använda rätt format för det här kontot:dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
Använd inte det här formatet:dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
iv. Du kan också ändra det direkt i "Tjänster" eftersom det lokala systemet har högre behörighet än administratör.
v. Du kan använda en lokal användare/domänanvändare för IR-tjänstinloggningskontot.d. Registrera integreringskörningen.
Om felet är "Tjänsten "Integration Runtime Service" (DIAHostService) kunde inte starta. Kontrollera att du har tillräcklig behörighet för att starta systemtjänster", gör följande:
Kontrollera DIAHostService-inloggningstjänstkontot i Windows-tjänstpanelen.
Kontrollera om inloggningstjänstkontot har logga in som en tjänstbehörighet för att starta Windows-tjänsten:
Mer information
Om inget av de föregående två matchningsmönstren gäller i ditt fall kan du försöka samla in följande Windows-händelseloggar:
- Integreringskörning för program- och tjänstloggar >
- Windows-loggprogram >
Det går inte att hitta knappen Registrera för att registrera en lokalt installerad IR
Symtom
När du registrerar en lokalt installerad IR visas inte knappen Registrera i fönstret Configuration Manager.
Orsak
Efter lanseringen av Integration Runtime 3.0 har knappen Registrera på befintliga noder för integreringskörningar tagits bort för att miljön ska bli renare och säkrare. Om en nod har registrerats på en integreringskörning, oavsett om den är online eller inte, omregistrerar du den till en annan integreringskörning genom att avinstallera den tidigare noden och sedan installera och registrera noden.
Lösning
I Kontrollpanelen avinstallerar du den befintliga integrationskörningen.
Viktigt!
I följande process väljer du Ja. Behåll inte data under avinstallationsprocessen.
Om du inte har installationsprogrammets MSI-fil för integreringskörningen går du till Download Center och laddar ned den senaste integreringskörningen.
Installera MSI-filen och registrera integreringskörningen.
Det går inte att registrera lokalt installerad IR på grund av localhost
Symtom
Du kan inte registrera den lokalt installerade IR:n på en ny dator när du använder get_LoopbackIpOrName.
Felsökning: Ett körningsfel har inträffat. Typinitieraren för Microsoft.DataTransfer.DIAgentHost.DataSourceCache utlöste ett undantag. Ett oåterkalleligt fel inträffade under en databassökning.
Undantagsinformation: System.TypeInitializationException: Typinitieraren för "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" utlöste ett undantag. >--- System.Net.Sockets.SocketException: Ett fel som inte kan återställas inträffade under en databassökning på System.Net.Dns.GetAddrInfo(Strängnamn).
Orsak
Problemet uppstår vanligtvis när localhost löses.
Lösning
Använd localhost IP-adress 127.0.0.1 som värd för filen och lös problemet.
Det gick inte att installera lokalt
Symtom
Du kan inte avinstallera en befintlig IR, installera en ny IR eller uppgradera en befintlig IR till en ny IR.
Orsak
Installationen av integrationskörningen beror på Windows Installer-tjänsten. Du kan uppleva installationsproblem av följande skäl:
- Otillräckligt diskutrymme.
- Brist på behörigheter.
- Windows NT-tjänsten är låst.
- Processoranvändningen är för hög.
- MSI-filen finns på en långsam nätverksplats.
- Vissa systemfiler eller register berördes oavsiktligt.
IR-tjänstkontot kunde inte hämta certifikatåtkomst
Symtom
När du installerar en lokalt installerad IR via Microsoft Integration Runtime Configuration Manager genereras ett certifikat med en betrodd certifikatutfärdare (CA). Det gick inte att använda certifikatet för att kryptera kommunikationen mellan två noder och följande felmeddelande visas:
"Det gick inte att ändra krypteringsläget för intranätskommunikation: Det gick inte att bevilja Integration Runtime-tjänstkontot åtkomst till certifikatets< certifikatnamn>. Felkod 103"
Orsak
Certifikatet använder nyckellagringsproviderlagring (KSP), som ännu inte stöds. Hittills har lokalt installerad IR endast stöd för csp-lagring (cryptographic service provider).
Lösning
Vi rekommenderar att du använder CSP-certifikat i det här fallet.
Lösning 1
Kör följande kommando för att importera certifikatet:
Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx
Lösning 2
Om du vill konvertera certifikatet kör du följande kommandon:
openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword>openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfxFöre och efter konvertering:
Lokalt installerad integrationskörning version 5.x
För uppgraderingen till version 5.x av den lokalt installerade integrationskörningen behöver vi .NET Framework Runtime 4.7.2 eller senare. På nedladdningssidan hittar du nedladdningslänkar för den senaste 4.x-versionen och de senaste två 5.x-versionerna.
För Azure Data Factory v2- och Azure Synapse-kunder:
- Om automatisk uppdatering är på och du redan har uppgraderat .NET Framework Runtime till 4.7.2 eller senare uppgraderas den lokalt installerade integrationskörningen automatiskt till den senaste 5.x-versionen.
- Om automatisk uppdatering är på och du inte har uppgraderat .NET Framework Runtime till 4.7.2 eller senare uppgraderas inte den lokalt installerade integrationskörningen automatiskt till den senaste 5.x-versionen. Den lokalt installerade integrationskörningen finns kvar i den aktuella 4.x-versionen. Du kan se en varning för en .NET Framework Runtime-uppgradering i portalen och den lokalt installerade integrationskörningsklienten.
- Om den automatiska uppdateringen är avstängd och du redan har uppgraderat .NET Framework Runtime till 4.7.2 eller senare kan du manuellt ladda ned den senaste 5.x och installera den på datorn.
- Om den automatiska uppdateringen är avstängd och du inte har uppgraderat .NET Framework Runtime till 4.7.2 eller senare. När du försöker installera integrationskörningen 5.x manuellt och registrera nyckeln måste du uppgradera .NET Framework Runtime-versionen först.
Problem med lokalt installerad IR-anslutning
Lokalt installerad integreringskörning kan inte ansluta till molntjänsten
Symtom
När du försöker registrera den lokalt installerade integreringskörningen visas följande felmeddelande i Konfigurationshanteraren:
”Noden för Integration Runtime (lokal installation) påträffade ett fel under registreringen.”
Orsak
Den lokalt installerade IR:en kan inte ansluta till tjänstens serverdel. Det här problemet orsakas vanligtvis av nätverksinställningar i brandväggen.
Lösning
Kontrollera om integreringskörningstjänsten körs. I så fall går du till steg 2.
Om ingen proxy har konfigurerats för den lokalt installerade integreringskörningen, vilket är standardinställningen, kör du följande PowerShell-kommando på den dator där den lokalt installerade integreringskörningen är installerad:
(New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")Kommentar
Tjänst-URL:en kan variera beroende på platsen för din datafabrik eller Synapse-arbetsyteinstans. Om du vill hitta tjänst-URL:en använder du sidan Hantera i användargränssnittet i din datafabrik eller Azure Synapse-instans för att hitta integrationskörningar och klicka på din lokala IR för att redigera den. Där väljer du fliken Noder och klickar på Visa tjänst-URL:er.
Följande är det förväntade svaret:
Om du inte får det svar som du hade förväntat dig använder du någon av följande metoder efter behov:
- Om du får ett meddelande om att det inte gick att matcha fjärrnamnet finns det ett problem med Domain Name System (DNS). Kontakta nätverksteamet för att åtgärda problemet.
- Om du får meddelandet "ssl/tls cert is not trusted" kontrollerar du certifikatet (
https://wu2.frontend.clouddatahub.net/) för att se om det är betrott på datorn och installerar sedan det offentliga certifikatet med hjälp av Certifikathanteraren. Den här åtgärden bör åtgärda problemet. - Gå till Fönster>Loggboken (loggar)>Program- och tjänstloggar>Integration Runtime och söker efter fel förorsakade av DNS, en brandväggsregel eller företagets nätverksinställningar. Om du upptäcker ett sådant fel tvingar du anslutningen att stänga. Eftersom varje företag har sina egna anpassade nätverksinställningar kontaktar du nätverksteamet för att felsöka dessa problem.
Om ”proxy” har konfigurerats på den lokalt installerade integreringskörningen kontrollerar du att proxyservern kan komma åt tjänstslutpunkten. Ett exempelkommando finns i PowerShell, webbegäranden och proxyn.
$user = $env:username $webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings').ProxyServer $pwd = Read-Host "Password?" -assecurestring $proxy = new-object System.Net.WebProxy $proxy.Address = $webproxy $account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "") $proxy.credentials = $account $url = "https://wu2.frontend.clouddatahub.net/" $wc = new-object system.net.WebClient $wc.proxy = $proxy $webpage = $wc.DownloadData($url) $string = [System.Text.Encoding]::ASCII.GetString($webpage) $string
Följande är det förväntade svaret:
Kommentar
Proxyöverväganden:
- Kontrollera om proxyservern behöver placeras i listan Säkra mottagare. I så fall kontrollerar du att dessa domäner finns på listan Betrodda mottagare.
- Kontrollera om SSL/TLS-certifikatet
wu2.frontend.clouddatahub.net/är betrott på proxyservern. - Om du använder Active Directory-autentisering på proxyn ändrar du tjänstkontot till det användarkonto som har åtkomst till proxyn som ”Integration Runtime Service” (Integration Runtime-tjänst).
Felmeddelande: Lokalt installerad integrationskörningsnod/logisk lokalt installerad IR är i inaktivt tillstånd/ "Körs (begränsad)"
Orsak
Den lokalt installerade integrerade runtime-noden kan ha statusen Inaktiv, vilket visas i följande skärmbild:
Det här beteendet inträffar när noder inte kan kommunicera med varandra.
Lösning
Logga in på den nodvärdbaserade virtuella datorn (VM). Under Program- och tjänstkoggar>Integrationskörning öppnar du Loggboken och filtrerar felloggarna.
Kontrollera om en fellogg innehåller följande fel:
System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 10.2.4.10:8060 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Connect(EndPoint remoteEP) at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)Om du ser det här felet kör du följande kommando i kommandotolken:
telnet 10.2.4.10 8060Om du får kommandoradsfelet "Det gick inte att öppna anslutningen till värden" som visas på följande skärmbild kontaktar du IT-avdelningen för att få hjälp med att åtgärda problemet. När du har lyckats med telnet kontaktar du Microsoft Support om du fortfarande har problem med nodstatusen för integreringskörning.
Kontrollera om felloggen innehåller följande post:
Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)Försök att lösa problemet på något av eller båda följande sätt:
- Placera alla noder i samma domän.
- Lägg till IP-adressen till värdmappningen i alla värdfiler för den värdbaserade virtuella datorn.
Anslutningsproblem mellan lokalt installerad IR och din datafabrik eller Azure Synapse-instans eller den lokalt installerade IR:en och datakällan eller mottagaren
Om du vill felsöka problemet med nätverksanslutningen bör du veta hur du samlar in nätverksspårningen, förstår hur du använder den och analyserar Spårningen av Microsoft Network Monitor (Netmon) innan du tillämpar Netmon Tools i verkliga fall från den lokalt installerade IR:n.
Symtom
Ibland kan du behöva felsöka vissa anslutningsproblem mellan den lokalt installerade IR:en och din datafabrik eller Azure Synapse-instans, som du ser i följande skärmbild, eller mellan den lokalt installerade IR:en och datakällan eller mottagaren.
I båda fallen kan du stöta på följande fel:
"Kopieringen misslyckades med felet:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Det går inte att ansluta till SQL Server: 'IP-adress'"
"Ett eller fler fel uppstod. Ett fel inträffade när begäran skickades. Den underliggande anslutningen stängdes: Ett oväntat fel inträffade vid en mottagning. Det går inte att läsa data från transportanslutningen: En befintlig anslutning stängdes med tvång av fjärrvärden. En befintlig anslutning stängdes av med tvång av fjärrvärdens Aktivitets-ID."
Lösning
När du stöter på föregående fel kan du felsöka dem genom att följa anvisningarna i det här avsnittet.
Samla in en Netmon-spårning för analys:
Du kan ange att filtret ska se en återställning från servern till klientsidan. I följande skärmbild av exemplet kan du se att serversidan är Data Factory-servern.
När du får återställningspaketet kan du hitta konversationen genom att följa Transmission Control Protocol (TCP).
Hämta konversationen mellan klienten och Data Factory-servern genom att ta bort filtret.
En analys av Netmon-spårningen som du har samlat in visar att TTL-summan (Time to Live) är 64. Enligt de värden som anges i artikeln IP Time to Live (TTL) och Hop Limit Basics som extraheras i följande lista kan du se att det är Linux-systemet som återställer paketet och orsakar frånkopplingen.
Standardvärdena för TTL och Hoppgräns varierar mellan olika operativsystem, enligt listan här:
- Linux kernel 2.4 (cirka 2001): 255 för TCP, User Datagram Protocol (UDP) och Internet Control Message Protocol (ICMP)
- Linux kernel 4.10 (2015): 64 för TCP, UDP och ICMP
- Windows XP (2001): 128 för TCP, UDP och ICMP
- Windows 10 (2015): 128 för TCP, UDP och ICMP
- Windows Server 2008: 128 för TCP, UDP och ICMP
- Windows Server 2019 (2018): 128 för TCP, UDP och ICMP
- macOS (2001): 64 för TCP, UDP och ICMP
I föregående exempel visas TTL som 61 i stället för 64, för när nätverkspaketet når målet måste det gå igenom olika hopp, till exempel routrar eller nätverksenheter. Antalet routrar eller nätverksenheter dras av för att producera den slutliga TTL:n.
I det här fallet kan du se att en återställning kan skickas från Linux-systemet med TTL 64.
Kontrollera var återställningsenheten kommer ifrån genom att kontrollera det fjärde hoppet från lokalt installerad IR.
Nätverkspaket från Linux System A med TTL 64 –> B TTL 64 minus 1 = 63 –> C TTL 63 minus 1 = 62 –> TTL 62 minus 1 = 61 lokalt installerad IR
I en idealisk situation skulle TTL-hoppnumret vara 128, vilket innebär att Windows-operativsystemet kör din datafabriksinstans. Som du ser i följande exempel skickades 128 minus 107 = 21 hopp, vilket innebär att 21 hopp för paketet skickades från datafabriksinstansen till den lokalt installerade IR:n under handskakningen TCP 3.
Därför måste du kontakta nätverksteamet för att kontrollera vad det fjärde hoppet är från den lokalt installerade IR:n. Om det är brandväggen, precis som med Linux-systemet, kontrollerar du alla loggar för att se varför enheten återställer paketet efter handskakningen för TCP 3.
Om du är osäker på var du ska undersöka kan du försöka hämta Netmon-spårningen från både den lokalt installerade IR:en och brandväggen under den problematiska tiden. Den här metoden hjälper dig att ta reda på vilken enhet som kan ha återställt paketet och orsakat frånkopplingen. I det här fallet måste du också engagera ditt nätverksteam för att gå vidare.
Analysera Netmon-spårningen
Kommentar
Följande instruktioner gäller för Netmon-spårningen. Eftersom Netmon-spårning för närvarande inte stöds kan du använda Wireshark för det här ändamålet.
När du försöker telnet 8.8.8.8 888 med den insamlade Netmon-spårningen bör du se spårningen i följande skärmbilder:
Föregående bilder visar att du inte kunde upprätta en TCP-anslutning till 8.8.8.8.8-serversidan på port 888, så du ser ytterligare två SynReTransmit-paket där. Eftersom källan SELF-HOST2 inte kunde ansluta till 8.8.8.8 med det första paketet fortsätter den att försöka upprätta anslutningen.
Dricks
Prova följande lösning för att upprätta den här anslutningen:
- Välj Läs in filterstandardfilteradresser>>>IPv4-adresser.
- Om du vill använda filtret anger du IPv4.Address == 8.8.8.8 och väljer sedan Använd. Du bör sedan se kommunikationen från den lokala datorn till mål 8.8.8.8.
Lyckade scenarier visas i följande exempel:
Om du kan telnet 8.8.8.8 53 utan problem, finns det ett lyckat TCP 3-handskakning och sessionen avslutas med ett TCP 4-handskakning.
Föregående TCP 3-handskakning skapar följande arbetsflöde:
Handskakningen TCP 4 för att slutföra sessionen illustreras av följande arbetsflöden:
Ta reda på om det här meddelandet påverkar dig
Det här meddelandet gäller för följande scenarier:
Scenario 1: Utgående kommunikation från en lokalt installerad integrationskörning som körs lokalt bakom en företagsbrandvägg
Så här avgör du om du påverkas:
Du påverkas inte om du definierar brandväggsregler baserat på fullständigt kvalificerade domännamn (FQDN) som använder metoden som beskrivs i Konfigurera en brandväggskonfiguration och tillåtlista för IP-adresser.
Du påverkas om du uttryckligen aktiverar listan över tillåtna för utgående IP-adresser i företagets brandvägg.
Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera nätverkskonfigurationen för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.
Scenario 2: Utgående kommunikation från en lokalt installerad integrationskörning som körs på en virtuell Azure-dator i ett kundhanterat virtuellt Azure-nätverk
Så här avgör du om du påverkas:
Kontrollera om du har några regler för utgående nätverkssäkerhetsgrupp (NSG) i ett privat nätverk som innehåller lokalt installerad integrationskörning. Om det inte finns några utgående begränsningar påverkas du inte.
Om du har begränsningar för utgående regler kontrollerar du om du använder tjänsttaggar. Om du använder tjänsttaggar påverkas du inte. Du behöver inte ändra eller lägga till något eftersom det nya IP-intervallet finns under dina befintliga tjänsttaggar.
Du påverkas om du uttryckligen aktiverar listan över tillåtna utgående IP-adresser i NSG-regelinställningen i det virtuella Azure-nätverket.
Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera NSG-reglerna för din konfiguration av virtuella Azure-nätverk för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.
Scenario 3: Utgående kommunikation från SSIS Integration Runtime i ett kundhanterat virtuellt Azure-nätverk
Så här avgör du om du påverkas:
Kontrollera om du har några utgående NSG-regler i ett privat nätverk som innehåller SQL Server Integration Services (SSIS) Integration Runtime. Om det inte finns några utgående begränsningar påverkas du inte.
Om du har begränsningar för utgående regler kontrollerar du om du använder tjänsttaggar. Om du använder tjänsttaggar påverkas du inte. Du behöver inte ändra eller lägga till något eftersom det nya IP-intervallet finns under dina befintliga tjänsttaggar.
Du påverkas om du uttryckligen aktiverar listan över tillåtna utgående IP-adresser i NSG-regelinställningen i det virtuella Azure-nätverket.
Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera NSG-reglerna för din konfiguration av virtuella Azure-nätverk för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.
Det går inte att upprätta en förtroenderelation för den säkra SSL/TLS-kanalen
Symtom
Det gick inte att ansluta den lokalt installerade IR:t till Azure Data Factory eller Azure Synapse-tjänsten.
När du kontrollerar den lokalt installerade IR-händelseloggen när du har gått till Windows>Loggboken (loggar)>Program- och tjänstloggar>Integration Runtime hittar du följande felmeddelande.
"Den underliggande anslutningen stängdes: Det gick inte att upprätta en förtroenderelation för den säkra SSL/TLS-kanalen. Fjärrcertifikatet är ogiltigt enligt valideringsproceduren."
Det enklaste sättet att kontrollera tjänstens servercertifikat är att öppna tjänstens URL i webbläsaren. Öppna till exempel länken kontrollera servercertifikat (
https://eu.frontend.clouddatahub.net/) på den dator där den lokalt installerade IR:en är installerad och visa sedan servercertifikatinformationen.
Orsak
Det finns två möjliga orsaker till det här problemet:
- Orsak 1: Rotcertifikatutfärdaren för tjänstens servercertifikat är inte betrodd på den dator där lokalt installerad IR är installerad.
- Orsak 2: Du använder en proxy i din miljö ersätts tjänstens servercertifikat av proxyn. Det ersatta servercertifikatet är inte betrott av den dator där lokalt installerad IR är installerad.
Lösning
- För orsak 1: Se till att tjänstens servercertifikat och dess certifikatkedja är betrodda på den dator där lokalt installerad IR är installerad.
- För orsak 2: Lita antingen på den ersatta rotcertifikatutfärdaren på datorn med lokalt installerad IR eller konfigurera proxyn så att den inte ersätter tjänstens servercertifikat.
Mer information om hur du litar på certifikat i Windows finns i Installera det betrodda rotcertifikatet.
Ytterligare information
Vi har distribuerat ett nytt SSL-certifikat som är signerat från DigiCert. Kontrollera om DigiCert Global Root G2 finns i den betrodda rotcertifikatutfärdaren.
Om den inte finns i den betrodda rotcertifikatutfärdarcertifikatutfärdarna laddar du ned den här.
Relaterat innehåll
Om du vill ha mer hjälp med felsökning kan du prova följande resurser: