Announcement

Collapse
No announcement yet.

RPC_S_SERVER_UNAVAILABLE

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RPC_S_SERVER_UNAVAILABLE

    Hallo !

    Folgendes Problem :
    Ein COM-Client versucht mit einem Remote-Rechner eine Verbindung aufzubauen. Der COM-Server startet aber der Client bekommt HRESULT=800706ba zurück.

    Was kann das bedeuten und wie kann ich das das abstellen ?

    Danke im Voraus.

  • #2
    Hallo,

    unter welchem Betriebssystem passiert das? Ich vermute einmal, dass der Benutzer für dieses DCOM-Objekt nur Startrechte, aber <b>keine</b> Zugriffsrechte hat. Über DCOMCNFG.EXE würde ich zuerst prüfen, ob für dieses DCOM-Objekt auf der Registerseite <i>Sicherheit</i> die notwendigen Mindesteinträge vorgenommen wurden. Außerdem ist es immer eine gute Idee, im Problemfall auf der Registerseite <i>Standard-Eigenschaften</i> die Hürden für <i>Standardauthentifizierungsebene</i> und <i>Standardidentitätswechselebene</i> niedriger zu hängen.

    In meinem Buch <i>COM/DCOM/COM+ mit Delphi</i> ist im DCOM-Kapitel eine reichlich bebilderte Schritt-für-Schritt-Anleitung zu finden. Wennd dieser Minimal-Aufruf funktioniert, kann man dann schrittweise die Sicherheitseinstellungen erhöhen

    Comment


    • #3
      Hallo Andreas,

      das war eine schnelle Antwort !

      BS : NT-Workstation und NT-Server
      Jeder hat Startrecht und Zugriffsrecht. Standardauthentifizierungsebene = NONE
      Standardidentitätswechselebene = ANONYMOUS

      Ich entwickle die Application mit C++Builder, deshalb ist Ihr Buch für mich ein bisschen fragwürdig. Aber wenn es mich weiterbringt soll Delphi auch keine Hürde sein.

      Dank

      Comment


      • #4
        Hallo,

        sind alle Benutzer in der gleichen Domäne angemeldet und ist auch der Server Mitglied dieser Domäne? Zur Sicherheit würde ich mich sowohl am Server als auch an der Workstation mit der <b>identischen</b> Administrator-Benutzernamen/Passwort-Kombination interaktiv anmelden und das DCOM-Objekt so in DCOMCNFG konfigurieren, dass es ebenfalls unter dem Konto des interaktiv angemeldeten Benutzers ausgeführt wird. In diesem Fall greift der "Hintereinstieg", der in NT/2000 eingebaut ist, so dass Clients auch außerhalb der Domäne auf den NT-Server zugreifen können, ohne das der GAST-Einstieg aktiviert wird.

        Wenn das Problem danach immer noch auftritt, sind auf beiden Seiten alle eingebundenen Typbibliotheken registriert? Wenn ja, wie sieht der Aufruf im Client aus? Gibt es dort analog zu Delphi auch eine CreateRemote-Methode der CoClass, bei der die IP-Adresse des NT-Servers beim Aufruf übergeben werden kann?

        Notfalls würde ich zuerst einen IUnknown-Interface-Zeiger vom DCOM-Server anfordern und dann im Client erst im zweiten Schritt gegen den "richtigen" Interface-Zeiger (Dual Interface) eintauschen. Wenn man dann im Debugger zeilenweise durchgeht, und der IUnknown-Aufruf gelingt, aber der Umtausch nicht, scheint eine der explizit/implizit eingebundenen TLBs zu fehlen.
        &#10

        Comment


        • #5
          Hallo Andreas,

          das mit den Administratoren habe ich getestet und es ergibt sich den gleichen Fehler. Die Typbibliotheken sind auf beiden registriert. Es gibt auch die entsprechende CreateRemote Methode unter C++Builder. Ich habe auch mit CoCreateInstanceEx versucht. Das Ergebnis ist dasselbe.

          Der DCOM-Server läßt sich zwar auf dem Remoterechner starten aber der Client kann keine Verbindung aufbauen egal ob mit oder ohne IUnknown-Interface.

          Auf dem NT-Workstation ist SP6 installiert und auf dem NT-Server SP5. Kann das der Grund sein ?

          Gru&#223

          Comment


          • #6
            Hallo,

            wie sieht der konkrete CreateRemote-Aufruf aus? Wie sieht der Aufbau des Server-Interfaces aus?

            Bei Problemen ist es immer eine gute Idee, ein neues, sehr schlicht aufgebautes Projekt zu beginnen, das im Interface nur ein Property (Integer) und eine Methode deklariert. Im Typbibliotheks-Editor überzeugt man sich auf der Registerseite Text davon, dass alle dort aufgeführten anderen TLBs (die eingebunden werden), auch wirklich auf beiden Rechnern installiert und registriert sind

            Comment


            • #7
              Hallo Andreas,

              ich habe mir Ihr Buch besorgt und bin trotzdem nicht schlauer geworden.

              Hier ist der Aufruf :

              COSERVERINFO ServerInfo ;<br>
              memset(&ServerInfo, 0, sizeof(ServerInfo)) ;<br>
              ServerInfo.pwszName = WideString(Edit1->Text) ;<br>

              MULTI_QI qi[1] ;<br>
              memset(&qi, 0, sizeof(qi)) ; <br>
              qi[0].pIID = &IID_IUnknown ; <br>

              if (SUCCEEDED(CoInitializeEx(NULL, COINIT_APARTMENTTHREADED))) {<br>
              hr = CoCreateInstanceEx(CLSID_MyTest, NULL,<br>
              CLSCTX_SERVER, &ServerInfo, 1, qi) ;<br>

              OleCheck(hr) ; // hier wird das Programm gestoppt <br>

              if (SUCCEEDED(qi[0].hr)) {<br>
              qi[0].pItf->QueryInterface(IID_IMyTest, (void**)&test) ; <br>

              .....

              Ich habe folgendes festgestellt, daß das Problem nur bei Rechnern ohne Domain-Anmeldung auftritt. Falls diese Konfiguration dieses Problem verursacht, wie kann ich es ohne Netzwerk-Umkonfiguration lösen ?

              Dank

              Comment


              • #8
                Hallo,

                wenn auch Workstations auf den DCOM-Server zugreifen sollen, die <b>nicht</b> vom gleichen Domänen-Kontroller verwaltet werden bzw. bei denen keine Vertrauensstellung (Trusted Domain) besteht, muss der DCOM-Rechner sein <b>Gast</b>-Benutzerkonto aktivieren (ist als Vorgabe zwar vorhanden, aber gesperrt). Nur dann bedeutet die spezielle NT-Gruppe <i>JEDER</i> auch wirklich jeder Aufrufer. Bei gesperrtem Gast-Konto entspricht die Gruppe JEDER nur der speziellen Gruppe <i>Authentifiziere Benutzer</i> (d.h. jeder Benutzer, der sich erfolgreich an der Domäne angemeldet hat)

                Comment


                • #9
                  Hallo,

                  das Gastkonto ist bei dem fehlgeschlagenen Server nicht deaktiviert bei den anderen funktionierenden Servern aber gesperrt.

                  Bin ich mit meinem Latein am Ende

                  Comment


                  • #10
                    Hallo,

                    dann würde ich mir bei NT 4 die Situation mit dem Tool <b>dcomcnfg.exe</b> anschauen: <br>
                    a) Registerseite <i>Standardeigenschaften</i>: Ist DCOM deaktiviert? <br>
                    b) Registerseite <i>Standardeigenschaften</i>: Standardeigenschaften der DCOM-Kommunikation auf niedrige Level setzen. <br>
                    c) Falls a) und b) nicht zum Erfolg führen, alle anderen Einstellungen mit dem Rechner vergleichen, auf dem der Zugriff erfolgreich ist

                    Comment


                    • #11
                      Hallo,

                      danke für die ganzen Bemühungen !

                      Ich habe die einfachere Methode gewählt d.h. Neuinstallation mit Domain-Anmeldung. Diese Vorgehenweise ist nicht professionel aber nicht so zeitberaubend.

                      Danke danke noch einmal

                      Comment

                      Working...
                      X