Häufig gestellte Fragen zu DCOM95

Dieser Artikel beantwortet einige der häufig gestellten Fragen über DCOM95.

Fragen

1. Funktioniert COM auf nur Windows 95-Netzwerke? Werden Windows 95-Computer kann als eine COM-Server-Computer in einem solchen Fall eingesetzt?
2. Das Programm DCOMCNFG.exe erzeugt eine Fehlermeldung, bei der Ausführung auf einem Windows 95-Computer mit Freigabe auf Zugriffssteuerung. Kann dieser Mittelwert DCOM auf solchen Computern nicht funktioniert?
3. Beim Aufrufen von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben, gibt die API RPC_S_SERVER_UNAVAILABLE zurück. Worin besteht die Ursache dieses Fehlers?
4. Beim Aufrufen von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben, gibt die API CO_E_SERVER_EXEC_FAILURE zurück. Worin besteht die Ursache dieses Fehlers?
5. Beim Aufrufen von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben, gibt die API RPC_E_NO_GOOD_SECURITY_PACKAGES zurück. Worin besteht die Ursache dieses Fehlers?
6. Wenn ich einen Anruf an den remote com-Server auf einem Windows 95-Computer ausgeführt zu tätigen, wird den Fehler RPC_S_UNKNOWN_AUTHN_SERVICE. Worin besteht die Ursache dieses Fehlers?
7. Wenn ich einen Anruf an den remote com-Server auf einem Windows 95-Computer ausgeführt zu tätigen, wird den Fehler RPC_S_SERVER_TOO_BUSY. Worin besteht die Ursache dieses Fehlers?
8. Ich habe einen com-Client auf einem Windows 95-Computer, der einen Server auf einem Windows NT-Computer gestartet wird. Wenn der Server versucht, die der Client wieder aufrufen, schlägt der Rückruf mit E_ACCESSDENIED. Worin besteht die Ursache dieses Fehlers?
9. Wie kann ich zwischen zwei Computern in einem Netzwerk nur für Windows 95, Windows 95 arbeiten Netclip erstellen?
10. Wie kann ich sicher zwischen zwei Windows 95-Computern in einem Windows 95/NT Netzwerk arbeiten Netclip erstellen?

In den folgenden Erläuterungen, wo ein COM-Server genannt wird, bedenken, dass ein com-Client, Rückrufe ermöglicht (z. B. über die Verbindungspunkt-Mechanismus) ist in Wirklichkeit ein COM-Server und daher werden die gleichen Faktoren, die für einen com-Server gelten auf solche COM-Clients anwenden.

Darüber hinaus finden Sie im Verweise Abschnitt für zusätzliche KB-Artikel, die einige der Probleme ausführlich beschreiben.

F1: Werden COM auf nur Windows 95-Netzwerke ausgeführt? Werden Windows 95-Computer kann als eine COM-Server-Computer in einem solchen Fall eingesetzt?

A: die Antworten auf beide Fragen sind Ja. Sie können com-Clients und Servern auf nur Windows 95-Netzwerken ausführen. Wenn eine NT-Domäne im Netzwerk vorhanden ist, kann Windows 95-Authentifizierung/Autorisierung über ein Pass - Through Sicherheitsmechanismus bereitstellen. Wenn im Netzwerk keine NT-Domänen vorhanden sind, können nur nicht sichere Aufrufe in solche Netzwerke vorgenommen werden. Da das Standardverhalten von COM für sichere Anrufe ist, muss dieses Verhalten geändert werden, bevor ein com-Client einen com-Server in einem nur-Windows 95-Netzwerk erfolgreich aufrufen kann.

Bevor besprochen, wie dies realisiert wird, lassen Sie uns kurz wie die Sicherheit in allgemeine funktioniert in COM-Sicherheit auf eine remote COM-Aktivierung eines Prozesses drei Schritt ist.

Sicherheit auf eine COM-Remoteaktivierung

Schritt 1:

