lukin

Hallo!

Gibt es eigentlich die Möglichleit, sich irgendwo alle neu erscheinenden KB-Artikel auflisten zu lassen, beispielweise wie in einem RSS Feed?

Bei den von Microsoft angebotenen Feeds habe ich das leider nicht finden können und auch sonst war meine Suche bislang erfolglos.

Das wäre aber hilfreich, denn so könnte man sich immer über neu bekannt gewordene Probleme (und evtl. deren Lösungen) informieren.

Gibt es da etwas von Microsoft?

Danke, Michael

Und was ist, wenn du dich mit dem aktivierten Userkonto aus dem Account-Forest anmeldest, erhältst Du dann auch eine Fehlermeldung?

 

Christoph

Ja. Genau dieselbe. Hatte ich oben schon geschrieben. Allerdings habe ich mich da wohl etwas unklar ausgedrückt, weil ich unmittlbar darunter geschrieben hatte, dass der Mailboxbesitzer deaktiviert ist. Aber das bezieht sich natürlich auf die Anmeldung in der Domäne, die Exchange provided.

Hi,

gesetzt den Fall, es existieren zwei AD Gesamtstrukturen, von denen eine als Exchange Resource Forest für die andere Gesamtstruktur dient.

Dort ist es bekanntermaßen so, dass zwischen beiden Gesamtstrukturen eine Vertrauensstellung existiert und der Mailbox-Besitzer im Exchange Resource Forest mit dem realen Benutzer in der anderen Gesamtstruktur verknüpft ist. Der Mailbox-Besitzer im Exchange-Resource Forest wird deaktiviert.

Mit Outlook 2003 klappt das alles wunderbar. Nur was ist, wenn ich mit Outlook WebAccess auf so eine verknüpfte Mailbox zugreifen möchte?

Wenn ich in der OWA-Anmeldung ein entsprechendes Konto (mit FQDN) der anderen Gesamtstruktur anmelde, erhalte ich jedes Mal:

Die Anmeldung bei Outlook Web Access ist fehlgeschlagen.

Überprüfen Sie Ihre Domäne, Ihren Benutzernamen und Ihr

Kennwort, und versuchen Sie es dann erneut

Das ist im Prinzip auch logisch, weil der Mailboxbesitzer deaktiviert ist.

Können in einem Exchange Resource Forest liegende Konten von den anderen Gesamtstrukturen nur mit Outlook 2003 genutzt werden? Oder gibt es auch einen Weg, Benutzern in der anderen Gesamtstruktur OWA zugänglich zu machen?

Bei der Umgebung handelt es sich um Windows Server 2003 SP1 / Exchange 2003 SP2.

Hallo,

ich möchte erreichen, dass ich beim Auftreten bestimmter Ereignisse im

Event-Log eine Nachricht per E-Mail erhalte, was mit Eventtriggers und

dem Kommandozeilen E-Mail-Programm "Blat" auch prinzipiell klappt.

Es gibt dabei allerdings keine Möglichkeit, mir auch Informationen wie

z.B. die Beschreibung des eingetretenden Events zukommen zu lassen.

Ich könnte höchstens das Tool "dumpel" einsetzen, um Einträge aus dem

Eventlog in eine Datei zu schreiben, die mir dann anschließend mit Blat

zugesandt werden kann.

Das Problem ist aber, dass dumpel dabei *alle* Einträge des Tages dieser

ID in die Datei schreibt -- und nicht wie gewünscht, nur den aktuellen.

Zu schade, dass Eventtriggers nicht selbst eine Datei mit der aktuellen

Ereignisbeschreibung erstellen kann...

Am liebsten hätte ich jedenfalls folgende Lösung:

Bei Eintritt z.B. eines Error-Ereignisses wird das Event mit Description

in eine Datei geschrieben und mir dann zugeschickt (z.B. per Blat).

Gibt es da eine Möglichkeit?

--

rgds, Michael

Hallo,

