Martint

der RODC wurde installiert, da in den Filialen niemand ist, der sich um die IT kümmern kann. Die Leute sollen nur die 3 beschriebenen Dinge machen können, wenn die Leitung ausfällt. Benutzeranlage etc. soll immer im Hauptstandort erfolgen. In der Replikationsgruppe sind die User drin, und auch eine entsprechende Sicherheitsgruppe mit den Computerkonten. Die Anmeldung funktioniert auch. Aktuell eben der Zugriff auf Freigaben nicht....

Hallo im Hauptstandort sind die Standorte angelegt, dort auch die Subnetze usw. In der Filiale macht der RODC das DHCP. Die Ausgabe von einer Station in der Filiale sieht so aus: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : XYZ Primäres DNS-Suffix . . . . . . . : Domain.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : Domain.local Ethernet-Adapter Ethernet0: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection Physische Adresse . . . . . . . . : XXX DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : XXX IPv4-Adresse . . . . . . . . . . : IP(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : Gateway DHCPv6-IAID . . . . . . . . . . . : XXX DHCPv6-Client-DUID. . . . . . . . : XXX DNS-Server . . . . . . . . . . . : DNS-IP des RODC DNS-IP des PDC im Hauptstandort NetBIOS über TCP/IP . . . . . . . : Aktiviert

Hallo Experten ich kämpfe hier an einem Problem und brauche ein wenig gedankliche Unterstützung. Die Situation ist wie folgt - knapp skizziert: Hauptstandort mit Windows Server 2012 als PDC - Subnetz A Filiale mit einem Windows Server 2012 als RODC und einem Windows Server 2016 als FileServer - Subnetz B Alle befinden sich in einer Domäne, die Standorte sind mit VPN verbunden Leider ist häufig mal die Internetverbindung gestört, wenn der Fall eintritt, sollen die Mitarbeiter in der Filiale sich zumindest anmelden können, das Internet nutzen und vor allem auf den FileServer in der Filiale noch zugreifen können. Aktuell ist es so, dass Anmeldung und Surfen dort funktionieren, aber der Zugriff auf den FileServer nicht. Beim Versuch auf eine Freigabe zuzugreifen kommt dann immer die Meldung: "Auf \\XYZ kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. Wenden Sie sich an den Administrator des Servers, um herauszufinden, ob Sie über Berechtigungen verfügen. Die Vertrauensstellung zwischen der Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" Sobald die VPN Verbindung wieder steht, funktioniert das wieder. Hat jemand spontan eine Idee dazu?? Grüße Martin

Also Problem nun endgültig gelöst - Autodiscovery rennt, OAB läuft, OOF läuft... Ursachen? Eine Menge... Punkt 1 - Zertifikat - CN habe ich nun auf den neuen DNS-Namen.tld ausgestellt Punkt 2 - auf den Virtuellen Verzeichnissen waren einige Berechtigungen wohl noch falsch gesetzt Punkt 3 - ohne zu wissen warum, aber in den Konteneinstellungen war die Option Abruf über HTTP konfiguriert... Punkt 4 - nochmal alle Internen Urls nachgezogen Passt nun jedenfalls alles Danke für die Hilfe!

So hat ein klein wenig gedauert. Nun hab ich upgedatet auf SP2 und danach auch gleich auf das Updaterolleup 3 für SP2. Leider alles unverändert... Grüße Martin

Hallo zusammen und Danke für die Ansätze das Umsetzen des Schalter bei der Webseite Autodiscover auf Clientzertifikate ignoerieren scheint zumindest schonmal dazu zu führen, dass der Autodiscover nun erstmals ohne Fehler durchläuft, sieht so aus: Autoconfiguration has started, this may take up to a minute Autoconfiguration found the following settings: Display Name: Administrator Protocol: Exchange RPC Server: EXCHANGE.int-domain.loc Login Name: Administrator Availability Service URL: https://mail.int-domain.loc/ews/exchange.asmx'>https://mail.int-domain.loc/ews/exchange.asmx OOF URL: https://mail.int-domain.loc/ews/exchange.asmx OAB URL: https://mail.int-domain.loc/oab/xxxxx/ Unified Message Service URL: https://mail.int-domain.loc/unifiedmessaging/service.asmx'>https://mail.int-domain.loc/unifiedmessaging/service.asmx Auth Package: Unspecified Protocol Exchange HTTP Server: EXCHANGE Login Name: Administrator SSL: Yes Mutual Authentication: Yes Availability Service URL: https://mail.ext-domain.de/EWS/Exchange.asmx'>https://mail.ext-domain.de/EWS/exchange.asmx OOF URL: https://mail.ext-domain.de/EWS/Exchange.asmx OAB URL: https://mail.ext-domain.de/oab/xxxxx/ Unified Message Service URL: https://mail.int-domain.loc/unifiedmessaging/service.asmx Auth Package: Unspecified Certificate Principal Name: msstd:EXCHANGE unter Protokoll zeigt er an: Attempting URL https://mail.int-domain.loc/Autodiscover/Autodiscover.xml'>https://mail.int-domain.loc/Autodiscover/Autodiscover.xml'>https://mail.int-domain.loc/Autodiscover/Autodiscover.xml found through SCP Autodiscover to https://mail.int-domain.loc/Autodiscover/Autodiscover.xml starting Autodiscover to https://mail.int-domain.loc/Autodiscover/Autodiscover.xml succeeded (0x00000000) ABER... Nun habe ich wieder den netten Effekt, dass ich diesen Anmeldedialog im Outlook bekomme, er will sich immer anmelden an mail.ext-domain.de - auch wenn ich dann auch Abwesenheitsassistent gehe, kommt sofort der Anmeldedialog. Kann es sein, dass auf der Default Web Site was nicht passt? Außerdem wenn ich mir die Ausgabe vom Autodiscover so anschaue, scheint der ja das per HTTP dann abzufragen? Allein wenn ich mir den DomainNamen anschaue... - achso Abwesenheitsassistent bringt dann leider immer noch den Fehler, dass der Server nicht erreichbar wäre - hängt aber sicher an dem Anemldedialog. Ideen? Grüße Martin

Danke, den oberen Link kenn ich zwar schon, aber ich schau es mir nochmal in Ruhe durch... Grüße Martin

Das ist es ja was mich stört - alle Clients sind in der Domäne, daher sollte es doch übers AD gehen? Wegen den Webseiteneinstellungen hab ich geschaut, bei Default Web Site / OWA / Autodiscover steht bei allen 3en: SSL erforderlich und 128 Bit SSL erforderlich angehakt und bei allen 3en steht Clientzertifikate auf Akzeptieren... Grüße Martin

soviel dazu, nun habe ich aber mal den Test von außen gemacht, recht interessant, habe geprüft auf "mail.ext-domain.de" ich hab jetzt einfach mal einen Baum rausgenommen, weil die Meldungen relativ ähnlich sind: Attempting to test potential AutoDiscover URL https://ext-domain.de/AutoDiscover/AutoDiscover.xml Failed testing this potential AutoDiscover URL Test Steps Attempting to resolve the host name ext-domain.de in DNS. Host successfully resolved Additional Details IP(s) returned: xx.xx.xx.xx Testing TCP Port 443 on host ext-domain.de to ensure it is listening and open. The port was opened successfully. Testing SSL Certificate for validity. The SSL Certificate failed one or more certificate validation checks. Tell me more about this issue and how to resolve it Additional Details A network error occurred while communicating with remote host Exception Details: Message: The handshake failed due to an unexpected packet format. Type: System.IO.IOException Stack Trace: at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost) at Microsoft.Exchange.Tools.ExRca.Tests.SSLCertificateTest.PerformTestReally() So ich hoffe das ist lesbar... Er scheint ja wirklich mit dem Zertifikat ein Problem zu haben, wo liegt wohl der Fehler? Grüße Martin

Ja klar, hier ist es: AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce ssControl.CryptoKeyAccessRule} CertificateDomains : {mail.int-domain.loc, owa, autodiscover.int-domain.loc, mail.ext-domain.de, autodiscover.ext-domain.de, EXCHANGE.int-domain.LOC, EXCHANGE, EXCHANGE.ext-domain.de, MAIL.EXCHANGE.int-domain.LOC, int-domain.loc, ext-domain.de} HasPrivateKey : True IsSelfSigned : True Issuer : CN=mail.int-domain.loc, O=int-domain, C=LOC NotAfter : 02.04.2011 15:12:55 NotBefore : 02.04.2010 15:12:55 PublicKeySize : 2048 RootCAType : Registry SerialNumber : 614D2921679D7FBF45D570E7BFBAB03A Services : IMAP, POP, IIS, SMTP Status : Valid Subject : CN=mail.int-domain.loc, O=int-domain, C=LOC Thumbprint : 17342AF2006222AA67FE0058D2996AA2F96CC4D4 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {jse-EX-SRV-CA} HasPrivateKey : True IsSelfSigned : True Issuer : CN=int-domain-EXCHANGE-CA, DC=int-domain, DC=loc NotAfter : 22.03.2015 15:59:19 NotBefore : 22.03.2010 15:49:21 PublicKeySize : 2048 RootCAType : Enterprise SerialNumber : 06EC93A1AE04C48842021242DC9370ED Services : None Status : Valid Subject : CN=int-domain-EXCHANGE-CA, DC=int-domain, DC=loc Thumbprint : 9989AEFBEA6EFBC1578A3969189D225224F19C3C AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System .Security.AccessControl.CryptoKeyAccessRule, System.Securi ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce ssControl.CryptoKeyAccessRule} CertificateDomains : {EXCHANGE, EXCHANGE.int-domain.loc} HasPrivateKey : True IsSelfSigned : True Issuer : CN=EXCHANGE NotAfter : 29.09.2010 20:00:31 NotBefore : 29.09.2009 20:00:31 PublicKeySize : 2048 RootCAType : None SerialNumber : 7FE121CA0C96E89C4E20B96E6F065162 Services : SMTP Status : Valid Subject : CN=EXCHANGE Thumbprint : 3FEEB2ABAAD673078311288AA9D617437135AF1D