Zunächst legen die Authentifizierungsebene der COAUTHINFO Struktur an eine Aktivierung API übergeben werden, z. B. CoCreateInstanceEx() bestimmt, wenn der serverseitige SCM zum Authentifizieren des Clients versucht. COAUTHINFO ist ein Feld innerhalb der Struktur COSERVERINFO. Wenn die Authentifizierungsebene, legen Sie in der Struktur COAUTHINFO etwas anderes als RPC_C_AUTHN_LEVEL_NONE ist, versucht der SCM auf der Serverseite der Client authentifiziert. Wenn diese Authentifizierung fehlschlägt, wird die Aktivierung API zurückgewiesen. Wenn die Authentifizierungsebene in setzen COAUTHINFO Struktur RPC_C_AUTHN_LEVEL_NONE ist, wird Authentifizierung wird nicht versucht (Dies ist eine anonyme Aktivierungsversuch schlägt betrachtet).

Schritt 2:

In beiden Fällen, in die nächste Schritt überprüft der Dienststeuerungs-Manager, ob der Client starten Berechtigungen tatsächlich auf den com-Server haben. Wenn der Client keinen starten Berechtigungen, wird die Aktivierung API zurückgewiesen. Wenn der Client starten Berechtigungen verfügt, wird der com-Server gestartet. Anonyme Aktivierungsanforderungen starten Berechtigung die Sicherheitsbeschreibung muss einen NULL-DACL enthalten oder eine ZUGRIFFSSTEUERUNGSLISTE, die "Jeder" ermöglicht zugreifen. Beachten Sie, wenn der Server bereits gestartet wurde, nicht die Überprüfung der Berechtigungen Starten ausgeführt wird.

Im Fall von Windows 95 muss ein COM-Server pre-launched sein, bevor ein com-Client kann verbunden, daher keine Berechtigungen Starten sind aus und daher keine Überprüfung für diese ist. Authentifizierung Schritt wird weiterhin ausgeführt, und die Authentifizierungsebene, festlegen in COAUTHINFO ist daher wichtig. Wenn der Client gibt nicht an eine explizite COAUTHINFO Struktur und den Zeiger NULL verlässt, versucht standardmäßig COM, den Client zuerst zu authentifizieren. Wenn Sie den Client authentifizieren kann, überprüft er die Sicherheitsbeschreibung starten, ob anonyme Aktivierung zulässig ist. Wenn Ja, starten Sie den Server (wie üblich, wenn der Server wurde bereits gestartet ist mit dieser Prüfung wird nicht ausgeführt).

Schritt 3:

Die dritte Schritt des Aktivierungsvorgangs ist einen Zeiger auf die Klassenfactory oder auf das eigentliche Objekt erhalten. Diese Schritt unterliegt Aufruf Sicherheit und die Zugriffsberechtigungen legt auf dem Server, die weiter unten erläutert. Beachten, die für anonyme Aktivierung, Sicherheit Aufruf / Zugriffsberechtigungen werden nicht überprüft, aber stattdessen Wenn der Server anonymen Aktivierung berechtigt, Klasse Factory Zeiger oder ein Objektzeiger zurückgegeben an den Client zu diesem Zeitpunkt.

Sicherheit auf eine Remote-Unterhaltung

Sicherheit auf einem Remoteaufruf ist ein zweistufiger Prozess.

Schritt 1:

Die erste ermittelt die Authentifizierungsebene für den Proxy festlegen Sicherheit auf einen COM-Aufruf. Die Standardauthentifizierungsebene auf einem Proxy festlegen wird durch wie der Client und Server der CoInitializeSecurity()-API Aufrufen bestimmt. Der Standardwert ist der höhere durch den Client und Server für den Parameter DwAuthnLevel diese API angegebenen Werten. Für einen bestimmten Aufruf kann der Client die Authentifizierungsebene auf dem Proxy über CoSetProxyBlanket(), wodurch die Standardeinstellung außer Kraft ändern. Der Client kann nicht jedoch ein Authentifizierungsebene auf dem Proxyserver angeben, der kleiner als, die vom Server in den Aufruf CoInitializeSecurity() angegeben ist.

