Dcom

[Power_Pete]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Es geht um eine Remoteverbindung eines OPC Servers mit einem Client.

Es handelt sich um folgende Komponenten:

Client PC: - Windows Server 2003 SP 2 Standart
- OPC Test CLient

Server PC: - Windows XP SP3 Profesional
- 3S Codesys OPC
- Deltalogic OPC

Ich bekomme keine Verbindung zum Codesys Server zustande. Firewall ist abgeschalten. Gleiches Netzwerk. Mit selbem User an beiden Rechner angemeldet. DCOM konfiguration laut Deltalogic Hilfe eingestellt (Deltalogic Server als Dienst laufen).

Ich habe von 3S auch eine Hilfe zu DCOM Einstelllung erhalten, diese schneidet sich aber mit der von deltalogic.

Ich hab das Gefühl es liegt an den User Einstellungen. Müssen die im Taskmanager auftretenden Dienst (OPCEnum, Deltalogic OPC, OPCforCodesys) alle unter dem selben User gestartet sein ?

Für was brauch ich OPCEnum ?


MfG Pete

 

[Power_Pete]

noch ein bild

 

[AutoSPy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Tipps zur OPC-Konfiguration

Müssen die im Taskmanager auftretenden Dienst (OPCEnum, Deltalogic OPC, OPCforCodesys) alle unter dem selben User gestartet sein?

Nein, müssen sie nicht. Der jeweils angezeigte Nutzer muss aber genügend Rechte haben (siehe unten).

Für was brauch ich OPCEnum ?

Dieser Dienst wird zum Browsen von lokal oder remote installierten OPC-Servern benötigt (siehe auch OPC Training Institute). Falls Dein Client die direkte Eingabe von URLs unterstützt und Du die gewünschte Server-URL kennst, brauchst Du den Dienst nicht. Im Allgemeinen arbeitet es sich mit ihm aber komfortabler.

Die meisten Anleitungen zur OPC-Konfiguration öffnen leider den Rechner für Gott und die Welt. Ich habe für uns daher mal eine Konfiguration erarbeitet, die sich nur minimal von der Standard-DCOM-Konfiguration unterscheidet. Hier die wesentlichen Schritte in Kürze.



Auf dem Server:

• ggf. die OPC Redistributables installieren
• DCOM aktivieren
• lokale Benutzergruppe "OPC-Benutzer" o.ä. anlegen und alle lokalen und Domänen-Nutzer eintragen, die Zugriff auf den OPC-Server erhalten sollen (auch lokale Nutzer anderer PCs mit ihren dortigen Passwörtern)
• Eigenschaften von OPCEnum und der benötigten Server bearbeiten:
  • Authentifizierungsebene: Standard
  • Ausführungsort: Anwendung auf diesem Computer ausführen
  • Sicherheit: der Gruppe "OPC-Benutzer" für Start und Zugriff der Komponente alle Rechte einräumen, der Gruppe "Benutzer" einen lesenden Zugriff auf die Konfiguration ermöglichen
  • Endpunkte: unverändert belassen
  • Identität: "Systemkonto" für Dienste wie OPCEnum und sonst als ein lokaler Nutzer der Admininstratoren-Gruppe ausführen
• in der Firewall die OPCEnum.exe, die Executable des OPC-Servers sowie den TCP-Port 135 für DCOM als Ausnahmen eintragen

Auf dem Client:

• ggf. die OPC Redistributables installieren
• den TCP-Port 135 für DCOM als Ausnahme eintragen

Auf die Firewall-Ausnahmen für den DCOM-Port 135 kann meist verzichtet werden (ausprobieren). Mit dieser Konfiguration betreiben wir erfolgreich die OPC-Server von Siemens und Deltalogic bei uns im Netzwerk. Wenn Du bisher bereits sehr viel probiert und verstellt hast, empfehle ich ein Rücksetzen auf einen früheren Wiederherstellungspunkt mit Original-DCOM-Einstellungen.

Viele Grüße,
Jens

 

[erdmann]

Hallo,

es gibt einen fiesen kleinen Unterschied zwischen älteren Windows- Version und
XPSP3 sowie Server 2003. Während bis XPSP2 unter
"lokale Sicherheitsrichtlinie" die Option "Verwendung von Jeder- Berechtigungen für anonyme Benutzer ermöglichen" defaultmäßig aktiviert war, ist diese Option ab XPSP3
defaultmäßig deaktiviert.

Mit dieser Option aktiviert können die Default- DCOM Einstellungen unverändert bleiben und OPC geht sofort.
Ist diese Option deaktiviert, müssen verschiedene Einstellungen recht kräftig geändert
werden.
Es gibt in der Tat die verschiedensten Anleitungen, die unterschiedlichste Einstellungen vorsehen.
Einige vergurken alles und funktionieren trotzdem nicht.


mfg

 

[Power_Pete]

Hm ok,


Wenn die Firewall auf beiden Rechnern deaktiviert ist muss doch bestimmt auch keine Ausnahmen eintragen oder ?

Die Einstellungen der lokalen Sicherheitsrichtlinien sind doch in der Deltalogic Hilfe auch beschrieben, muss nochmal nachsehen aber ich mein ich hab sie wie dort beschrieben wird eingestellt.

 

[Power_Pete]

Zuviel Werbung?
-> Hier kostenlos registrieren

WTF ....


Ich hatte den Deltalogic Server lokal (zu Testzwecken installiert) sowie auf dem remote Rechner. Jetzt ist auf dem lokalen die Demo Laufzeit abgelaufen und ich hab ihn dann deinstalliert. Nach der Deinstallation hatte mein Visualisierungs Client sofort eine remote Verbindung zu dem Server Rechner.... Alles wunderbar....

Testweise hab ich den Server gestoppt und wieder gestartet, Verbindung wieder weg und lässt isch auch nicht wieder verbinden.

 

[AutoSPy]

Wenn die Firewall auf beiden Rechnern deaktiviert ist muss doch bestimmt auch keine Ausnahmen eintragen oder ?

Davon ist auszugehen.

Die Einstellungen der lokalen Sicherheitsrichtlinien sind doch in der Deltalogic Hilfe auch beschrieben, muss nochmal nachsehen aber ich mein ich hab sie wie dort beschrieben wird eingestellt.

So wie ich unseren OPC-Zugriff unter Windows XP SP3 konfiguriert habe (siehe oben), brauche ich weder eine lokale Sicherheitsrichtlinie ändern, noch den Nutzern "Jeder" oder "ANONYMOUS-ANMELDUNG" irgendwelche Rechte für den OPC-Zugriff einräumen. Denn dadurch werden für jedermann alle Tore geöffnet, was ich genau nicht möchte.

Schau doch mal in den Sicherheitsprotokollen von Server- UND Client-PC nach, ob etwas eingetragen wird, wenn Du das Browsen startest. Fehlende Zugriffsrechte oder Firewall-Probleme werden dort schnell sichtbar.

Außerdem würde ich sicherheitshalber noch einen alternativen OPC-Client ausprobieren.

Viele Grüße,
Jens

 

[Power_Pete]

Ja ok,

Denn dadurch werden für jedermann alle Tore geöffnet, was ich genau nicht möchte.

vorerst stört mich es nicht das alle User Zugriff haben, zuerst sollte ich die Verbindung hinbekommen

Schau doch mal in den Sicherheitsprotokollen von Server- UND Client-PC nach, ob etwas eingetragen wird, wenn Du das Browsen startest. Fehlende Zugriffsrechte oder Firewall-Probleme werden dort schnell sichtbar.

hab ich gemacht siehe Anhang... aber das sagt mir jetzt ... was ??? Habs gegoogelt ohne wirklichen Erfolg.

 

[AutoSPy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Falls das die einzigen Einträge zum Zeitpunkt eines Browsing-Versuches in Deinem Sicherheitsprotokoll auf dem Server sind, solltest Du die Überwachungsrichtlinie erweitern (siehe Screenshot), da sonst entscheidende Ereignisse fehlen. Achte insbesondere auf An-/Abmeldungen von Nutzern, um sicherzugehen, dass der Server-PC (Win XP) die Anfrage nicht ablehnt, weil er Deine Anmeldedaten nicht authentifizieren kann.

VG Jens

 

[Dr. OPC]

Auf dem Server:

• ggf. die OPC Redistributables installieren
• DCOM aktivieren
• lokale Benutzergruppe "OPC-Benutzer" o.ä. anlegen und alle lokalen und Domänen-Nutzer eintragen, die Zugriff auf den OPC-Server erhalten sollen (auch lokale Nutzer anderer PCs mit ihren dortigen Passwörtern)
• Eigenschaften von OPCEnum und der benötigten Server bearbeiten:
  • Authentifizierungsebene: Standard
  • Ausführungsort: Anwendung auf diesem Computer ausführen
  • Sicherheit: der Gruppe "OPC-Benutzer" für Start und Zugriff der Komponente alle Rechte einräumen, der Gruppe "Benutzer" einen lesenden Zugriff auf die Konfiguration ermöglichen
  • Endpunkte: unverändert belassen
  • Identität: "Systemkonto" für Dienste wie OPCEnum und sonst als ein lokaler Nutzer der Admininstratoren-Gruppe ausführen
• in der Firewall die OPCEnum.exe, die Executable des OPC-Servers sowie den TCP-Port 135 für DCOM als Ausnahmen eintragen

Dem ist fast nichts hinzuzufügen, genau so stelle ich das auch immer ein, ausser eine kleine Ergänzung noch:
Identität: "Systemkonto" für Dienste wie OPCEnum und sonst als ein lokaler Nutzer (aus der OPC-Gruppe natürlich) oder der Admininstratoren-Gruppe (falls der Admin auch in der OPC-Gruppe ist bzw. Clientseitig bekannt und berechtigt ist) ausführen

Auf dem Client:

• ggf. die OPC Redistributables installieren
• den TCP-Port 135 für DCOM als Ausnahme eintragen

Der Client (oder der Prozess in dem der Client läuft) sollte auch Mitglied in der OPC-Gruppe sein und die OPC Gruppe sollte auch auf dem Client-PC angelegt sein und für den Clientprozess mindestens "remote Access Permissions" besitzen. Sonst können beim OnDataChange die Daten nähmlich nicht "zugestellt" werden, da ruft nähmlich der Server in Richtung des Clients und alles dreht sich rum.

"lokale Sicherheitsrichtlinie" die Option "Verwendung von Jeder- Berechtigungen für anonyme Benutzer ermöglichen" defaultmäßig aktiviert war, ist diese Option ab XPSP3
defaultmäßig deaktiviert.

Das ist tatsächlich eine riesige SICHERHEITSLÜCKE wenn man das so einstellt, das würde ich auf KEINE FALL machen und es ist definitiv nicht nötig.

ABER, bei WinXPSP3 wird tatsächlich eine Sicherheitsoption "verschärft", die man zurückstellen MUSS, sonst geht nichts.
Sicherheitsoptionen->Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für Lokale Konten sollte von "nur Gast" auf "klassisch - lokale Benutzer authentifizieren sich als sie selbst" umgestellt werden, denn sonst wird jeder remote Zugriff auf den Gast-Account "umgeleitet" und der ist defaultmäßig deaktiviert. Gerade nach einer Neuinstallation oder nach Update auf XP-SP3 sollte man diese Einstellung prüfen. Natürlich auf beiden Seiten, Client und Server.

Eine super Checkliste gibt es hier:
http://www.ascolab.com/de/dokumente.html

 

[OPCNews]

Tunneln von DCOM Verbindungen

Hey Leute,

bei der ganzen Firewall-Problematik macht es aus meiner Sicht auch Sinn sich Gedanken darüber zu machen ob man die DCOM-Verbindung nicht am besten tunnelt.

Hier ein paar interessante Tipps zum Thema DCOM-Konfiguration mit OPC:TOOL::

http://www.matrikonopc.de/dcom-configuration-opc.aspx

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

bei der ganzen Firewall-Problematik macht es aus meiner Sicht auch Sinn sich Gedanken darüber zu machen ob man die DCOM-Verbindung nicht am besten tunnelt.

Wenn du die Diskussion genauer gelesen hättest, dann wäre dir aufgefallen, dass die Firewall hier nicht das Problem darstellt, da sie (temporär) abgeschaltet wurde.

Hier geht es darum dass remote auf einen Server zugegriffen werden kann und auf einen anderen (auf der selben Machine) eben nicht. Dies liegt also definitiv an den DCOM Einstellungen und die Probleme können (vor allem in der hier beschriebenen Konfiguration) auch ohne (kostenpflichtige) Tunnel-Software gelöst werden.

 

[repök]

PCS7 Win2003 Server WinCC6.1

Hallo,
ich hab da oben beschriebenes System und möchte nun das WinCC als OPC-Server arbeitet. Als OPC-Client käme dann WinCC7.0 zum Einsatz. Probehalber habe wir dann den Test-Client von Rockwell und den OPC-Scout eingesetzt. Beide bleiben beim Verbindungsaufbau (also dem Start des OPC-Servers von WinCC) hängen. Wir waren zum Zeitpunkt des Tests remote mit dem Win2003-Server verbunden. Liegt das an der Remote-Verbindung?

Und wie sieht die DCOM-Konfiguration unter Win2003-Server aus? Ist die ähnlich wie in XP? Muss da auf was besonderes geachtet werden?

PS: Beide PC's sind in der gleichen Arbeitsgruppe (also keine Domaine).

 

[Dr. OPC]

Der Server ist auch ein WinCC 7.0 nehme ich an. Lokal funktioniert das? Hast du das getestet? WinCC Runtime läuft nehme ich an.

W2k3 und XP sind sich sehr ähnlich, erst bei R2 kam eine Erweiterung für ActiveDirectory dazu, die die Sicherheitseinstellungen verschärft.

Wenn der lokale Zugriff klappt solltest Du zunächst die Checkliste abarbeiten. Kannst du den Fehlercode posten, der beim Connect zurückkommt?

 

[repök]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, der Server ist ein WinCC 6.1. Siemens hat mir dabei versichert das, dass funktioniert.
Fehlercode gibt es keinen. Die Test-Clients bleiben einfach hängen.

 

[Dr. OPC]

Bleibt es auch hängen wenn du es lokal versuchst?

 

[repök]

Das hatten wir noch nicht versucht. das problem ist, ich komme nicht so einfach an den server ran (kundschaft ist da ein bischen unflexibel). ich konnte das bis jetzt nur remote probieren.

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK verstehe, das ist natürlich etwas hinderlich.

Ping auf die Kiste geht aber und antwortet auch?
Die Runtime von WinCC läuft auch?
Der SSC wurde ausgeführt auf der Kiste?

 

[repök]

Tut mir leid, dass ich mich so spät melde. war auf montage.

Ping geht, mit antwort.
wincc läuft.
SSC weiss ich nicht.
Ich nehme mal an, dass SSC ausgeführt wurde. Genau sagen kann ich das nicht.

 

[Dr. OPC]

Das SSC wird normalerweise automatisch direkt von der Installation ausgeführt, nur bei WinCC 6.1 bin ich mir nicht sicher ob das da auch schon so war. Schadet aber nichts wenn du das Ding über das Startmenü noch mal anstartest. Das SSC stellt die Firewall und die DCOM settings (erstmal) so ein wie sie für eine remote Kommunikation benötigt werden.

Weiterhin solltest du prüfen ob der User unter dem der Client läuft auch Mitglied in der "SimaticHMI" Gruppe ist.

Wenn du sagst der hängt, heisst das nach 6 min auch kein Fehler kommt ?