Reicht NT-Workstation bzw. Win95/98 als Rechner fuer DCOM?

[Martin Kellner]

Muss fuer eine DCOM-Verbindung ein Rechner ein NT-Server sein oder reicht NT-Workstation bzw. Win95/98?

Koennen beide Rechner ohne gemeinsame Domaene laufen?

Ich habe hierzu bisher nur sehr wiederspruechliches sammeln koennen

Martin Kellner

[Bernhard Geyer]

Meine Info's und Erfahrungen sind folgende:

Sowohl Windows 95/98 als auch Windows NT Workstation konnen als DCOM-Server eingesetzt werden.

Bei Windows 95 muß DCOM noch installiert werden, bei NT sollte man den neuesten Service Pack einspielen (erst mit SP #3 funktioniert DCOM halbwegs richtig)

weitere Infos unter:

http://www.execpc.com/~dmiser/dcom95.htm<br>
c't Ausgabe 6, 1998, ab Seite 390<br>
oder das Buch COM/DCOM mit Delphi von Andreas Kosch (Sollte man haben, wenn man in dem Bereich COM/DCOM mit Delphi tiefer einsteigen will)

Zu der frage nach der gemeinsamen Domaene steht im c't-Artikel auch einiges.

Mehr kann ich dir jetzt nich helfen, aber ich denke mal daß Du von Andreas Kosch auch noch Infos bekommen wirst

[Martin Kellner]

Ich moechte nochmal etwas genauer werden. Ich habe DCOM testweise ueber eine RAS-Verbindung mit Nullmodemkabel bei 4800 Baud eingesetzt und war erfolgreich damit, doch ist das was ich in Sachen Sicherheit gemacht habe fuer mich nicht nachvollziehbar. Ich muss wohl einen Test mit zwei Rechnern in diversen Konstallationen machen.

Bei der Konfiguration bin ich eben blauaeugig ueber den Sicherheitsaspekt gestolpert. Ich muss das jedoch ausreichend abklaeren, um spaeter damit nicht auf die Nase zu fallen, denn ich will ja per InstallShield oder aehnlichem arbeiten koennen.

Ich habe das Buch von Andreas Kosch mittlerweile und denke das ich das gesamte Thema damit ganz gut in den Griff bekommen werde

[Andreas Kosch]

Hallo,

die vollständigen Sicherheitsmechanismen von DCOM wirken nur dann, wenn alle Rechner in der gleichen Domäne (bzw. trusted domains) sind. Allerdings ist das optional, es dürfen auch unabhängige Domänen sein, wenn der DCOM-Server via DCOMCNFG entsprechend konfiguriert wird.

Für Windows 9x-Rechner gilt das Gleiche - hier stehen die Sicherheitsmechanismen nur eingeschränkt zur Verfügung.

Allerdings darf der Entwickler an DCOMCNFG vorbei alles selber regeln

[Martin Kellner]

Heisst das, das alles was DCOMCNFG erledigt auch zu Fuss per Registry-Eintragung zu erledigen ist?

In meinen Versuchen habe ich natuerlich erstmal diesen Weg gewaehlt.

zu Ihrem Buch noch ein paar Anmerkungen:
Ich lese in Ihrem Buch erst in den ersten Seiten, doch kann ich wie mir beim Ueberfliegen des Gesamtwerkes aufgefallen ist 2 Aussagen sehr deutlich unterstuetzen:

1. Das MSDN-Abo ist auf jedenfall empfehlenswert. Ich habe auch diverse Supportaufgaben in Netzwerk- und Arbeitsplatz-Betreuung damit geloest. Der Zugriff auf Beta- und Produktionsreleases fuer die Entwicklung ist auch sehr wichtig. Sie kostet was, das ist klar, doch Suchzeit im Internet und unvollstaendige Testmoeglichkeiten kosten viel mehr.

2. Die Testumgebung mit Mini-Netzwerk kann sich ein Klein-Entwickler nicht immer leisten, doch wer Irgendwas fuer Datenbank- und Netzwerkumfeld entwickelt, sollte mehr als Rechner integrieren :-)

Ich moechte noch einen dritten Punkt ergaenzen, der ja vielleicht auch irgendwo in Ihrem Buch zu finden ist. Man sollte sich am Besten eine Moeglichkeit fuer ein Disaster-Recovery schaffen. Ich moechte hier keine Produktnamen nennen, doch gerade wenn man Konfigurationen wechselt und diverse Versionen von Windows- und Entwicklungsystemversionen einsetzt, geht es ohne nicht mehr.

Martin Kellne

[Andreas Kosch]

Hallo,

mit DCOMCNFG werden nur die Registry-Einträge gesetzt, die von COM ausgelesen werden, wenn die Anwendung <b>nicht</b> die Win32-API-Funktion <b>CoInitializeSecurity</b> aufruft. In diesem Fall ruft COM implizit diese Funktion selbst auf und verwendet dazu die in der Registry eingetragene Konfiguration. Wenn der eigene COM-Server die Sicherheitseinstellungen selbst regeln will, muss er dazu nicht die Registry-Einträge setzen, da beim expliziten Aufruf von CoInitializeSecurity diese Registry-Einträge gar nicht ausgewertet werden (sondern nur die Parameter beim Aufruf dieser Funktion). Auf diesem Weg kann der Entwickler verhindern, das der Administrator der NT-Maschine die Rechte-Konfiguration des DCOM-Servers ändert (d.h. der Administrator kann zwar die Registry-Einträge ändern, allerdings werden diese dann von COM völlig ignoriert).

Aus meiner Sicht ist das <b>MSDN Library</b> das absolute Minimum, sehr zu empfehlen ist <b>MSDN Professional</b> (mit den ganzen CDROMs der SDKs, Tools und Betriebssystemen). Mit dieser MSDN-Version kann der Entwickler auch mehrere Testrechner mit den aktuellen Betriebssystemversionen ausstatten (Obergrenze liegt bei 10 Rechnern).

Das mit der Datensicherung ist korrekt - ein Bandlaufwerk sollte in jeden Entwicklungsrechner/Server vorhanden sein. Allerdings habe ich das Sicherungsband bisher nur einmal tatsächlich benötigt, um den NT-Server wiederherzustellen. Das geht mit den NT-Bordmitteln (Booten von Diskette, Neuinstallation, Wiederherstellung des letzten Bandes mit dem NT-Backupprogramm) völlig problemlos (abgesehen vom Zeitbedarf)

[Martin Kellner]

Erstmal Danke für die guten Tips.

Natürlich hätte ich exakterweise von der Pro-Version der MSDN schreiben sollen. Das Backup mit NT-Bordmitteln funktioniert sogar in einem Netzwerk das ich betreue gut genug.

Zum Thema DCOM muss ich mich jetzt Aufmachen das Ganze mal selbst nachzuvollziehen. Danach wird es sicher neue Fragen geben.

Das Überstimmen der Registry durch den DCOM-Server dürfte schon die meisten meiner Befürchtungen in Bezug auf Administrierbarkeit ausräumen. Es geht weniger um die Anforderung einer hohen Datensicherheit, sondern mehr um eine stabile Punkt-zu-Punkt-Verbindung über RAS.

Da bleibt natürlich noch die Aktualität des Systems (DCOM,RAS), die ich in den Griff bekommen muss.

Martin Kellne