Wenn der Server RPC_C_AUTHN_LEVEL_CONNECT in den Aufruf an CoInitializeSecurity() gibt und der Client RPC_C_AUTHN_LEVEL_PKT gibt, ist die Standardauthentifizierungsebene auf alle Proxies in der Client z. B. RPC_C_AUTHN_LEVEL_PKT. Der Client kann die Authentifizierungsebene bei einem Aufruf RPC_C_AUTHN_LEVEL_PKT_PRIVACY durch Aufrufen von CoSetProxyBlanket() ändern. Jedoch kann der Client die Authentifizierungsebene nicht zu RPC_C_AUTHN_LEVEL_NONE, ändern, da der vom Server angegebenen Mindestwert RPC_C_AUTHN_LEVEL_CONNECT ist. Wenn ein Prozess die CoInitializeSecurity()-API nicht explizit aufrufen, ruft die COM-Laufzeit die API stellvertretend für den Prozess. Die Authentifizierungsebene für diesen Standard-Anruf wird aus den folgenden Registrierungsschlüssel (Beachten Sie) abgerufen, dass dies eine computerweite Einstellung und keine Prozess-spezifischen ist.

Dies ist ein benannter Wert DWORD. Der Wert 1 entspricht RPC_C_AUTHN_LEVEL_NONE, 2 entspricht RPC_C_AUTHN_LEVEL_CONNECT und So weiter.

Schritt 2:

Wenn ein Anruf eingeht, wird zuerst die Authentifizierungsebene für den Aufruf überprüft. Wenn die Authentifizierungsebene etwas anderes als RPC_C_AUTHN_LEVEL_NONE ist, wird der Client authentifiziert. Dann wird eine Sicherheitsbeschreibung für Zugriffsberechtigungen des Servers, eine Zugriffsüberprüfung erfolgt durch Vergleichen der Identität des Clients anhand dieser Sicherheitsbeschreibung.

Wenn der Aufruf an RPC_C_AUTHN_LEVEL_NONE eingeht, erfolgt eine Clientauthentifizierung nicht. In diesem Fall ist es fehlerhafte eine Sicherheitsbeschreibung für Zugriffsberechtigungen des Servers an. Daher wird ein Aufruf von CoInitializeSecurity angeben einer Sicherheitsbeschreibung ungleich NULL und eine Authentifizierung Sicherheitsstufe RPC_C_AUTHN_LEVEL_NONE einen Fehler zurückgegeben. Beachten Sie jedoch, wenn der Server ruft nicht CoInitializeSecurity (stattdessen beruht auf der Computerebene Standardauthentifizierungsebene) und wenn diese Authentifizierungsebene ist RPC_C_AUTHN_LEVEL_NONE, eine Zugriffsüberprüfung erfolgt keine gegen (Registrierung-basiert) die Sicherheitsbeschreibung für die Serverklasse. Der Client wird immer noch authentifiziert werden, wenn die Authentifizierungsebene nicht RPC_C_AUTHN_LEVEL_NONE ist.

Wenn ein Aufruf an RPC_C_AUTHN_LEVEL_CONNECT oder oberhalb eingeht, führt COM eine Zugriff überprüfen, ob das Clientkonto zulässig ist, den Server aufrufen, indem Sie die Liste Zugriffsberechtigungen für den Server. Wenn das Clientkonto Zugriff unzulässig ist, wird der Anruf zurückgewiesen. Andernfalls wird der Aufruf zugelassen.

wie Sie DCOM auf einem Netzwerk nur Windows 95 - Setup

COM-Server:

Rufen Sie CoInitializeSecurity(), als die Authentifizierungsebene RPC_C_AUTHN_LEVEL_NONE übergeben. Wenn der Server aus irgendeinem Grund nicht diese API aufrufen können (z. B. es ist ein in-Process-DLL-Server), ändern Sie die computerweiten Authentifizierung-Level-Einstellung auf RPC_C_AUTHN_LEVEL_NONE, durch Ändern des in Schritt 1 oben mit dem Registrierungseditor erwähnten Registrierungsschlüssels. Der Computer muss re-booted, damit diese Änderung wirksam werden.

Warnung : unkorrekte Verwendung des Registrierungseditors kann schwerwiegende, systemweite Probleme verursachen, installieren Sie Windows 95 zur Fehlerkorrektur erforderlich machen, die. Microsoft kann nicht garantieren, dass alle Probleme, die aus der Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie das Programm auf eigene Verantwortung.

