# Dcom



## Power_Pete (29 Juni 2011)

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 Serve*r 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 (29 Juni 2011)

noch ein bild


----------



## AutoSPy (4 Juli 2011)

*Tipps zur OPC-Konfiguration*



Power_Pete schrieb:


> 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).



Power_Pete schrieb:


> 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 (4 Juli 2011)

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 (5 Juli 2011)

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 (5 Juli 2011)

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 (5 Juli 2011)

Power_Pete schrieb:


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


Davon ist auszugehen.



Power_Pete schrieb:


> 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 (5 Juli 2011)

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 (5 Juli 2011)

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 (22 Juli 2011)

> Auf dem Server:
> 
> ggf. die OPC Redistributables installieren
> DCOM aktivieren
> ...


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 (1 August 2011)

*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 (1 August 2011)

> 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 (9 August 2011)

*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 (9 August 2011)

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 (9 August 2011)

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 (9 August 2011)

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


----------



## repök (9 August 2011)

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 (9 August 2011)

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 (15 August 2011)

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 (15 August 2011)

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  ?


----------



## repök (15 August 2011)

Ich weiss nicht ob wir das 6min haben laufen lassen. also das scc werde ich dann mal starten, und weitersehen was passiert. allerdings erst nächste woche.
Gibt es da noch irgendwelche stolpersteine wegen win 2k3 server?

ansonsten werde ich mich sicherlich nochmal melden! danke schonmal


----------



## Joerg_K. (15 Januar 2014)

Hallo,
ich habe auch ein Problem mit der Kommunikation über DCOM.
Ich habe auf einem WIN 7 Rechner den OPC Server von Codesys am laufen und auf einem Server 2008 den Client mit der OPC- Visualisierung. Die Verbindung steht und die Datenpunkte werden eingelesen (Visualisierungsprogramm). Die Variablen werden auch alle angezeigt und die Änderungen der einzelnen Steuerungen werden auch angezeigt. Soweit alles in Ordnung.
Jetzt zum Problem: es wurden ein paar Fehlersituationen simuliert, unteranderem das Trennen der IP Verbindung zwischen OPC Server (Win7) und Client (S2008). Beim erneuten Verbinden werden die Daten nicht mehr aktualisiert. Der OPC Server und das Gateway laufen weiterhin.
Muss der Server erneut gestartet werden? oder gibt es da noch irgendetwas was ich in den Einstellungen vergessen habe.


----------



## Dr. OPC (16 Januar 2014)

Wenn alles funktioniert, dann ist es offensichtlich richtig eingestellt  was DCOM angeht. Wenn nach einem Reboot immer noch alles funktioniert  sollte das also passen. Von der DCOM-Seite her gibt es nur einen Punkt  den man oft vergisst: einige OPC Server verwenden als Rechte-Kontext den  "Interaktiven Benutzer", das ist also der, der gerage eingeloggt ist.  Wenn man also DCOM richtig und funktionsfähig eingestellt hat, muss man  in diesem Fall sicherstellen, dass immer der selbe Benutzer eingeloggt  wird. Das klappt in der Praxis oft nicht. Daher würde ich immer dem  Server eine feste "Identität" zuweisen (DCOM-Einstellungen, letzte  Lasche).

Zurück zu Deinem Problem. Ich glaube nicht dass es mit  DCOM zu tun hat, denn nur durch das "Trennen" der Verbindung (also z.B.  Kabel ziehen) ändern sich ja die Rechte nicht und auch nicht der Kontext  in dem die Anwendungen laufen. Ich vermute ein Problem im Client,  dieser sollte einen "automatischen re-connect" machen. Ob das überhaupt  passiert solltest Du prüfen. Der Client muss komplett von vorne  anfangen, vermutlich ruft er in seinem "re-connect" nicht genauso wie beim initialen Connect. Der Server seinerseits muss auch erkennen dass die Verbindung unterbrochen ist und die entsprechenden Ressourcen freigeben. Funktioniert es denn wenn du "nur" den Prozess des Server neu startest?


----------



## Joerg_K. (17 Januar 2014)

Hallo Dr. OPC
Die Nutzer sind bei beiden Rechner gleich, also kein "interaktiver oder Nutzer der die Anwendung startet", sondern der Nutzer ist mit Anmeldung und PW eingetragen.
Ich  habe den Client auf dem Server 2008 neugestartet,danach wurden die Daten wieder aktualisiert. Ich sollte noch erwähnen, dass auf beiden Rechnern der OPC Server von Codesys installiert ist. (siehe Anleitung WAGO).Deshalb müsste doch der Client erkennen,das die IP Verbindung gestört ist, in diesem Fall das Trennen der LAN Kabels.
Des weiteren ist mir aufgefallen, das beim Gateway mehrere Kanäle (2) aktiv waren, welche einen Zeitstempel besitzen, der jeweils mit dem Start der OPC Verbindung identisch ist.


----------

