VonDoczuDoc.de

Ich bitte um einen Rat :
Ich bin dabei, einen neuen Server ( Dell Power edge 2800) mit Windows SBS 2003 einzurichten.

Nach Installation von Turbomed als Einzelplatzversion scheitert der Versuch, den Poet Server als Dienst einzurichten.



Beim Aufruf des Poeten ptserv32.exe folgt die Fehlermeldung von Windows :


Could not listen on poet/tcp : the adress specified in use or another server already running ( -2532)


Wie kann das umgangen warden. ?

Unter Windows 2000 Server gibt es diese Fehlermeldung nicht

Gruß D.Sasse

Auf einem SBS Server werden unter anderem auch die exchange dienste mit gestartet. die exchange dienste grabben sich den port, den der poet braucht. also entweder exchange deaktivieren, oder die dienstabhängigkeiten so konfigurieren, dass der poet VOR exchange startet, dann gehts wieder.

GRÜSSE,

ein Freund.

Anonymous hat geschrieben:Auf einem SBS Server werden unter anderem auch die exchange dienste mit gestartet. die exchange dienste grabben sich den port, den der poet braucht. also entweder exchange deaktivieren, oder die dienstabhängigkeiten so konfigurieren, dass der poet VOR exchange startet, dann gehts wieder.

GRÜSSE,

ein Freund.

hat geklappt, herzlichen Dank

Ich habe ebenfalls den genannten Fehler dadurch gelöst, dass ich in der Registry per Eintrag den FastObeject Server als Dienst vor einer Exchange Server Anwendung starten lasse.

Jetzt habe ich allerdings folgendes Problem:
Seit Wochen versuche ich auch mit Unterstützung einen Remote Zugang zu Outlook via RPC over HTTP zu konfigurieren. Alle Einstellungen scheinen zu stimmen. Hat jemand evt. ein ähnliches Problem erlebt. Bei mit kommt Outlook bei der Einwahl in den Exchange-Server zum Stillstand. Offensichtlich vertragen sich der Exchange Server (RPC-Proxy) und der ptserv32 nicht miteinander, beide greifen übrigens mit TCP auf Port 6001 und 6002 zu.

Vielleicht kann mir jemand mitteilen ob es dazu reproduzierbare Erfahrungen gibt und evt. eine bestimmte Startreihenfolge von Fast-Object-Server und Exchange-Server-Komponenten das Problem löst.

Bin für jede Hilfe sehr dankbar.

Heureka!

Wie vermutet liegt ein grundlegendes Problem zwischen einer Exchange-Server-Komponente (MS Exchange SA) und dem FastObjects Server vor. Beide greifen sinnigerweise auf die Ports 6001 und 6002 zu. Und nur wer zuerst kommt darf ihn nutzen.

Also wer den ptserv32.exe als Dienst vor den Exchange-Server Komponenten installiert beraubt sich der Fähigkeit seines Exchange-Servers und umgekehrt.