Hinweis : bei die oben genannten Änderung in der Registrierung vornehmen, ist es wichtig, die COM-Aufruf Sicherheit zu verstehen, für der gesamte Computer ausgeschaltet ist. Jeder Client werden in alle COM-Serverprozess auf den Computer ausgeführt, wenn der Client auf dem Server halten einen Schnittstellenzeiger auf ein Objekt erhält aufrufen können. Daher müssen Sie beim Ändern dieser Einstellung computerweiten vorsichtig sein. Es wird dringend empfohlen, dass ein COM-Serverprozess CoInitializeSecurity() eigene Sicherheit festlegen Ebene, sondern die Computer-Einstellung ändern aufrufen.

Bevorstehende Versionen von COM haben die Möglichkeit an Authentifizierungsebenen pro Prozess, so dass die oben beschriebenen Problemumgehung nicht erforderlich ist. Auf diese Weise können Sie die Aufruf-Sicherheit auf Basis eines Prozesses vom Prozess steuern. Dieses Feature steht in der Webversion DCOM95 1.1 (verfügbar bald), Internet Explorer 4.0 für Windows 95 und Windows 98 (Beta 2 oder höher).

COM-Clients:

Die Aktivierung muss zuerst eine Authentifizierung Sicherheitsstufe RPC_C_AUTHN_LEVEL_NONE angeben. Dies kann entweder indem COAUTHINFO Zeiger in COSERVERINFO als NULL (Standard) oder durch Festlegen RPC_C_AUTHN_LEVEL_NONE in der Struktur COAUTHINFO erfolgen. Im ehemaligen Fall COM versucht eine authentifizierte Aktivierung zuerst, und greift dann zurück, um eine nicht-Aktivierung authentifiziert. In letzterem Fall müssen Sie auch RPC_C_IMP_LEVEL_IMPERSONATE für DwImpersonationLevel-Parameter angeben.

Zweitens müssen Aufrufe eine Authentifizierung Sicherheitsstufe RPC_C_AUTHN_LEVEL_NONE angeben. Dafür muss der Client übergeben RPC_C_AUTHN_LEVEL_NONE CoInitializeSecurity() aufrufen. Wenn Sie CoSetProxyBlanket() verwenden, muss zu dieser API sowie RPC_C_AUTHN_LEVEL_NONE angegeben werden. Wie im Fall Server Wenn der Client CoInitializeSecurity(), aufrufen kann nicht kann dann die computerweite-Authentifizierungsebene in der Registrierung (wie oben erläutert) geändert werden.

Dritte, stellen Sie sicher, dass sichere Verweiszählung nicht aktiviert ist. Sichere Verweiszählung DCOMCNFG aktiviert werden kann und in der Registrierung am folgenden Speicherort angezeigt:

Standardmäßig ist dieser Schlüssel nicht vorhanden und sicheren Verweiszählung ist nicht aktiviert.

Hinweis : Es scheinen aus der obigen, dass der Client nicht aufrufen, CoInitializeSecurity(), muss können aber CoSetProxyBlanket() verwenden, um die Authentifizierung auf einzelnen Proxys steuern. Jedoch dies funktioniert nicht richtig, weil der Release() verwendet das Standard-Authentifizierung auf dem Proxy rufen Sie immer (d. h., der festgelegt in CoInitializeSecurity), daher der Client werden keine, das Serverobjekt herunterzufahren, sofern die Standard-Authentifizierung auf dem Proxy als RPC_C_AUTHN_LEVEL_NONE festgelegt. Zu diesem Zweck müssen Sie CoInitializeSecurity(), entweder explizit oder implizit aufrufen. Wenn das Serverobjekt nicht Verweiszählung interessiert, ist dies kein Problem.

F2: Das Programm DCOMCNFG.exe erzeugt eine Fehlermeldung, bei der Ausführung auf einem Windows 95-Computer mit Freigabe auf Zugriffssteuerung. Kann dieser Mittelwert DCOM auf solchen Computern nicht funktioniert?

A: Nein, diese eine Einschränkung des Dcomcnfg.exe strikt ist. Oleview.exe kann auf Computern mit Zugriffssteuerung auf Benutzerebene Freigabe verwendet werden. DCOM funktioniert ordnungsgemäß über die Zugriffssteuerung Freigabe auf Windows 95-Computern. Die Antwort auf Frage 1 veranschaulicht, wie Sie ohne Sicherheit auf diesen Computern eingerichtet.

F3: Beim Aufruf von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben gibt die API RPC_S_SERVER_UNAVAILABLE. Worin besteht die Ursache dieses Fehlers?

A: Es gibt verschiedene Gründe für diesen Fehler.

