Detta fel är typiskt för . Felet "Konfigurationen av den distribuerade informationssäkerhetsnoden matchar inte den förväntade" är ett system. Uppstår främst på grund av en onormal avstängning under utbyte av data via URIB.

Detta kan lösas på ett ganska enkelt sätt. Låt oss överväga det.

Instruktioner

1. Gör kopior av databaserna som arbetet kommer att utföras på (I konfiguratorn "Administration - Ladda upp infobas").

2. Starta konfiguratorn för RIB-nodens huvuddatabas.

3. Spara den centrala nodkonfigurationen i en databasfil ("Konfiguration - Spara konfiguration till fil...")

4. Öppna slavnoddatabaskonfiguratorn.

Få 267 videolektioner på 1C gratis:

5. Ta bort konfigurationen av slavnoden från supporten (Konfiguration - Support - Supportinställningar - Ta bort från support):

6. Ladda databaskonfigurationen ("Konfiguration – Ladda konfiguration från fil...").

8. Efter omstruktureringen måste du gå in i företagsläge och installera huvudkonfigurationsnoden. Detta kan göras med hjälp av speciell bearbetning - . Bearbetning fungerar i både hanterat applikationsläge och vanligt applikationsläge.

9. Under bearbetningen måste du välja huvudnoden och klicka på "Kör":

10. Klart! Försök att starta utbytet, systemet bör slutföra utbytet korrekt.

Dynamiska uppdateringsfel (eller andra plattformsfel) kan vara orsaken till distribuerade informationsbasutbytesfel:

• "Data tas emot från den nod för vilken konfigurationsändringar har registrerats"
  

• "Konfigurationen av den distribuerade informationssäkerhetsnoden motsvarar inte den förväntade"
  

Hur återställer man utbytet?

Men låt oss börja inte med restaurering, utan med möjligheten att genomförabyta "manuellt", vilket är viktigt under dagen, för som alltid ska allt fungera "igår" :) Detta kan göras med hjälp av underbara behandlingar som jag inte kom ihågnaken där jag laddade ner den (författare, vänligen svara - jag lämnar länkar till din resurs och vid behov tar jag bort den från min). Bearbetning gör det möjligt att ladda ner endast registrerade dataändringar i databasen (enligt den specificerade utbytesplanen för en specifik nod!) i XML utan att ladda ner konfigurationsändringar och, om konfigurationsobjekten inte har förändrats mycket, då är det en mycket stor chans att ladda denna data. Dessa kan laddas ner från länken i slutet av artikeln.

När det gäller återhämtning. Det finns enklare metoder som inte inkluderar alla objekt i listan nedan, men de hjälper inte alltid, vilket var fallet i ett av mina fall. Därför presenterar jag metoden som hjälpte mig att kringgå möjliga problem på ett mer omfattande sätt. Nästa steg för steg.

Det är lämpligt att vidta dessa steg när det inte finns några fungerande användare i databasen. Om detta inte är möjligt måste du "avsluta" metoden själv, och därför måste du först förstå dess logik.

1. Gör säkerhetskopior överallt.

2. För klientservrar: inaktivera databaserna via "serveradministration" och anslut dem omedelbart med blockering av schemalagda uppgifter (detta återställer serverns cache). Efter detta, glöm inte att överföra registreringsloggen till den nya katalogen.

3. På alla datorer som används för återställning, ta bort databasen i listan över 1C startdatabaser och skapa en ny (användarcachen kommer att rensas)

4. I konfiguratorn (i den centrala databasen), lägg till en ny konstant och spara konf.ändringarna.

5. Rensa alla börskataloger.

6. Gör lossningar till alla grenar (endast lossningar för närvarande).

7. Försök att ladda ner (endast ladda ner) mottagna data till alla filialer. Det är naturligt att acceptera konf-ändringarna.

Om allt är bra överallt går vi vidare om allt är dåligt, vi tror att det kan hjälpa att ladda .cf från den centrala databasen och LADDA den till grenen. I slavnoden bör du koppla bort databasen från RIB (bearbetning hjälper till med detta - ladda ner från länken nedan). Det finns en artikel om detta ämne på infostart.ru.

8. Vi avbryter registreringen av ändringar för filialer i centralbanken (vi har trots allt redan fått alla ändringar överallt). Det är viktigt att göra i detta skede så att de ackumulerade förändringarna från olika grenar kommer till andra grenar. (ladda ned bearbetning för obindande bindning från länken nedan).

