DJNova

Hallo, ich wollte nur Bescheid geben, dass alles einwadnfrei funktioniert hat. Habe die Keys eingetragen und alles funktioniert wunderbar. Danke & Lg, Michael

Tut mir leid für den Stress... War selber auch 2 Tage außer gefecht gesetzt. Das ganze ist ein Terminalserver mit aktuellstem Patchstand in einer VMware-Umgebung. Fehlermeldungen gibt es absolut keine, nein. Deswegen bin ich ja so verwundert. Danke vielmals für den Tip. Werde das gleich mal ausprobieren. Lg, Michael

Ich wollte es mal pushen, da ich sowas noch nie hatte und total ratlos bin. Danke, Michael

Hallo, ich habe ein Problem, und ich weiß nicht mehr weiter. Ich habe einen Filer, welcher die CIFS Shares hält und einen Server 2012 für das DFS. Jetzt können zB die Multifunktionsdrucker/Scanner nur direkt in den Share Scannen, und nicht über das DFS. Habe es auch so eingerichet, dass der Scanner in einen Share scannt, welcher als Target eines Ordners im DFS eingetragen ist, damit die Leute darauf gleich zugreifen können. Jetzt kommt aber das Problem... 1-2 oder 3 Dokumente funktionieren und werden gleich nach dem Scannen angezeigt, und danach entweder garnicht mehr oder mit F5. Wenn F5 nichts bringt, dann muss man sich ab- und wieder anmelden. Danach funktioniert es wieder für 1 oder maximal 2 Scans. Die User arbeiten auf einem Terminalserver mit Server 2008 R2. Hat da jemand einen Rat für mich? Danke & Lg, Michael

Hallo, Ich habe 5 Terminalserver im Einsatz mit identer Konfiguration und Patchstand. Leider ist ein Server darunter, auf dem man sich zwar anmelden bzw einloggen kann, aber sobald der erste Benutzer drauf ist, ist es nicht möglich eine weitere Verbindung herzustellen bzw dass sich ein weiterer Benutzer anmelden kann. Wenn ich den Service für die Remotedesktopsitzung neu starte, dann fliegt dieser eine Benutzer zwar raus, es kann sich ein neuer anmelden, aber trotzdem kein weiterer. Konfiguration: (alle Server sind Server 2008 R2) Server01: Connectionbroker, License Server Server02, Server03, Server04: Mitglieder einer Farm f. interne Benutzer Server05: Dedizierter Server f. externe Mitarbeiter Server06: Dedizierter Server f. Kunden Das Problem besteht nur auf Server06, der jedoch, wie schon erwähnt, gleich konfiguriert ist wie alle anderen, außer dass dieser, wie auch Server05 nicht Mitglieder der Farm sind. Habe dann bereits den Artikel http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/779f48ca-1582-431b-9a1d-7b222aa08269/ gelesen, aber eine Neustallation von KB2667402 hat nichts gebracht. Den zweiten Patch, habe ich aber nicht neu installiert. Jetzt ist die Frage, ob das Problem schon mal jemand in dieser Form hatte. Danke, Michael Edit: Hat sich soeben erledigt... eine Policy hat mir die Gleichzeitigen Verbindungen auf 1 gesetzt... so eine sch****.

Hallo, anscheinend hat SplitDNS nicht richtig funktioniert. Jetzt kommt die Warnung nicht mehr. Danke für die Hilfe. Das war er rote Faden den ich gebraucht habe :-)

Wenn es das ist, was ich vorher konfiguriert habe, dann ja. Aber wenn die offizielle Adresse gefragt wird, dann fragt er trotzdem immer den externen DNS und wird auf die offizielle IP weitergeleitet, die auf den internen Server NATet. Und die Zertifikatsmeldung kommt nach wie vor nach ca. 15-30 Sekunden.

Ich weiß nicht, was ich noch schreiben soll oder was du für Infos brauchst. Ich habe nun alle interen sowie externe Adressen aller Services auf die externe Domäne gesetzt.

Die offizielle Domain nach draußen wird wo anders gehostet und nicht von unserem internen DNS. Verstehe jetzt nicht genau, wo das Problem liegt.

Autodiscover für https://webmail.domain.extern/autoiscover/autodiscover.xml Fehlgeschlagen (0x800C8203) Autodiscover für https://autodiscover.domain.extern/autoiscover/autodiscover.xml Fehlgeschlagen (0x800C8203) muss ich am DNS, weil die Domain wird ja von wem anders gehostet, dort die subdomain "autodiscover" eintragen? Mich wundert es nur, weil ja die Subdomain "webmail" auf die gleiche IP zeigt wie "autodiscover" zeigen würde.

Jap, die funktioniert.

Autodiscover kann ich jetzt gar keinen mehr machen... Ich habe die interne URL des Autodiscovers auf die externe URL gesetzt und jetzt sagt er, dass die Einstellungen nicht bestimmt werden konnten. Setze ich wieder auf die interne zurück für den Autodiscover, dann kommt die Zertifikatsmeldung sofort bzw kommt 2mal.

Ich habe mich zu früh gefreut... Nach dem Start von Outlook dauert es ca. 15-30 Sekunden, und es kommt wieder ein Warnhinweis, dass der Servername im Zertifikat nicht mit dem eigentlichen Servernamen übereinstimmt... :angry:

So, jetzt habe ich alles nochmal durch. Ich habe zwar die interne Adresse für EWS angepasst, aber auf den Autodiscover vergessen. Anscheinend dauernd in der falschen Zeile geschaut... Man wird bilnd, wenn man sich dauernd mit einem Thema beschäftigt. Ich habe es nun gelöst als ich folgende zwei Verzeichnisse geändert habe: Set-ClientAccessServer -Identity CASSRV -AutodiscoverServiceInternalUri https://EXTERNE-URL/autodiscover/autodiscover.xml Set-WebServicesVirtualDirectory -Identity "CASSRV\EWS (Default Web Site)" -InternalUrl https://EXTERNE-URL/ews/exchange.asmx Set-OABVirtualDirectory -Identity "CASSRV\OAB (Default Web Site)" -InternalUrl https://EXTERNE-URL/oab Danke für den Denkanstoß :jau:

Ich habe mir jetzt nochmal alles durchgesehen, und auch die EWS Config nochmal überarbeitet. Jetzt kommt aber noch immer die Zertifikatswarnung, weil der Servername nicht mit dem im Zertifikat übereinstimmt. Es hilft mir nicht viel, wenn man meine Aussagen unf Fragen kommentiert. Ich wollte die Situation schildern, und wenn zu wenig Infos sind, reiche ich die mit Vergnügen nach. Ich zweifle auch nicht an der Kompetenz der Leute, die mir hier Hilfe anbieten... Ich bräuchte nur einen kleinen Hinweis, oder irgendwas, das mich wieder auf die richtige Bahn bringt. Vielleicht habe ich einen kleinen Denkfehler gemacht und/oder in der Konfiguration etwas nicht bedacht, nicht konfiguriert oder aber auch verkonfiggt... Beim Test der Autokonfiguration via Outlook zeigt er mir alle Pfade korrekt an... :-(