Also ggf. ja - wobei ich jetzt erstmal im April mein MCSA vollmachen muss, da steht noch eine Prüfung aus. Aber direkt im Anschluss solls losgehen... Grüße Martin

Hi also wir setzen auf Docusnap - mit der entsprechenden "Multi" Lizenz darf man damit auch unbegrenzt viele Standorte oder andere Netze scannen. Für die Lizensierung entscheidend dann sind die maximalen Clients an 1 Standort. Hast Du also 5 Standorte mit je 50 Clients, dann 50er Multi-Lizenz. Es gibt entsprechende Module die man lizensieren kann, je nachdem was man braucht, Windows, Linux, VMWare, SQL, Exchange. usw. Das Tool finde ich persönlich eines der Besten, zeichnet auch Visio-Pläne, aber das Ergebnis ist mittelprächtig. Ansonsten sehr starkes Tool!! Grüße Martin

Hallo und Danke für das Interesse :) ja ich bin mir auch sicher, dass mit dem XXX Autodiscover etwas nicht passt. Leider stecke ich nur dummerweise fest. Also der Test der Autoermittlung ergibt folgendes: Attempting URL https://mail.int-domain.loc/Autodiscover/Autodiscover.xml'>https://mail.int-domain.loc/Autodiscover/Autodiscover.xml'>https://mail.int-domain.loc/Autodiscover/Autodiscover.xml found through SCP Autodiscover to https://mail.int-domain.loc/Autodiscover/Autodiscover.xml starting Autodiscover to https://mail.int-domain.loc/Autodiscover/Autodiscover.xml FAILED (0x80072F0C) Autodiscover to https://ext-domain.de/autodiscover/autodiscover.xml'>https://ext-domain.de/autodiscover/autodiscover.xml starting Received certificate error with no error context. Failing with cert error. Autodiscover to https://ext-domain.de/autodiscover/autodiscover.xml FAILED (0x800C8203) Autodiscover to https://autodiscover.ext-domain.de/autodiscover/autodiscover.xml'>https://autodiscover.ext-domain.de/autodiscover/autodiscover.xml starting Autodiscover to https://autodiscover.ext-domain.de/autodiscover/autodiscover.xml FAILED (0x80072FoC) Local autodiscover for ext-domain.de starting Local autodiscover for ext-domain.de FAILED (0x8004010F) Redirect check to http://autodiscover.ext-domain.de/autodiscover/autodiscover.xml'>http://autodiscover.ext-domain.de/autodiscover/autodiscover.xml starting Redirect check to http://autodiscover.ext-domain.de/autodiscover/autodiscover.xml FAILED (0x80004005) Srv Record lookup for ext-domain.de starting Srv Record lookup for ext-domain.de FAILED (0x8007251D) Im Synchronierungsprotokoll dann der Fehler zum OAB: 17:18:14 Synchronisiererversion 12.0.6423 17:18:14 Postfach "Administrator" wird synchronisiert 17:18:14 Vorgang abgeschlossen 17:18:14 Microsoft Exchange-Offlineadressbuch 17:18:14 Die Offlineadressbuchdateien werden nicht heruntergeladen. Es wurde kein Server (URL) gefunden. 17:18:14 0X8004010F Die xml Datei kann ich aber erreichen, wenn ich das ganz normal im Browser eingebe. Wie gesagt, für autodiscover.ext-domain.de hab ich ein DNS Eintrag, der zeigt auf den Exchange. Dieser cert error stört mich. Habe aber schon bestimmt 3 mal mit einem neuen Zertifikat getestet. Muss zugeben, der Fehler kommt erst, seitdem ich das vorinstallierte/interne ersetzt hab. Ideen? Grüße Martin