9. Vi laddar in i centralbanken och om allt är bra, så laddar och lossar vi med varje filial flera gånger för att konsolidera resultatet.

10. Det är allt.

Du kan aktivera exekvering av rutinuppgifter för klient-serverdatabaser.

För att förhindra problem som orsakar detta fel, rekommenderas det att inte göra dynamiska uppdateringar (åtminstone flera gånger i rad - tills ändringar har laddats upp till filialer), och det är också lämpligt att markera rutan "ladda upp data endast vid framgångsrik uppladdning" i utbytesinställningarna.

Hej kära läsare av vår blogg! Idag ska vi prata om
åtgärda två fel som kan uppstå vid utbyte i en distribuerad informationsbas (RIB). Sådana fel kan uppstå om du har ändrat konfigurationen av din databas och försöker överföra dessa ändringar från den centrala databasen till den perifera. Till exempel på det sätt som beskrevs. Låt oss börja!

Det här är meddelandena som kan visas när du försöker göra ett utbyte med RIB:

"Data tas emot från noden för vilken
konfigurationsändringar har loggats.
Ändringar måste överföras
konfigurationer till noden."


"Distribuerad nodkonfiguration för informationssäkerhet
inte som förväntat!"

Låt oss titta på stegen för att korrigera situationen. Innan vi börjar, låt oss skapa vår informationsdatabas!!!

1. Låt oss ta konfigurationsfilen med uppdateringen, öppna den centrala databasen i konfiguratorn och ladda den (Configuration-Load configuration from file...). Låt oss spara informationssäkerheten (F7).
2. Låt oss gå till och ladda upp till en fil för den perifera databasen:
   
   
   • Välj utbytesplanen i listan, högerklicka sedan för att öppna snabbmenyn och välj "Spara ändringar...".
3. Låt oss nu ta itu med perifer informationssäkerhet. Låt oss öppna det i exklusivt läge så att det inte finns några användare, och även stänga konfiguratorn. Nu måste du komma ihåg noden som är den huvudsakliga för den aktuella databasen. Öppna operationer-Utbytesplaner-Välj din utbytesplan (till exempel "Efter lager"). I listan över utbytesplaner är huvudnoden objektet med den gula ikonen. Denna information kommer att vara användbar för oss i den sjunde punkten. Låt oss öppna bearbetningen och klicka på knappen "Avbryt tilldelning av huvudnod".
4. Låt oss nu öppna den perifera informationssäkerheten i konfiguratorn och ladda samma konfigurationsfil som vi laddade i det första steget i den centrala databasen (Configuration-Load configuration from file...). Låt oss spara informationssäkerheten (F7).
5. Låt oss ändra supportinställningarna (Configuration-Support-Support Settings...). I dialogrutan väljer du cellen i tabellen i skärningspunkten mellan den första raden och den andra kolumnen. Dubbelklicka sedan för att öppna dialogrutan "Support Rules Settings". I den, kontrollera flaggan "Installera för underordnade objekt" och klicka på knappen "OK". Stäng dialogrutan för supportinställningar genom att klicka på knappen "Stäng". Spara IB (F7). Låt oss stänga konfiguratorn.
6. Låt oss nu öppna den perifera informationssäkerheten igen i 1C:Enterprise exklusivt läge så att det inte finns några användare, och även stänga konfiguratorn. Låt oss öppna bearbetningsinstallationen av MainNodeDB.epf och välj utbytesplanen som vi vill installera som huvudnod (i det fjärde stycket kom vi ihåg denna nod). Klicka sedan på knappen "Installera huvudnod". Efter detta kommer den nuvarande informationssäkerheten åter att bli perifer.
7. Nu i den aktuella informationssäkerheten (perifera) kommer vi att öppna utbytesplanerna och ladda ner filen med utbytet från den centrala databasen, som vi fick i det tredje steget:
   
   
   • Operations-Exchange Plans-Välj vår utbytesplan (till exempel "Efter lager").
8. Om allt gick bra, kommer vi att ladda upp utbytet för den centrala databasen i den aktuella informationssäkerheten (perifer):
   
   
   • Operations-Exchange Plans-Välj vår utbytesplan (till exempel "Efter lager").
   • Välj utbytesplanen i listan, högerklicka sedan för att öppna snabbmenyn och välj "Spara ändringar...".
   • Ange sökvägen och namnet på utbytesfilen i dialogrutan. Klicka på knappen "OK".