Das Buch von Microsoft (http://tinyurl.com/8vvmu) sieht ja schon mal gut aus, da es W-LAN und Radius in einem behandelt.

Kann mir noch jemand andere Bücher wie z.B. http://tinyurl.com/aoaew empfehlen?

Gruß, Michael

Hallo,

wir haben hier noch einen ISA 2000, der erst mal auch noch eine Weile bleiben soll. Ab und an muss ich aber doch was dran machen und würde mir deshalb noch ein gutes Buch dazu kaufen. Könnt ihr mir da was empfehlen?

Interessant schaut das hier aus:

http://www.amazon.de/exec/obidos/redirect?link_code=ur2&camp=1638&tag=mcseboardde-21&creative=6742&path=ASIN%2F3826609964

Gruß, Michael

Hi,

danke für die Tipps. Das Buch werde ich mir mal bestellen. Wenn noch jemand andere Bücher zu dem Thema kennt, immer her damit!

Gruß, Michael

Das ist ein komplexes Thema - kennt jemand ein gutes Buch, um sich in das Thema einzuarbeiten?

Ich kann Entwarnung geben. Bisher kannte ich von Microsoft nur das Whitepaper mit den Deployment Scenarios. Ich weiss nicht, ob die technischen Details erst seit der Ueberarbeitung des Artikels vom 02.06.2005 dort stehen, jedenfalls steht hier alles noch mal gut erklaert:

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc.mspx

Das beantwortet nun endgueltig alle Fragen zum Thema RPC over HTTP. Ich wuerde mich auf jeden Fall an diese Informationen halten. Scheinbar basieren viele Artikel im Internet auf falschen Informationen.

Gruss, Michael

Ich verstehe nicht, wie die Verbindung ohne die Angabe des Globalen

Katalog-Servers in "Value Ports" ueberhaupt funktionieren kann - der

RPC Proxy duerfte doch von Port 6004 auf dem GC so gar nix wissen.

Gerade deshalb macht man ja die Eintraege in "Value Ports", naemlich

damit der RPC Proxy weiss, wo er die Dienste finden kann.

Wenn ich bei mir in Outlook den Verbindungsstatus ansehe, ist unter

Verzeichnisdienst auch mein Exchange-Server und _nicht_ der Globale

Katalog-Server zu sehen - obwohl der Exchange-Server ja gar keinen

globalen Katalog respektive Verzeichnisdienst fuehrt.

Ach, noch was:

Warum ist auf dem Exchange Server der Port 6004 ebenfalls fuer NSPI

registriert und warum muss er unter "Value Ports" angegeben werden?

Ich denke, NSPI ist die Schnittstelle zum Globalen Katalog, weshalb

man Port 6004 ja auch durch ncacn_http:6004 auf dem Globalen Katalog

Server fixieren muss.

Freundliche Gruesse, Michael

Hallo,

ich beschaeftige mich nun schon seit einiger Zeit mit RPC over HTTP.

Funktionieren tut es einwandrei - aber ich habe noch ein paar Fragen,

die mir bis jetzt kein Beitrag und keine Dokumentation beantworten

konnte und die bei mir fuer reichlich Unklarheit sorgen.

Ich beschreibe in diesem Beitrag meine funktionierende Konfiguration -

in der Hoffnung, dass selbst das schon jemandem bei der Einrichtung

weiterhilft. Der Beitrag ist relativ lang - ich hoffe trotzdem, dass

sich ein schlauer Fuchs erbarmt und mir meine Fragen beantworten kann.

Erst mal zu meinem Szenario. Ich betreibe drei Domaenencontroller, von

denen zwei den Globalen Katalog fuehren. Exchange 2003 SP1 laeuft auf

einem Memberserver und ist gleichzeitig der RPC Proxy:

----------- ----------- -----------

AD1 (DC+GC) AD2 (DC) AD3 (DC+GC)

----------- ----------- -----------

-----------------

EX2K3 (RPC Proxy)

-----------------

Wie in zahlreichen Dokumentationen beschrieben, habe ich auf dem RPC

Proxy das virtuelle Verzeichnis im IIS-Snap-In entsprechend

konfiguriert und im Exchange System Manager den Exchange Server als

Ziel fuer den RPC Proxy angegeben (als Backend-Server).

Danach habe ich die Einstellungen in der Registrierung angepasst. Und

dazu habe ich auch gleich ein paar Fragen.

Erst einmal muessen auf dem RPC Proxy die Ports der Dienste angegeben

werden, mit denen der RPC Proxy kommunizieren soll. Da diese Dienste

standardmaessig ueber dynamische Ports erreichbar sind, registriert

Exchange fuer die Verwendung von RPC over HTTP dafuer feste Ports.

Dabei handelt es sich um folgende Dienste auf dem Exchange-Server:

Information Store: Port 6001

System Attendant: Port 6002

Referral (RFR) service: Port 6002

NSPI (Name Service Provider Interface): Port 6004

Die Adressen dieser Dienste muessen in der Registrierung des RPC

Proxy-Servers an folgender Stelle explizit angegeben werden:

Schluessel: HKLM | Software | Microsoft | RPC | RPCProxy

Wert: ValidPorts

Typ: Reg_SZ

Das Format der Eintraege lautet dabei wie folgt:

<server_name>:<port_number>, zum Beispiel ex2k3:6001

Dabei benoetigt jeder Port bzw. Dienst seinen eigenen Eintrag, und das

jeweils sowohl mit NetBIOS Namen des Servers sowie mit dem FQDN des

Servers. In meinem Fall lauten die Eintraege dann wie folgt:

ex2k3:6001-6002;ex2k3.active-directory.dom:6001-6002;ex2k3:6004,

ex2k3.active-directory.intern:6004

Soweit, so gut.

Weil seit Exchange 2000 das Active Directory als Verzeichnis benutzt

wird, kontaktiert Outlook fuer Adresslisten nicht mehr Exchange,

sondern direkt das NSPI Interface auf einem Globalen Katalog Server.

Da NSPI standardmaessig ebenfalls einen dynamischen Port benutzt, muss

auch hier wieder fuer den RPC Proxy ein fester Port konfiguriert

werden. Das geschieht durch folgenden Eintrag in der Registrierung auf

dem/den Globalen Katalog Server/n:

Schluessel: HKLM | System | CurrentControlSet | Services | NTDS |

Parameters

Wert: NSPI Interface Protocol Sequence

Typ: Reg_Multi_SZ (multi-string)

Angegeben werden muss folgender Eintrag: ncacn_http:6004

Damit ist das NSPI Interface auf dem/den Globalen Katalog Server/n

fuer den RPC Proxy auf TCP Port 6004 erreichbar.

So. Genau diese Konfiguration habe ich gemacht - und es funktioniert

alles einwandfrei (auf die SSL Konfiguration gehe ich hier nicht ein).

Jetzt zu meinen Fragen:

Wie oben beschrieben, muss auf den Globalen Katalog-Servern ein fester

Port fuer NSPI registriert werden, damit der RPC Proxy darauf

zugreifen kann.

Warum muss ich diesen Port auf dem RPC Proxy unter "Value Ports" nicht

mit angeben? Bei mir funktioniert es auch ohne die Angabe des Globalen

Katalog-Servers in der Registrierung.

Auf einigen Seiten steht, dass man ihn unbedingt angeben muss, auf

anderen Webseiten hingegen ist davon ueberhaupt nichts zu lesen.

Vielleicht ist das ein guter Ausgangspunkt für dich.

 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/rpc_over_http_security.asp

Danke. Das werde ich mir noch mal angucken. Übrigens steht die Konfiguration des Schlüssels ValidPorts hier noch mal anders beschrieben:

http://www.outlookexchange.com/articles/HenrikWalther/RPC_over_HTTP.asp

Das ist ja echt ein sehr verwirrendes Thema. In der Anleitung oben steht wieder mal drin, dass da der Global Catalog mit rein muss. Und noche ein paar andere Ports, auf die ich mir im Moment gar keinen Reim machen kann...

Ist diese Verwirr-Taktik gewollt oder liegt das jetzt nur an mir? Andere Dinge sind da aber besser beschrieben, finde ich. Das ist alles ganz schön undurchsichtig.

So, ich habe es jetzt hinbekommen. Allerdings wuerde ich mich ueber

ein bisschen Nachilfe freuen, um zu verstehen, warum das erst jetzt

funktioniert.

Also. Unter HKLM\SOFTWARE\Microsoft\Rpc\RpcProxy befindet sich der

Eintrag "ValidPorts", der den Ort folgender Dienste enthaelt:

6001 Store

6002 DSReferral

6004 DSProxy

Die Dienste laufen alle auf dem Exchange-Server und werden schon mit

dem Exchange-Setup eingerichtet. Mit dem Eintrag "ValidPorts" teilt

man dem RPC over HTTP Proxy also sozusagen mit, wo sich diese Dienste

befinden.

Ich war nun durch verschiedene Aussagen in diversen Anleitungen aber

etwas verwirrt.

Da ich auf http://www.petri.co.il gelesen hatte, dass man auf allen

Global Catalog Servern einen bestimmten Port fuer den RPC over HTTP

Verzeichnisdienst angeben muss, naemlich mit dem Key ncacn_http:6004

im Schluessel HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters,

dachte ich, ich muss im Key ValidPorts auf dem RPC Proxy den Port 6004

direkt mit dem Global Catalog Server angeben. Dementsprechend war das

mein Eintrag unter ValidPorts:

ExchangeNetBIOS-Name:6001-6002; ExchangeFQDN:6001-6002;

GlobalCatalogNetBIOS-Name:6004; GlobalCatalogFQDN:6004

Da ich ja mit dem Key ncacn_http:6004 auf dem Global Catalog Server

definiert hatte, dass Anfragen vom RPC over HTTP Verzeichnisdienst an

Port 6004 angenommen werden, dachte ich, das muesste eben so klappen.

So ist das ausserdem auch auf http://www.tacteam.net nachzulesen.

Allerdings habe ich mich damit getaeuscht. Die Verbindung zu E-Mail

klappte zwar mit HTTPS, die Verbindung zum Verzeichnisdienst jedoch

nur ueber TCP/IP.

Ich habe dann im Key ValidPorts einfach mal den Port 6004 mit dem

Exchange-Server angegeben. Also so:

ExchangeNetBIOS-Name:6001-6002; ExchangeFQDN:6001-6002;

ExchangeNetBIOS-Name:6004; ExchangeFQDN:6004

Damit hat es dann sofort funktioniert. Nur leider bin ich jetzt ein

bisschen verwirrt, nach der ganzen Geschichte. Kann mir vielleicht

jemand erklaeren, was es mit diesen Registrierungeintraegen genau auf

sich hat?

Ich verstehe zwar, dass man dem RPC over HTTP Proxy mit dem Key

ValidPorts mitteilt, wo er die Diense auffinden kann. Die Verbindung

zum Global Catalog und der Eintrag ncacn_http:6004 auf demselben

sorgen bei mir dann allerdings fuer etwas Verwirrung. Und was genau

sind ueberhaupt die die Dienste DSReferral und DSProxy? Ueber eine

Erklaerung dazu waere ich wirklich sehr dankbar! Wenn jemand eine

Quelle kennt, wo ich das nachlesen kann, waere ich ebenso dankbar!

Ich wuerde so gerne verstehen, was ich da gerade gemacht habe...

Freundliche Gruesse, Michael

Hallo,

ich habe noch mal eine Frage zu den Eintragen in der Registrierung.

Auf http://www.petri.co.il'>http://www.petri.co.il steht, dass man den RPC over HTTP Proxy zur Benutzung von spezifischen Ports konfigurieren muss. Dazu muessen in dem Schluessel

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy

folgende Eintragungen gemacht werden:

ServerNETBIOSName:6001-6002;ServerFQDN:6001-6002;ServerNetBIOSName:6004;ServerFQDN:6004

In einem Artikel auf http://www.tacteam.net,'>http://www.tacteam.net, in dem ein Szenario mit Front- und Backend-Server behandelt wird, steht, dass mit diesen Eintraegen der Exchange Backend-Server angegeben wird. Der Backend Server scheint dann also ueber die Ports 6001-6004 fuer den RPC over HTTP Proxy erreichbar zu sein. Habe ich das richtig verstanden?

Ebenfalls ist auf http://www.tacteam.net beschrieben, dass in diesem Schluessel auch der Name und Port des Global Catalog-Servers angegeben muss (jedenfalls, wenn nicht alles auf einem Server laeuft). Auf http://www.petri.co.il steht dazu, dass man allen Global Catlog Servern sagen muss, welchen Port sie fuer RPC over HTTP nehmen sollen. Das waere dann der Eintrag

ncacn_http:6004

im Schluessel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters auf dem GC-Server.

Demnach waere es dann so, dass Zugriffe auf den GC durch den RPC over HTTP Proxy auf Port 6004 statt finden wuerden und nicht auf dem Standard Port 3268. Also muesste ich auf dem RPC over HTTP Proxy tatsaechlich den GC mit dem Port 6004 angeben und nicht mit dem Standard-Port 3268. Stimmt das?

Ueber ein bisschen Hilfe waere ich dankbar!

Gruss,

Michael

wenn jemand noch andere Ideen hat, mir fällt sonst nix mehr dazu ein. Sorry!

Trotzdem danke, ich werde mich damit am Wochenende dann noch mal etwas genauer damit befassen.

Hallo,

Wie hast du genau das Outlook Profil für RPC over HTTP konfiguriert?

so wie oben beschrieben:

Anlegen des Outlook Profils. Dort habe ich in den Eigenschaften den

FQDN des Exchange-Servers eingegeben (den internen, da ich das erst nur

intern teste) und die Standardauthentifizierung aktiviert. Ausserdem

habe ich die Einstellung aktiviert, dass auch bei einer schnellen

Verbindung erst HTTP benutzt werden soll. SSL habe ich deaktiviert, da

ich noch kein Zertifikat erstellt habe.

mehr kann man da ja auch nicht einstellen.

Hi,

Alle Clients müssen Outlook 2003 und Windows XP SP1 oder neuer nutzen mit dem Patch 331320, damit s funktioniert.

danke. Aber ich habe mich oben nur verschrieben - es muss SP2 lauten.

Gruß,

Michael

Hallo,

ich kaempfe momentan ein bisschen mit der Einrichtung von RPC over HTTP.

Fuer meine Testzwecke habe ich mir folgendes Szenario aufgestellt:

1x Windows Server 2003 SP1 als DC mit GC

1x Windows Server 2003 SP1 mit Exchange 2003 SP1

1x Windows XP SP2 Workstation mit Outlook 2003 SP1

Da es in diesem Szenario keinen Front-End-Server gibt, bin ich nach

folgender Anleitung vorgegangen:

http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3RPCHTTPDep/48d6d03d-64c2-470f-9561-6de9003effe4.mspx

Im einzelnen habe ich dabei folgende Schritte durchgefuehrt:

1. Installation des RPC over HTTP Proxys auf dem Exchange-Server

2. Konfiguration des Exchange-Servers als RPC over HTTP Backend-Server

(Konfiguration ist gut, ein Haekchen wars)

3. Konfiguration des virtuellen Verzeichnisses RPC im IIS (Deaktivierung

des anonymen Zugriffs sowie Aktivierung von NTLM- sowie

Standardauthentifizierung)

4. Konfiguration des Proxy Servers zur Nutzung spezifizierter Ports (die

6001-6002 und 6004 fuer den Exchange Server mit NetBIOS sowie Namen

sowie FQDN)

5. Anlegen des Outlook Profils. Dort habe ich in den Eigenschaften den

FQDN des Exchange-Servers eingegeben (den internen, da ich das erst nur

intern teste) und die Standardauthentifizierung aktiviert. Ausserdem

habe ich die Einstellung aktiviert, dass auch bei einer schnellen

Verbindung erst HTTP benutzt werden soll. SSL habe ich deaktiviert, da

ich noch kein Zertifikat erstellt habe.

Wenn ich nun Outlook mit diesem Profil starte, werde ich aufgefordert,

Benutzername und Kennwort einzugeben. Danach kann ich auf mein Postfach

zugreifen - aber leider nicht ueber HTTP. In den

Verbindungseigenschaften steht nur TCP/IP als Verbindung (Wobei ich

TCP/IP da ein bisschen komisch zu lesen finde, da sollte lieber RPC

stehen wie ich finde).

Hat jemand eine Ahnung, was ich falsch gemacht haben koennte?

Freundliche Gruesse,

Michael

PS: In einigen Beitraegen habe ich gelesen, dass man mit Exchange SP1

die Konfiguration des Proxy Servers zur Nutzung spezifizierter Ports gar

nicht mehr in der Registrierung durchfueheren muss - angeblich kann man

die Ports auch irgendwo im System Manager eintragen. Ich frag mich nur,

wo das sein kann - ich hab's nicht gefunden.

Hallo,

ich habe schon einiges gelesen, aber leider immer noch keine Antwort auf meine Frage gefunden:

Wenn ein Notebookbenutzer mit einem servergespeicherten Profil sich offline an der Domaene anmeldet, erscheint der Hinweis, dass das servergespeicherte Profil nicht gefunden werden kann und stattdessen die lokale Kopie geladen wird.

Das merkwuerdige ist, dass diese Meldung bei einigen Benutzern erscheint, bei anderen wiederum kommt diese Meldung nicht. Ist dieses Verhalten bekannt, oder gibt es eine Einstellung, diese Meldung sauber zu umgehen?

Zuerst dachte ich ja, es laege an einer Gruppenrichtlinie: Beim Notebook, das bei der Offlineanmeldung keine Meldung zeigt, war naemlich die Option fuer das schnelle Anmelden deaktiviert. Aha dachte ich, das wird's sein. Windows muss vorher die Netzverbindungen vorbereiten und erkennt dann schon, dass das Netz nicht zur Verfuegung steht und weiss automatisch, dass das lokale Profil geladen werden muss. Aber Pustekuchen: Auch das hat nicht funktioniert.

Weiss jemand Rat?

Danke,

Michael

Hallo,

ich moechte einen Exchange-Server gerne in Verbindung mit einem

Smarthost verwenden. Weiss jemand, welche Provider so etwas guenstig

fuer kleinere Unternehmen oder sogar Privatpersonen anbieten?

Gruss,

Michael

Hallo,

es wird ja immer wieder dazu geraten, nach den Arbeiten am

Windows-Server sich von der Konsole wieder abzumelden. Ich kann das

momentan einfach nur aus dem Grund nachvollziehen, dass nicht unnoetig

viele Prozesse auf einem Server laufen muessen und es so einfach nicht

notwendig ist.

Scheinbar koennen durch eine aktive Konsolensitzung im Hintergrund aber

auch Sicherheitsrisiken entstehen. Gibt es zu diesem Thema

Informationsmaterial von Microsoft und kann mir evtl. jemand sagen, um

welche Risiken es sich dabei handeln kann?

Danke,

Michael

Ich habe das gerade mal getestet. Allerdings habe ich den Namen des Exchange-Servers eingetragen - es hat funktioniert. Der GC wird doch über DNS gefunden, oder? Dafür gibt es doch den SRV eintrag?!

Ich habe dazu mal eine Frage. Unsere Notebook-Benutzer arbeiten auf den Notebooks ausschließlich mit lokalen Benutzern. Wenn nun ein Mitarbeiter von außerhalb über ein VPN auf den Exchange-Server zugreifen möchte, kann er Outlook dann auch als lokaler Benutzer starten? Findet Outlook dann den globalen Katalog oder muss der Benutzer sich an der Domäne anmelden?

tsadmin

Perfekt - man lernt nie aus, danke!

Gruß,