führen 1: der DNS-WINS-Namensauflösung ist nicht einrichten oder ordnungsgemäß arbeiten

Achten Sie zunächst, dass Sie den remote-Computer nach Namen anpingen können. Wenn Sie es nach Namen nicht pingen können, ist wahrscheinlich die DNS-WINS-Namensauflösung nicht Setup oder funktionieren nicht ordnungsgemäß in Ihrem Netzwerk. Sie können nicht in diesem Fall den Computernamen an DCOM entweder angeben. Versuchen Sie mithilfe seiner IP-Adresse pingen Wenn dies funktioniert, können Sie die IP-Adresse anstelle des Computernamens an DCOM angeben. Wenn durch Ping IP-Adresse auch funktioniert nicht und TCP/IP ist nicht ordnungsgemäß in Ihrem Netzwerk installiert. Sie müssen dieses Problem beheben, bevor Sie DCOM im Netzwerk verwenden können. Beachten Sie, das die Möglichkeit, NETBIOS aufzulisten teilt (über die "net \\NETBIOSNAME anzeigen" Befehl) bedeutet nicht, dass TCP/IP ordnungsgemäß installiert ist, kann NETBIOS über NETBEUI-Transport ausgeführt werden.

Überprüfen Sie ob, die Registrierungsschlüssel "EnableDCOM" und "EnableRemoteConnect" unter HKLM\Software\Microsoft\OLE auf dem Servercomputer auf "Y" festgelegt sind. "EnableDCOM" muss auf "Y" festgelegt werden, um verteilte COM-Funktionen zu aktivieren. "EnableRemoteConnect" muss auf "Y" festgelegt werden, damit den Computer als Server fungieren. Sie müssen die Server Neustart, damit diese Änderung wirksam.

führen 2: RPCSS.exe wurde nicht ordnungsgemäß auf dem Remotecomputer gestartet

Die andere wichtige Ursache für diesen Fehler ist, dass RPCSS.exe korrekt an einen bekannten Fehler in DCOM95 1.0 auf dem Remotecomputer nicht gestartet ist. RPCSS.exe ist der Resolver/end-point Mapper-Prozess, die ausgeführt werden, bevor alle remote DCOM-Aufrufe durchgeführt werden können. Unter Windows NT ist RPCSS ein Windows NT-Dienst, der gestartet wird, wenn der Computer gestartet wird. Unter Windows 95 wird RPCSS Prozess Grundlage "zögernd" oder bei Bedarf gestartet. Beachten Sie, dass für nur-lokale-Kommunikation RPCSS nicht erforderlich ist und wird nicht gestartet. Aber wenn der Registrierungseintrag "EnableRemoteConnect" auf "Y" festgelegt ist, RPCSS wird gestartet automatisch Wenn ein COM-Server CoRegisterClassObject() zum Registrieren ihrer Klassen aufruft.

Dies gilt unabhängig davon, ob der Client, der der Server gestartet auf demselben Computer oder auf einem Remotecomputer handelt. Dies gilt auch, wenn der Server gestartet wird, manuell (wie der Normalfall unter Windows 95) außer unter den folgenden Bedingungen:

• Der Aufruf zu CoRegisterClassObject() erfolgt von Single Threaded Apartment (STA) Server.

In diesem Fall aufgrund von einen Bug in DCOM95, RPCSS.exe wird nicht automatisch gestartet und somit schlagen ein Remoteclient mit Fehler RPC_S_SERVER_UNAVAILABLE. Das gleiche Problem geschieht, wenn ein lokaler Client den Server gestartet. Der lokale Client wird funktionieren, aber wenn ein Remoteclient versucht, eine Verbindung zum Server herzustellen, erhalte der Remoteclient die Fehlermeldung.

Sie können dieses Problem umgehen, indem RPCSS.exe pre-launching, bevor alle Klassenobjekte registriert sind. Eine bequeme Möglichkeit dazu ist in der Registrierung am HKLM\Software\Microsoft\Windows\CurrentVersion\Run, die gestartet wird, wenn die Shell geladen wird, oder \RunServices, die unmittelbar nach dem Starten des Computers startet (d. h. bevor Anmeldung). Fügen Sie einen benannten Wert (einen beliebigen Namen) und einem Wert von "Rpcss.exe". Dieses Problem wird in der DCOM95 1.1 Web Release behoben (verfügbar bald), Internet Explorer 4.0 für Windows 95 und Windows 98 (Beta 2 oder höher).