9. Låt oss nu försöka ladda den här filen i den centrala databasen och öppna den i 1C:Enterprise-läge:
   
   
   • Operations-Exchange Plans-Välj vår utbytesplan (till exempel "Efter lager").
   • Välj utbytesplanen i listan - Högerklicka för att ta fram snabbmenyn och välj "Läs ändringar..."
   • Välj utbytesfilen i dialogrutan. Klicka på knappen "OK".

För att undvika problem med arbetskopior, gör först

• Meddelandefilen har redan laddats in i den mottagande databasen. Du måste ladda ner den från källdatabasen igen.

Fel "Fel vid kopiering av en fil från en FTP-resurs... Fel vid arbete med Internet: Timeout uppnåddes"

• Det är inte möjligt att kopiera den önskade filen från den sida genom vilken utbytet sker. Detta kan bero på att ditt internet är långsamt eller problem med själva webbplatsen.
• Du måste försöka upprepa utbytet efter 15-30 minuter.

Fel: Det är förbjudet att redigera data för denna period. Ändringar kan inte registreras..."

• Den nedladdade informationen innehåller dokument från den stängda perioden.
• Det är nödvändigt att utföra utbytet under användare som har rätt att ändra dokument under denna period.

Fel: Damåste utföras. Uppdateringen kan utföras i konfiguratorläge"

Anledning: Programmerarna ändrade konfigurationen i mitten. Lösning: Uppdatera den ändrade konfigurationen i den perifera databasen. För detta:

• Gå till konfiguratorn.
• Kör menyalternativet "Konfigurator / Uppdatera databaskonfiguration".
• Om en fråga visas med endast svaren "Upprepa", "Avbryt", "Uppdatera dynamiskt", klicka på knappen "Uppdatera dynamiskt".
• Om en fråga ställs med bara "Upprepa" och "Avbryt" svar.
  • alla användare loggar ut från 1C.
  • tryck på "Repeat"-knappen.
• Svara jakande på de återstående frågorna: "Ja", "Acceptera", "OK".
• Stäng konfiguratorn.
• Upprepa laddningen från mitten.

Fel: "Konfigurationen är inte som förväntat", "Försöker acceptera ändringar från en okänd konfiguration"

• Databas fel.
• Det är nödvändigt att kontakta specialister.

Utbytet tar väldigt lång tid och fryser

Möjliga orsaker:

• Det kommer in mycket data.
  • Ta reda på av avsändaren om han utförde en gruppändring av dokument (publicering, ändring av detaljer, etc.).
  • Om så är fallet, lämna datorn med växeln över natten.
• En stor fil kan inte laddas ner från Internet.
  • Om filen är stor (80-100 MB eller mer) kanske 1C helt enkelt inte kan ladda ner den.
  • Du måste ladda ner filen och ladda upp den till 1C manuellt (eventuellt med hjälp av specialister).
    • menyalternativet "Operationer" / Utbytesplaner / Fullständig / Knapp på panelen "Läs meddelande".
• Databasen är skadad:
  • Försök
• Om dessa steg inte hjälper måste du kontakta specialister.

• Om felet inte kan åtgärdas, ring nödsupportnumret +7 (8512) 64-55-05.
• Vår specialist hjälper dig, oavsett vilken stad du befinner dig i.

Fråga: Fel vid uppdatering av RIB-noden

God eftermiddag.

Jag uppdaterade huvudnoden Rarus-Retail till 2.2.5.27, gjorde ett utbyte med ett par RIB-noder - allt är bra.

Jag startade en massiv uppdatering av de återstående noderna (liknande "toppparet" (andra RIB-butiker)) - ett fel dyker upp i klientdelen:

Distribution av rapporter Registerdata för uppdatering av listan över rutinuppgifter.
uppskjuten uppdateringshanterare
"Distribution av rapporter. Uppdatera listan över rutinuppgifter"
Ett fel har uppstått:
"(GeneralModule.GeneralPurpose.Module(3502)): Fel vid anrop av kontextmetod (Innehåller)
Returnera Metadata.InformationRegisters.Contains(MetadataObject);
Därför att:
Typ missmatch (parameternummer "1").