Hallo zusammen Ich weiß es ist kein neues Problem und gibt zig Anleitungen dazu im Netz - ich habe schon eine halbe Ewigkeit mit Troubleshooting verbracht. So langsam gehen mir die Ideen aus... 2 Fehler, die sicher die selbe Ursache haben Fehler 1: Ihre Abwesenheitseinstellungen können nicht angezeigt werden, da ihr Server zurzeit nicht verfügbar ist. Versuchen Sie es später erneut. Fehler 2: Gleichzeitig das allbekannte Problem, das OAB nicht downloadbar ist, das Synchprotokoll sagt, es kann den Server nicht finden.... Situation: - Win 2k8 Server SP2 mit Ex2k7 SP1 installiert - lokale Domäne mit domäne.loc - Clients gehen physisch oder per 2k3 Terminalserver mit Outlook 2007 ans Netz - Proxy Betrieb - Ausnahmeliste wurde gepflegt, auch Abschalten von Proxy ändert am Problem leider nichts - Test der OutlookWebServices ist alles erfolgreich - Autodiscover / Zertifikat - irgendwo hier muss der Hund begraben liegen. Der Test bringt eigentlich nur Fehler und er meckert auch einen Cert Error an, aber nicht konkret, was ihm nicht passt Was habe ich schon gemacht: - DNS Eintrag erstellt autodiscover.domäne.de der auf den internen Exchange zeigt - per Zertifikatsdienste / Kommandoshell ein neues Zertifikat erstellt und das vorinstallierte ersetzt, bei dem die DNS Namen autodiscover.domäne.de,Exchange.domäne.loc und einige mehr enthalten sind. - Zertifikat per GPO verteilt. - Zugriff auf OWA im Netz bringt keinen Zert.Fehler - Zugriff per OAB im Netz bringt Zugriff verweigert (so sollte es wohl auch sein) - OAB ist zugeordnet, wurde aktualisiert, Dateien existieren - EWS Verzeichnis neu erstellt - Autodiscover Verzeichnis neu erstellt - als interne URL habe ich überall Exchange.domöne.loc eingetragen - DNS technisch funktioniert das Gibt es noch weitere Ideen, um da weiter zu machen? Kann beim Zert. noch was falsch sein? Vermute es könnte hier der Fehler sein? Danke für den Input vorab Grüße Martin

Hallo nochmal danke für Eure Ideen. @klausk Daran hab ich auch schon gedacht, hast Du was im Hinterkopf, was transparent funktioniert und bezahlbar ist? Das Problem ist halt, dass der Chef die Daten tagsüber im Zugriff braucht, daher sollen die Sachen auf dem Netz bleiben. Es gibt aber in der Firma ein oder 2 Leute, die aufgrund ihrer Arbeit die Admin-Berechtigung haben, bzw. auch das Passwort haben. Chef will eben nun, dass die nicht an diese Daten kommen (u.a. Lohndaten). Das vom Netz zu trennen hab ich vorgeschlagen, wollte er aber nicht, weil es dann in der täglichen Arbeit zu unpraktikabel ist. Das mit der Verschlüsselung hat zumindest für Aufmerksamkeit gesorgt.