Schließlich stellen Sie sicher, dass der COM-Serverprozess gestartet wird und seine Klassen durch Aufrufen von CoRegisterClassObject() wurde erfolgreich registriert.

F4: Beim Aufruf von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben gibt die API CO_E_SERVER_EXEC_FAILURE. Worin besteht die Ursache dieses Fehlers?

A: zur Lösung dieses Problems:

1. Stellen Sie sicher, dass der folgenden Registrierungseintrag auf dem Server auf "Y" festgelegt ist:

   HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
   EnableRemoteConnect='Y'
   						

   müssen Sie die Server Neustart, damit diese Änderung wirksam.
2. Stellen Sie sicher, dass der com-Server bereits auf dem Computer gestartet ist und seine Klassen durch Aufrufen von CoRegisterClassObject() wurde erfolgreich registriert. DCOM95 führt keine Remoteaktivierung. Daher muss der Server ausgeführt werden, bevor ein Remoteclient eine Verbindung herstellen kann.

F5: Beim Aufruf von CoCreateInstanceEx() einen remote Windows 95-Computer-Namen angeben gibt die API RPC_E_NO_GOOD_SECURITY_PACKAGES. Worin besteht die Ursache dieses Fehlers?

A: Dieser Fehler tritt auf, wenn RPCSS.exe gestartet wird, nachdem ein Clientprozess gestartet und der Clientprozess dann sichere remote COM-Aufrufe, wie z. B. CoCreateInstanceEx() nimmt. Genommen Sie an, Sie haben einen com-Client-Prozess "A", der gestartet und führt möglicherweise einige lokalen COM-Aktivitäten (RPCSS.exe ist noch nicht gestartet). Jetzt einem anderen Clientprozess "B" beginnt und führt remote COM-Aufruf, wodurch RPCSS.exe starten. Wenn Client "A" versucht, einen sicheren remote COM-Anruf zu tätigen, wird es jetzt dieser Fehler ausgegeben. Wenn "A"-Client einen nicht sichere remote COM-Aufruf versucht, erhalten Sie Fehler RPC_E_INVALID_PARAMETER.

Dieser Fehler tritt auf, da Sicherheitsinformationen werden ist nicht ordnungsgemäß synchronisiert, wenn wenn RPCSS in einem Client zu starten, COM feststellt, dass er bereits gestartet wurde.

Wie in der Antwort auf Frage 3 können Sie dieses Problem von Prä-starten RPCSS.exe umgehen, vor dem Starten des Clientprozess. Eine bequeme Möglichkeit dazu ist in der Registrierung am HKLM\Software\Microsoft\Windows\CurrentVersion\Run, die gestartet wird, wenn die Shell geladen wird, oder \RunServices, die unmittelbar nach dem Starten des Computers startet (d. h. bevor Anmeldung). Fügen Sie einen benannten Wert (einen beliebigen Namen) und einem Wert von "RPCSS.EXE".

Dieses Problem wird in der Webversion DCOM95 1.1 behoben (verfügbar bald), Internet Explorer 4.0 für Windows 95 und Windows 98 (Beta 2 oder höher).

F6: Wenn ich einen Anruf an den remote com-Server auf einem Windows 95-Computer zu tätigen, wird den Fehler RPC_S_UNKNOWN_AUTHN_SERVICE. Worin besteht die Ursache dieses Fehlers?

A: Dieser Fehler bedeutet, dass Sie versuchen, einen sicheren Aufruf (Authentifizierungsebene auf dem Proxyserver ist RPC_C_AUTHN_LEVEL_CONNECT oder höher), aber Windows 95-Computer auf Freigabe auf Zugriffssteuerung festgelegt ist und den Aufruf nicht authentifizieren kann. Die Antwort auf Frage 1 Weitere Informationen finden Sie auf wie Sie DCOM-Aufrufe nicht sichere. Hinweis: Wenn die COAUTHINFO Struktur RPC_C_AUTHN_LEVEL_CONNECT gibt oder oben eine Aktivierung API wie z. B. CoCreateInstanceEx() den gleichen Fehler erhält.