Har någon stött på detta? Jag har redan försökt uppdatera plattformen (till max 8.3.10 och testade den på 32-64 datorer)... det hjälpte inte. Men test 2-butikerna uppdaterades utan problem, jag kan inte förstå hur.

Svar:() Så här installerar jag huvudnoden. Jag skrev lite om något annat: efter bearbetning avbinder noden, nästa gång du startar den, börjar inte conf-uppdateringen omedelbart, utan först öppnar 1C ett fönster där den ber dig att bekräfta att noden kopplas bort. Därefter uppdateras den - efter uppdateringen finns noden inte längre i listan.
Faktum är att på 2.1 kommer jag ihåg att jag uppdaterade den med den här metoden, men på 2.2 fungerade något inte. Kanske i parken jag redan petat fel sekvens i åtgärderna)

ENLIGT ÄMNET:
Jag kom på vad jag har. Det visade sig att jag hade förbisett:
"I en av 2.2-versionerna dök rapportdistributionskatalogen upp med det fördefinierade elementet "Personliga data"" - en katalog med detta element var också tillgänglig i 2.1.

Nyansen är denna: jambs med uppdateringsnoder observeras på de databaser som skapades från den centrala exakt i release 2.1.9.18. Allt som skapades i tidigare utgåvor uppdaterades normalt. Detta förklarar förmodligen varför ett par TS-databaser också uppdaterades framgångsrikt, och sedan uppstod problem.

Jag försökte inte uppfinna något med att skapa ett nytt element i katalogen och ställa in det som fördefinierat. Jag överförde detta element från en kopia av centret till 2.1 via avlastning/laddning av XML och upprepade uppdateringen på den problematiska "basen" - allt fungerade.

() Så använd metoden om du inte har hittat svaret ännu.

Fråga: Konfigurationsuppdateringsfel

Jag uppdaterar Accounting 2.0.64.14-konfigurationen till 2.0.64.24. plattform 8.2.19
Ett fel visas omedelbart:
Fel vid åtkomst till fil... sökväg... temporär fil.tmp.
Var ska man leta?

Svar: Jag löste problemet den gången genom att vänta på en ny "stabil" release

Fråga: Fel i användarrättigheter till BSP

Hälsningar!!! Jag skriver en conf baserad på BSP 2.2, det verkar som att jag redan har erfarenhet och har studerat bryggorna långt och brett, men när jag startar informationssäkerheten för första gången visas ett felmeddelande:

(GeneralModule.UsersService.Module(345)): Auktorisering misslyckades. Systemet kommer att stängas av.
Användare: Administratören hittades inte i användarkatalogen.

Ett fel uppstod när du försökte lägga till en användare i katalogen:
"Fel vid uppdatering av infobasen.
Parametern för åtkomstbegränsning är inte ifylld:
"Möjliga rättigheter för att ställa in objekträttigheter."

För utvecklaren: stöddata kan behöva uppdateras,
som påverkar programmets funktion. För att utföra uppdateringen kan du:
- använda extern bearbetning
"Utvecklarverktyg: Uppdatera supportdata",
- eller kör programmet med kommandoradsparametern 1C:Enterprise 8
"/C LaunchInformationBaseUpdate",
- eller öka konfigurationsversionsnumret så att nästa gång du startar
Procedurerna för att uppdatera infobasdata har slutförts."

Klicka för att expandera...

Jag skulle vilja höra svaren från de "erfarna", för efterföljande aktiv dialog, kanske till och med samarbete

Svar:

Vdeg sa:

Problemet löst?

Jag har ett annat problem: jag lägger till en användare i BSP 2.2.5.29, och han har antingen fullständiga rättigheter (om jag lägger till dem manuellt) eller inga alls (han ser ett tomt gränssnitt utan en enda referensbok eller dokument). För i typiska BSP-roller finns det inga kryssrutor alls för att komma åt specifika (mina) kataloger och dokument. Hur kommer då rekordnivååtkomst för en ny användare att spåras???

Klicka för att expandera...

Hur ska BSP:n veta vilken typ av kataloger du har och hur du vill konfigurera åtkomst till dem?
Vi måste nog göra det själva

Fråga: SendingDeliverableNotified Fjärrnod misslyckades med verifiering

Fram till i fredags fungerade följande kod bra..