Beim Exchange Server werden für den RPC-Proxyserver die beiden Ports benötigt. Wer nicht weis wofür RPC benötigt wird: RPC over HTTP stellt eine Tunnelung der Exchange-Daten für Outlook-2003-Clients außerhalb über das Internet (via HTTP oder besser HTTPS) zur Verfügung. Und der Witz ist - denn hier liegt auch der von mir genutzte Pfad zur Lösung des Problems, der RPC-Proxy Server ist lediglich intern tätig. Holt sich über die Ports 6001, 6002 und 6004 die Informationen vom Exchange-Server ab und leidet dann die Informationen über die üblichen Webserverports 80 (für http://) und besser und sicherer über 443 (für https://) nach außen. Das heißt die Ports 6001 und 6002 werden nicht für den Zugriff von außen benötigt und können verstellt werden.

Dies habe ich getan: auf 6011 statt 6001 und auf 6012 statt 6002. Und zwar an folgender Stelle des Exchange-Servers:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Name: Rpc/HTTP Port
Typ: REG_DWORD
Wert: 0x1771 (dezimal 6001)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Name: HTTP Port
Typ: REG_DWORD
Wert: 0x1772 (dezimal 6002)

Sowie den RPC-Proxy an folgender Stelle der Registry verstellen (beides über Start/Ausführen: regedt32) - auf 6011-6012 statt 6001-6002:

Gehen Sie hierzu folgendermaßen vor: 1. Starten Sie auf dem Proxyserver den Registrierungseditor.

Achtung: Die unkorrekte Verwendung des Registrierungseditors kann schwerwiegende Probleme verursachen, die das gesamte System betreffen und eine Neuinstallierung des Betriebssystems erforderlich machen. Microsoft kann nicht garantieren, dass Probleme, die von einer falschen Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie den Registrierungseditor auf eigene Verantwortung.
2. Klicken Sie auf den folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy
3. Klicken Sie mit der rechten Maustaste auf ValidPorts, und klicken Sie auf Ändern.
4. Meist sind hier bereits die korrekten Daten eingetragen und nur die Ports müssen angepasst werden
NETBIOS-Name des Servers:6001-6002;FQDN des Servers:6001-6002;NETBIOS-Name des Servers:6004;FQDN des Servers:6004


Danach sind die Ports 6001 und 6002 für den ptserv32.exe frei und TurboMed kann ohne Probleme auf einem SBS 2003 Server installiert werden. Da ein solcher Server als OEM ca. 400 Euro (inkl. 5 Lizenzen) kostet eine hochwertige und kostengünstige Lösung für eine weltweite Erreichbarkeit der eigenen Daten.

Die Neuportierung hat bisher keinerlei weitere Probleme nach sich gezogen. SBS 2003 läuft ohne jede Fehlermeldung, das Feature RPCoverHTTP steht zur Verfügung. Endlich! Bin für weitere Informationen und Vorschläge jederzeit offen.

Dazu empfehle ich folgende Dokumente:
http://support.microsoft.com/kb/833401/de
Die Installationsanleitung des Microsoft-Support über RPC über HTTP.

Vielen Dank an meddoc für diese immer noch aktuellen Tips!
Installation auf einem WHS 2008 R2 (basiert auf SBS 2003) hing genau an dieser Stelle. Lebenswichtige Exchange-Dienste von einer TM-Testinstallation abhängig zu machen war keine Option, also die Ports in der Registrierung angepasst. Dabei fiel mir aber auf, dass im Abschnitt:

Sowie den RPC-Proxy an folgender Stelle der Registry verstellen (beides über Start/Ausführen: regedt32) - auf 6011-6012 statt 6001-6002:

Gehen Sie hierzu folgendermaßen vor: 1. Starten Sie auf dem Proxyserver den Registrierungseditor.

Achtung: Die unkorrekte Verwendung des Registrierungseditors kann schwerwiegende Probleme verursachen, die das gesamte System betreffen und eine Neuinstallierung des Betriebssystems erforderlich machen. Microsoft kann nicht garantieren, dass Probleme, die von einer falschen Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie den Registrierungseditor auf eigene Verantwortung.
2. Klicken Sie auf den folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy
3. Klicken Sie mit der rechten Maustaste auf ValidPorts, und klicken Sie auf Ändern.
4. Meist sind hier bereits die korrekten Daten eingetragen und nur die Ports müssen angepasst werden
NETBIOS-Name des Servers:6001-6002;FQDN des Servers:6001-6002;NETBIOS-Name des Servers:6004;FQDN des Servers:6004

unter Punkt 4 die Angabe missverständlich ist: 6001-6002 muss ersetzt werden durch 6011-6012 um den RPC-Proxy umzuleiten.

Warum TM bei solch einem Fehler nach Jahren nicht mal die Ports anpasst, ist mir aber mehr als schleierhaft...

Resultat: TM läuft auf einem Domaincontroller mit Exchange bisher ohne Fehler.

Nochmal ein DICKES Lob für dieses nützliche Forum!

Gruß
itsol

meddoc hat geschrieben:Heureka!

Wie vermutet liegt ein grundlegendes Problem zwischen einer Exchange-Server-Komponente (MS Exchange SA) und dem FastObjects Server vor. Beide greifen sinnigerweise auf die Ports 6001 und 6002 zu. Und nur wer zuerst kommt darf ihn nutzen.

Also wer den ptserv32.exe als Dienst vor den Exchange-Server Komponenten installiert beraubt sich der Fähigkeit seines Exchange-Servers und umgekehrt.

Beim Exchange Server werden für den RPC-Proxyserver die beiden Ports benötigt. Wer nicht weis wofür RPC benötigt wird: RPC over HTTP stellt eine Tunnelung der Exchange-Daten für Outlook-2003-Clients außerhalb über das Internet (via HTTP oder besser HTTPS) zur Verfügung. Und der Witz ist - denn hier liegt auch der von mir genutzte Pfad zur Lösung des Problems, der RPC-Proxy Server ist lediglich intern tätig. Holt sich über die Ports 6001, 6002 und 6004 die Informationen vom Exchange-Server ab und leidet dann die Informationen über die üblichen Webserverports 80 (für http://) und besser und sicherer über 443 (für https://) nach außen. Das heißt die Ports 6001 und 6002 werden nicht für den Zugriff von außen benötigt und können verstellt werden.

Dies habe ich getan: auf 6011 statt 6001 und auf 6012 statt 6002. Und zwar an folgender Stelle des Exchange-Servers:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Name: Rpc/HTTP Port
Typ: REG_DWORD
Wert: 0x1771 (dezimal 6001)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Name: HTTP Port
Typ: REG_DWORD
Wert: 0x1772 (dezimal 6002)

Sowie den RPC-Proxy an folgender Stelle der Registry verstellen (beides über Start/Ausführen: regedt32) - auf 6011-6012 statt 6001-6002:

Gehen Sie hierzu folgendermaßen vor: 1. Starten Sie auf dem Proxyserver den Registrierungseditor.

Achtung: Die unkorrekte Verwendung des Registrierungseditors kann schwerwiegende Probleme verursachen, die das gesamte System betreffen und eine Neuinstallierung des Betriebssystems erforderlich machen. Microsoft kann nicht garantieren, dass Probleme, die von einer falschen Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie den Registrierungseditor auf eigene Verantwortung.
2. Klicken Sie auf den folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy
3. Klicken Sie mit der rechten Maustaste auf ValidPorts, und klicken Sie auf Ändern.
4. Meist sind hier bereits die korrekten Daten eingetragen und nur die Ports müssen angepasst werden
NETBIOS-Name des Servers:6001-6002;FQDN des Servers:6001-6002;NETBIOS-Name des Servers:6004;FQDN des Servers:6004


Danach sind die Ports 6001 und 6002 für den ptserv32.exe frei und TurboMed kann ohne Probleme auf einem SBS 2003 Server installiert werden. Da ein solcher Server als OEM ca. 400 Euro (inkl. 5 Lizenzen) kostet eine hochwertige und kostengünstige Lösung für eine weltweite Erreichbarkeit der eigenen Daten.

Die Neuportierung hat bisher keinerlei weitere Probleme nach sich gezogen. SBS 2003 läuft ohne jede Fehlermeldung, das Feature RPCoverHTTP steht zur Verfügung. Endlich! Bin für weitere Informationen und Vorschläge jederzeit offen.

Dazu empfehle ich folgende Dokumente:
http://support.microsoft.com/kb/833401/de
Die Installationsanleitung des Microsoft-Support über RPC über HTTP.

Diese Anleitung habe ich punktgenau befolgt, allerdings klappt das leider nicht unter Windows 2011. Die RPC Ports werden bei jedem Start wieder zurückgeschrieben. Hat vielleicht noch jmd. einen Tipp?

Ich denke, Sie meinen den SBS2011 Standard mit integriertem Exchange. Den kann man noch kaufen. Ich wollte eigentlich auch diese Lösung, vor allem weil der Server für dieses Betriebssystem zertifiziert ist. Nach allen möglichen Versuchen vom Umkonfigurieren des SBS 2011 bis hin zum Kontakt der Poet-Entwickler kann ich Ihnen nur raten: Vergessen Sie's. Warum?
1. Den Poet bekommen Sie nicht auf andere Ports umgelenkt (beim Server vielleicht - aber nicht bei den Clients!);
2. Das neue Exchange nutzt im Vergleich zu der Version 2003 soviel Verkehr über die internen Ports, dass Sie diesen Verkehr mit den von damals bekannten Mitteln nicht mehr auf andere Ports umlenken können. Im Unterschied zu damals werden gleich Port-Gruppen reserviert und es werden abhängige Dienste gestartet, die dann auch die Portgruppen benutzen. Wenn man an diesen Stellen versucht zu schrauben, riskiert man die Performance des Gesamtsystems.

Leider gibt es den SBS 2011 Essentials nicht mehr. Das wäre auf W7-Basis die brauchbare und preiswerte Alternative. Ich habe mir den Server 2012 R2 Essentials als Testversion (läuft 180 Tage legal) von MS gezogen. Läuft etwa seit Anfang des Jahres auch mit aktueller Server-Hardware prima (ist mittlerweile auch von den Herstellern zertifiziert) und ist außerdem in meinen Augen preiswert. Funktioniert mit W7-Clients, TM und IfAP performant und wird demnächst aus dem Test- in den Produktivbetrieb übernommen.

Falls jemand von Turbomed mitliest: es wäre schön, wenn Turbomed Server 2012 R2 Essentials möglichst bald auch in die Liste der zugelassenen Server-Betriebssysteme aufnehmen würde. Momentan stehen da nur 2012 Standard und 2012 Foundation. Ich finde die 2012 R2 Essentials-Variante als die derzeit beste Lösung für eine Praxis mit extra Server-Rechner.

Viele Grüße vom Igel