F7: Wenn ich einen Anruf an den remote com-Server auf einem Windows 95-Computer zu tätigen, wird den Fehler RPC_S_SERVER_TOO_BUSY. Worin besteht die Ursache dieses Fehlers?

A: Dieser Fehler bedeutet, dass Sie versuchen, einen sicheren Aufruf Ebene eine Authentifizierung über RPC_C_AUTHN_LEVEL_CONNECT. Windows 95 akzeptiert eingehende COM-Aufrufe nur auf einer Authentifizierungsebene von RPC_C_AUTHN_LEVEL_CONNECT oder unten. Es gibt keine Zugriffsbeschränkungen für die Authentifizierungsebene der ausgehenden Anrufe. Die Antwort auf Frage 1 Weitere Informationen finden Sie auf wie ein Client Proxy seine Standardauthentifizierungsebene erhält und wie ein Client (über CoSetProxyBlanket) geändert werden kann. Aufgrund muss dieser Einschränkung einen Windows 95 com-Server (oder COM-Clients, die Rückrufe akzeptiert) angeben auf die meisten RPC_C_AUTHN_LEVEL_CONNECT Authentifizierungsebene CoInitailizeSecurity() aufrufen. Es kann nicht alles oberhalb dieser Ebene angegeben werden. Wenn dies der Fall ist, schlägt die eingehende Remoteaufrufe mit dem oben genannten Fehler fehl.

F8: ist einen com-Client auf einem Windows 95-Computer, der einen Server auf einem Windows NT-Computer gestartet wird. Wenn der Server versucht, die der Client wieder aufrufen, schlägt der Rückruf mit E_ACCESSDENIED. Worin besteht die Ursache dieses Fehlers?

A: Stellen Sie sicher, dass die Identität des Servers nicht auf "Launching User" festgelegt ist. (Sie können Dcomcnfg.exe verwenden, um die Identität des Servers überprüfen). "Benutzer starten" oder "Aktivieren als Activator" Prozesse fehlen Anmeldeinformationen für sichere Anrufe außerhalb des eigenen Computers. Beachten Sie, dass das gleiche Layout funktionieren, wenn der Client auf einem Windows NT-Computer handelt und die Authentifizierungsebene auf den Rückruf RPC_C_AUTHN_LEVEL_CONNECT ist. Windows NT verwendet den NULL-Sitzung Freigabe-Mechanismus, damit diese funktioniert. Dies ist nicht möglich, mit Windows 95. Beachten Sie, dass auch unter Windows NT Falls die Authentifizierung auf den Rückruf über RPC_C_AUTHN_LEVEL_CONNECT, ist der Rückruf mit dem RPC_S_SEC_PKG_ERROR Fehler fehlschlagen wird.

Verwenden Sie dcomcnfg.exe, um die Identität des Servers an den "Interaktiver Benutzer" oder "Dieser Benutzer" zu ändern. Dadurch wird den Server sichere Rückrufe stellen können. Die andere Option unsichere Rückrufe, indem Sie RPC_C_AUTHN_LEVEL_NONE festlegen, auf dem Proxy Rückruf ist (Siehe Frage 1).

F9: Wie kann ich zwischen zwei Computern in einem Netzwerk nur für Windows 95, Windows 95 arbeiten Netclip erstellen?

A: Netclip ist eine DCOM-Beispielanwendung, die Sie an einem Remotecomputer Zwischenablage verwenden können. Sie erhalten von http://www.interdesigner.com/downloads.htm (http://www.interdesigner.com/downloads.htm)

Die folgenden Anweisungen erläutern, wie Netclip zwischen Windows 95-Computern in einem nur-Windows 95-Netzwerk kommunizieren. Da keine Windows NT-Computer oder Windows NT-Domänen auf diesem Netzwerk vorhanden sind, ist keine Benutzer auf Sicherheit. DCOM-Aufruf Sicherheitsstufe für den gesamten Computer daher deaktivieren diese Anweisungen. Eine Erläuterung der Sicherheitsaspekte dieses Ansatzes finden Sie unter Frage 1.