XdtoSubscriber = FactoryXDTO.Create(FactoryXDTO.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = FactoryXDTO.Create(FactoryXDTO.Type(";), "GCM");
New XDTO Serializer = New XDTO Serializer(XDTO Factory);
Subscriber = NewSerializerXDTO.ReadXDTO(xdtoSubscriber);
Notification=New DeliverableNotification;
Notification.Recipients.Add(Subscriber);
Notification.Text=Text;
Notification.SoundNotification=SoundNotification.Default;
Notice.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notification, DataAuz, True);

Nu felet: Fjärrnoden misslyckades med verifieringen. Bröt hela mitt huvud. Jag fångade förfrågningar från servern - den var tom, det kändes som om den inte kontaktade någonstans... Jag provade det på tre olika maskiner med olika axlar. torkade ut.. hjälp...

Svar: Upp

Svar: Så jag bestämde mig för att göra en ny bild av noden. När du startar noden står det att du måste börja med \c börja uppdatera informationsbasen
och gör om bilden.

Det visar sig att detta beror på en uppdateringskurva.

Jag försökte starta med den här nyckeln och göra ett utbyte med en befintlig nod. Inga uppdateringar startade på noden, jag bad inte om att starta om något.

Och som ett resultat accepterades meddelandet återigen inte i huvudnoden med samma fel.

Vad kan göras?
Kan jag fiktivt ändra något i huvudnoden i conf och göra ett utbyte? Eller kommer det inte att uppdatera hela konfigurationen, utan bara det jag ändrar? Jag ska försöka göra en knut nu. Men jag väntar på dina idéer

Fråga: Distribuerad databas - fel under utbyte är inte löst

Goddag allihop!

Situationen är följande.

När jag laddar ett utbyte från en perifer nod får jag meddelandet "Konfigurationen av den distribuerade informationssäkerhetsnoden matchar inte den förväntade."

Sedan följer jag instruktionerna.
Jag laddar ur konfigurationen från den centrala databasen till CF, kopplar upp den perifera databasen från den centrala noden genom bearbetning, tar bort konfigurationen i den perifera databasen från supporten, laddar konfigurationen från en fil.
Jag binder den centrala bearbetningsnoden i den perifera databasen.
Spara, ansök.

Jag laddar ner utbytet från den centrala databasen igen.
Jag laddar in den i kringutrustningen. Jag laddar ur utbytet från den perifera databasen.
Jag laddar den i den centrala. Återigen får jag meddelandet "Konfigurationen av den distribuerade informationssäkerhetsnoden matchar inte den förväntade."
Men det här är något riktigt nonsens - jag laddar in konfigurationen i den centrala databasen och ingen har ändrat konfigurationen i den perifera databasen.

Hur kan man övervinna ett sådant fel?

Svar: Det har aldrig fallit någon in att råda så självklara saker efter många års missbruk om den demoniska uppdateringen :)

Fråga: RIB och uppdateringar

Hej alla. Man planerar att använda distribuerad informationssäkerhet.

konfigurationen ändrad. Den centrala databaskonfigurationen uppdateras av programmeraren. Dessa ändringar kommer sedan att överföras till perifera databaser med hjälp av utbytesfiler.

Frågan är: hur är det med att starta hanterare efter att ha uppdaterat databaskonfigurationen och loggat in för första gången i användarläge?

uppdatering av huvudkonfigurationen - uppdatering av databaskonfigurationen - exekvera uppdateringshanterare i användarläge

Till exempel missades många utgåvor, det är nödvändigt att sekventiellt uppdatera till 3 utgåvor. Det är inga problem med att uppdatera den centrala databasen, men hur är det med de perifera? Det är också nödvändigt att uppdatera dem i 3 steg (uppdatera den centrala databasen med den första versionen, uppdatera RIB, uppdatera den centrala databasen med den andra versionen, uppdatera RIB, etc.?)

Tack alla för er hjälp!

Svar:() peka på näsan, jag kan inte hitta koden som exekveras vid registrering av ändringar i ett objekt.
Det verkar som att om du använder metoden WhenSendingData, kommer ändrade objekt fortfarande att ackumuleras i huvudnoden för att skicka till slavnoden. Och dessa är extra datorresurser
Därför vill jag att objekten i huvudnoden inte ska registreras för sändning omedelbart vid ändringsögonblicket (Till exempel On Write). På vilken plats, till exempel, i standardredovisning Rev. 3 är dessa objekt registrerade för arkivering?

Fråga: [LÖST] Fel vid kontakt med onlinesupport

Kära experter, berätta för mig!
1C:Enterprise 8.3 (8.3.11.2899)
Det finns flera databaser med olika konfigurationer som körs på 1C-servern, i alla är internetstödet anslutet och fungerar normalt. Inkl. laddar valutakurser, banker, checkar motparter, SPARK osv.
Proxyinställningar i alla databaser är skrivna på samma sätt.
Men i BP-3 KORP-databaserna visas alltid ett fel:

I loggboken:

Det gick inte att erhålla en autentiseringsbiljett från tjänsten.
Det gick inte att läsa in content(). (GeneralModule.InternetUser SupportClientServer.Module(362)): Fel vid anrop av kontextmetoden (SubmitForProcessing)
Response = Connection.SendForProcessing(HTTPRequest, ReceivingParameters.ResponseFileName);
Därför att:
Internetfel: Fjärrvärd misslyckades med verifiering

Klicka för att expandera...

Jag provade det på olika versioner av plattformen (8.3.10..., 8.3.11...) och på olika versioner av konfigurationen (3.0.54.15, 3.0.57.10).
Att testa och fixa hjälper inte heller.
Vad kan vara fel?
Har BP-CORP verkligen tillgång till Internet på ett speciellt sätt?
Tack.

Svar:

Svar från 1C (det som var markerat i rött hjälpte mig):

Under övergången uppdaterades BSP som en del av strömförsörjningsenheten från 2.4.3 till 2.4.4
I listan över ändringar BSP 2.4.4
Ökad säkerhet vid upprättande av en säker anslutning med HTTPS Internettjänster. Om olika problem upptäcks med certifikatet för internettjänsten som man försöker göra en säker anslutning med (certifikatet är inte giltigt, inaktuellt eller inte pålitligt), kommer anslutningen inte att upprättas.
I 8.3.10 utförs certifikatverifiering i Windows med operativsystemet." -
Installera de senaste uppdateringarna för ditt operativsystem De innehåller viktiga uppdateringar av systemkomponenter som är ansvariga för att arbeta med certifikat.
Installera även de senaste rotcertifikatuppdateringarna som distribueras av Microsoft i installationspaketen.
Kräver version som inte är lägre än IE8.0. Den innehåller viktiga uppdateringar av systemkomponenter som ansvarar för att arbeta med certifikat.
Som regel, efter installation av alla uppdateringar, är problemet löst.
Kontrollera att länken öppnas om du anger det i sökfältet i Internet Explorer.
Användaren för vars räkning du arbetar har tillgång till Internet.
Om detta är en fildatabas på klientens dator bör du kontrollera den på den.
Om detta är en klient-server-databas, då på servern under användaren som 1C-servern körs under.
Kontrollera endast med IE-webbläsaren.
Kontrollera att portarna 443 och 80 är öppna
Om en proxyserver används, kontrollera om data är konfigurerade i menyn Personliga inställningar.
Om klient-serverversionen används, då du bör konfigurera servern på ett sådant sätt att anslutningen till Internet med IE-webbläsaren fungerar korrekt under den användare på vars vägnar 1C-servern körs.​

Jag registrerade proxyn i IE-inställningarna för användaren som 1C-servern körde under - allt fungerade.

Fråga: Bukh 3-uppdatering

God dag
Bokföring 3
Jag uppdaterade från 3.0.43.208 till 3.0.43.235
fel
först
(GeneralModule.MessagingInternal.Module(381)): Fel vid anrop av kontextmetod (ThisNode)

Därför att:
Mer än en post hittades
andra
När du anropar uppdateringshanteraren:
"MessagingInternal.SetCodeThisEndPoint()"
Ett fel har uppstått:
"(GeneralModule.MessagingInternal.Module(381)): Fel vid anrop av kontextmetod (ThisNode)
Returnera ExchangePlans.MessageExchange.ThisNode();
Därför att:
Mer än en post hittades."

Jag läste att det finns ett problem med plattformen, jag provade det på olika versioner av plattformarna
Jag försökte ta en ren konfiguration av den senaste versionen och bara dumt ladda den med en komplett ersättning
I allmänhet hjälpte det inte, det var alltid samma sak. Säg mig, har någon stött på detta?

Svar:

Jag ändrade noden från sant till falskt ovan, jag trodde att det inte fungerade, och sedan gick jag för att se att det fungerade