1. Installieren Sie DCOM95 auf beiden Computern.
2. Pingen Sie den Servercomputer vom Clientcomputer seine NETBIOS-Namen, DNS-Namen oder IP-Adresse. Wenn der Ping-Befehl mit einem dieser Namen erfolgreich ist, kann der gleiche Namen als Computername Server an COM übergeben werden Wenn von ping IP-Adresse nicht funktioniert, und Sie können DCOM nicht verwenden. Sie müssen installieren und konfigurieren Sie TCP/IP zuerst.
3. In der Registrierung die folgenden benannten Wert müssen festgelegt werden zu "Y" auf beiden Computern:

   HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
   EnableDCOM
   						

   die folgenden benannten Wert müssen auf "Y" auf dem Servercomputer Netclip festgelegt werden:

   HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
   EnableRemoteConnect
   						

   Wenn Sie diese Werte ändern, bedenken, die Sie den Computer neu starten, damit diese Änderung wirksam wird.
4. Die folgenden benannten Wert (REG_DWORD) muss auf 1 festgelegt (keine) auf beiden Computern:

   HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
   LegacyAuthenticationLevel
   						

   Wenn der benannte Wert nicht vorhanden ist, können Sie es erstellen.
   
   Wenn Sie erstellen/diesen Wert ändern, müssen Sie berücksichtigen, die Sie Neustart durchführen, damit diese Änderung wirksam wird.
   Hinweis : bei Computern mit Benutzersicherheit auf können Sie dcomcnfg.exe verwenden, um diese Änderungen vornehmen. Auf einem Computer mit Freigabe auf Sicherheit, müssen Sie manuell (über REGEDIT) oder programmgesteuert (mithilfe der Registrierung Win32-APIs) diese Änderungen vornehmen, da Dcomcnfg.exe nicht ausgeführt wird.
5. Starten Sie beide Computer neu.
6. Starten Sie RPCSS.exe von der Befehlszeile auf dem Windows 95-Computer ist, wobei der Netclip-Server ausführen. Dies ist eine Problemumgehung für einen bekannten Fehler in DCOM95 1.0. (andere Möglichkeiten pre-starting RPCSS.exe finden Sie unter Frage 2) Diese Schritt ist nicht erforderlich, wenn Sie DCOM95 1.1, Internet Explorer 4.0 oder Windows 98 (Beta 2 oder höher) installiert.
7. Starten Sie den Netclip-Server als "Netclip/Server"
8. Starten Sie auf dem Windows 95-Clientcomputer Netclip, und geben Sie der Computernamen (oder die IP-address-see Schritt b) des Servercomputers an.

F10: Wie kann ich sicher zwischen zwei Windows 95-Computern auf einem Windows 95/Windows NT-Netzwerk arbeiten Netclip erstellen?

A: Da eine Windows NT-Domäne im Netzwerk ist, können Sie die Pass-Through-Sicherheit von Windows NT-Domäne verwenden. Dazu stellen Sie sicher, dass die beide die Windows 95-Computer festgelegt sind, Benutzerzugriffssteuerung Ebene mit Namen von Benutzern und Gruppen, die vom Windows NT-Domäne verwenden. Dazu können Sie im Applet Netzwerk in der Systemsteuerung. Verwenden Sie dcomcnfg.exe, um die computerweite Authentifizierungsebene Verbindung auf beiden Computern festzulegen. Verwenden Sie auf dem Servercomputer Netclip Dcomcnfg.exe, um die Zugriffsberechtigungen auf Netclip-Clientcomputer angemeldet ist Windows NT-Domänenkonto zuweisen. Dies kann geschehen entweder für die Standard Zugriffsberechtigungen des Servercomputers oder benutzerdefinierten Zugriffsberechtigungen des Netclip-Servers selbst sein. Verwenden Sie auf dem Clientcomputer Netclip Dcomcnfg.exe, um die Zugriffsberechtigungen der Netclip-Server-Computer derzeit angemeldet ist Windows NT-Domänenkonto zuweisen. Sie müssen für die Standardliste der Zugriffsberechtigungen des Clientcomputers vornehmen, da der Netclip Server Rückrufe in den Client machen und der Netclip-Client muss Zugriffsberechtigungen auf den Server-Konto gewähren. Führen Sie die Schritte in Frage 9 (mit Ausnahme von Schritt 4 zum Deaktivieren der Aufruf Sicherheit) um die Netclip Client/Server-Sitzung zu starten.

Weitere Informationen finden Sie in die folgenden Artikeln der Microsoft Knowledge Base: