Gimbanossi

Ok, wenn wir die Frage zu den Lizenzen mal als geklärt betrachten, was könnt ihr mir zum Rest sagen? Danke.

Ok, danke dafür schon mal. Wer hat denn für die vorangestellte Frage noch einen hilfreichen Rat?

Hallo Community, ich plane eine Umstellung und benötige mangels Erfahrung noch den ein oder anderen Tipp von Euch ;-) Folgende Situation: Vorhanden ist ein Windows Server 2012 R2 Standard mit einem Xeon E5 CPU und 32GB Ram, der aktuell als Host für die Warenwirtschaft-Software und als zentraler Datenspeicher mit Sicherungsfunktion genutzt wird. Nun soll eine Zweigstelle angebunden werden, in der 4 weitere Mitarbeiter arbeiten. Für diese Mitarbeiter soll der Server als Terminalserver fungieren, damit die 4 Mitarbeiter per RDP ebenfalls mit der Warenwirtschaft arbeiten können. Der Server verwaltet weder DNS noch DHCP und ist auch kein DC. Vielmehr ist gar keine Domäne im Netzwerk vorhanden. Dieser Umstand hat mich zwar verwundert, aber ich frage mich, ob es denn wirklich sinnvoll ist, nachträglich eine Domäne zu installieren. Dass eine Domäne generell sinnvoll ist, ist mir klar, aber der damit einhergehende Aufwand wäre ja nicht gerade gering und der Mehrwert ist dem Kunden oft nicht in der Form ersichtlich, dass es den Aufwand rechtfertigt. Zudem würde ich dann den aktuellen Server in eine VM umwandeln wollen und um den DC erweitern. Dazu eine zweite VM für den Terminalserver installieren, da TS und DC ja niemals gemeinsam laufen sollten. (habe ich mir mal sagen lassen) Nun meine Frage an Euch: Bin ich da auf dem richtigen Weg oder ist das vielleicht sogar mit Kanonen auf Spatzen geschossen? Außerdem: Muss ich für die 4 Mitarbeiter tatsächlich eine 5er User-Cal UND eine 5er RDS-Cal kaufen? Oder gibt's da vielleicht mir unbekannte Tricks? Vielen Dank vorab.

Vollkommen richtig. Und nur weil das so ist, haben Leute wie Du in Foren wie diesen die Möglichkeit mit Rat und Tat zur Seite zu stehen um zu helfen und Anerkennung zu ernten. Und manchmal ist es auch ok ein Problem zu umgehen, anstatt es zu lösen. Hauptsache es läuft hinterher, Dafür nochmal vielen Dank.

Ne. Ich habe mir ein Emailkonto vorgenommen, bei dem ich diese Änderungen vorgenommen habe. Und mit eben diesem Emailkonto habe ich auch die Tests durchlaufen lassen. Inwiefern hätte also diese Information dazu beigetragen, die Fehlersuche abzukürzen? Getestet wurde ja schließlich mit einem Konto bei dem die Vererbung aktiviert war. Abgesehen davon, weis ich jetzt ja immernoch nicht ganz exakt, was jetzt genau mit meinem Zertifikat falsch war, bzw. wo der Fehler genau saß...

Ich hatte das Konto welches ich zum testen benutzt hatte schon entsprechend angepasst. Ich habe es hier nur nochmal explizit aufgeführt für all diejenigen, die mal danach googlen werden und dann nicht sämtliche benötigten Infos auf 7 verschiedenen Foren zusammen tragen müssen, so wie ich, sondern in einem Post all diese Infos vorfinden ;-)

UPDATE: (und für alle, die mal das gleiche Problem haben sollten) Ich habe jetzt ein Multidomain SSL Zertifikat mit den Einträgen "remote.meinedomain.de", "autodiscover.meinedomain.de" und "meinedomain.de" erworben und entsprechend beim Provider für meine Domain und die entsprechende Subdomain (autodiscover. ...) sowie auf unserem Server installiert. Anschließend per GPO verteilt. Ich habe außerdem im AD bei allen betroffenen Usern in den Sicherheitseinstellungen die Vererbung aktiviert (Achtung: Vorher unter Ansicht die Erweiterten Features aktivieren) und unter Konto die Anmeldung auf xyz@domain.de (identisch zur Emailadresse) eingestellt. Und siehe da - alle mobilen Geräte die ich bisher testete finden die Einstellungen nun vollautomatisch. Wenn ich jedoch lokal mein Outlook öffne, schimpft es da im Zertifikat der Name "exchange-server.domäne.local" nicht gefunden werden konnte. Aber ich denke, dieses Problem wird kein sehr großes sein. Ich bedanke mich bei allen, die zur Problemlösung beigetragen haben.

ich kaufe jetzt also erstmal ein Multi-Domain SSL Zertifikat für remote.meinedomain.de und autodiscover.meinedomain.de Muss ich auf sonst noch etwas achten, damit es am Ende nicht das falsche Zertifikat wird? Gibt es beispielsweise Unterschiede darin, welche mobilen Endgeräte damit zu recht kommen etc?

korrigiert mich bitte, wenn ich falsch liege. Aber abgesehen davon, dass in dem Zertifikat definitiv zu viel drin steht, müsste doch rein theoretisch - wenn testconnectivity.microsoft.com erfolgreich durchläuft - von Seiten des Zertifikats her - alles zumindest so weit ok sein, dass die Funktion gegeben sein sollte, oder etwa nicht? Sorry wenn ich so doof frage :-\

ja, das Thema UPN war auf Seite 1 schon mal diskuttiert worden, habe ich entsprechend angepasst. Prinzipiell spricht nichts gegen die Investition in ein öffentliches Zertifikat, allerdings würde ich das ganz gerne erst einmal selbst hinbekommen, also mit einem selbstsignierten. Wenn ich dann eins kaufe möchte ich vorher schon ganz genau wissen, dass die Einträge alle korrekt sind und ich nicht wieder irgendwas im Zertifikat vergessen habe. Es sollte damit ja schließlich auch möglich sein, nicht wahr?

Ursprünglich war es ein SBS (daher das remote.) Den SBS gibt es aber nicht mehr. Der wurde durch mehrere 2012R2 abgelöst und der Exchange 2010 des SBS wurde migriert zu einem Exchange 2013. Welche Einträge sollten Deiner Meinung nach denn im Zertifikat drin stehen und welche nicht?

ja, nur was und wo ist falsch konfiguriert? :-P Outlook fragt auch einige Zertifikate ab, hab ich das Gefühl. m.meinedomain.de und mobil.meinedomain.de zum Beispiel. Diese URLs stehen in meinem Zertifikat nicht drin. Ich habe bei mir nur folgende Einträge: exchange-server.domäne.local exchange-server remote.meinedomain.de autodiscover.meinedomain.de autodiscover.domäne.local meinedomain.de domäne.local sollte das nicht eigentlich reichen?

Also die Mobile Devices verhalten sich auch im internen WLAN so. Outlook von außerhalb habe ich noch nicht getestet, werde ich aber gleich mal tun und anschließend berichten. So, habe jetzt noch folgendes getestet: Outlook von außerhalb des Netzwerks - Einstellungen werden gefunden, scheinen aber nicht die richtigen zu sein. Statt https://remote.meinedomain.de trägt er als Server irgendeinen ellenlangen Hashwert@meinedomain.de ein und die Verbindung kann dann auch nicht hergestellt werden. MAC von außerhalb des Netzwerks - Einstellungen werden nicht automatisch gefunden, aber die Verbindung funktioniert nach händischer Eingabe (Server-URL & Domäne\Username) problemlos. (erkennt als Server dann https://remote.meinedomain.de/ews/exchange.asmx)

Sowohl Exchange ActiveSync-AutoErmittlung als auch Synchronisierung, Benachrichtigung, Verfügbarkeit und automatische Antworten. Das Ergebnis ist bei beiden das gleiche. Wenn man die Vertrauensstellung für SSL ignoriert läuft's problemlos durch, wenn nicht, fehlt die Zertifikatskette... Das Zertifikat wurde am Smartphone beim ersten Einrichtungsversuch vom Gerät abgefragt und bestätigt. Ein "test-outlookwebservices" gibt ebenfalls "Erfolg" zurück. Aber mit Outlook gabs bei mir auch nie diese Probleme, das hat immer auf Anhieb die Einstellungen automatisch gefunden und umgesetzt. Das Problem hab ich nur bei mobilen Geräten.

hat vielleicht noch jemand eine zündende Idee, die evtl. zur Lösung beitragen könnte?

habe jetzt bei den Benutzerprinzipalnamen-Suffixen "meinedomain.de" hinzugefügt und beim User dann in den Eigenschaften - Konto - Benutzeranmeldename das "@meinedomain.de" eingestellt. Leider führt auch das nicht zum erwünschten Ergebnis. Sprich, das Smartphone meldet immer noch, dass die Einstellungen nicht gefunden werden konnten.

nein, ich habe ein selbstsigniertes Zertifikat. UPN ?? :suspect: Hier nochmal der komplette Testbericht. Bei ignorierter SSL Vertrauensstellung. Es wird versucht, den AutoErmittlungs- und Exchange ActiveSync-Test durchzuführen (falls angefordert). AutoErmittlung für Exchange ActiveSync erfolgreich getestet. Weitere Details Verstrichene Zeit: 8444 ms. Testschritte Es wird versucht, alle Methoden zum Herstellen einer Verbindung mit dem AutoErmittlungsdienst zu verwenden. Der AutoErmittlungsdienst wurde erfolgreich getestet. Weitere Details Verstrichene Zeit: 8444 ms. Testschritte Es wird versucht, die mögliche AutoErmittlungs-URL https://meinedomain.de:443/Autodiscover/Autodiscover.xml zu testen. Fehler beim Testen dieser potenziellen AutoErmittlungs-URL. Weitere Details Verstrichene Zeit: 750 ms. Testschritte Es wird versucht, die mögliche AutoErmittlungs-URL https://autodiscover.meinedomain.de:443/Autodiscover/Autodiscover.xml zu testen. URL der AutoErmittlung erfolgreich getestet. Weitere Details Verstrichene Zeit: 7693 ms. Testschritte Es wird versucht, den Hostnamen autodiscover.meinedomain.de im DNS aufzulösen. Der Hostname wurde erfolgreich aufgelöst. Weitere Details Zurückgegebene IP-Adressen: meine.ip Verstrichene Zeit: 172 ms. Es wird getestet, ob TCP-Port 443 auf Host autodiscover.meinedomain.de überwacht wird/geöffnet ist. Der Port wurde erfolgreich geöffnet. Weitere Details Verstrichene Zeit: 168 ms. Die Gültigkeit des SSL-Zertifikats wird überprüft. Das Zertifikat hat alle Überprüfungsanforderungen bestanden. Weitere Details Verstrichene Zeit: 5468 ms. Testschritte Die Microsoft-Verbindungsuntersuchung versucht, das SSL-Zertifikat vom Remoteserver autodiscover.meinedomain.de an Port 443 zu erhalten. Die Microsoft-Verbindungsuntersuchung hat das Remote-SSL-Zertifikat erfolgreich abgerufen. Weitere Details Antragsteller des Remotezertifikats: CN=exchange-server.domäne.local, OU=xxx, O=xxx, L=xxx, S=xxx, C=DE, Aussteller: CN=ems-EXCHANGE-SERVER-CA-1, DC=domäne, DC=local. Verstrichene Zeit: 5446 ms. Der Zertifikatsname wird überprüft. Zertifikatsnamen erfolgreich überprüft. Weitere Details Der Hostname autodiscover.meinedomain.de wurde im Eintrag für den alternativen Antragstellernamen des Zertifikats gefunden. Verstrichene Zeit: 0 ms. Das Datum des Zertifikats wird getestet, um zu bestätigen, dass das Zertifikat gültig ist. Überprüfung des Datums war erfolgreich. Das Zertifikat ist nicht abgelaufen. Weitere Details Das Zertifikat ist gültig. NotBefore = 6/19/2015 2:11:25 PM, NotAfter = 6/18/2017 2:11:25 PM Verstrichene Zeit: 0 ms. Die IIS-Konfiguration wird im Hinblick auf die Clientzertifikatsauthentifizierung überprüft. Keine Clientzertifikatsauthentifizierung erkannt. Weitere Details Clientzertifikate für Akzeptieren/Anfordern nicht konfiguriert. Verstrichene Zeit: 606 ms. Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann. Die Microsoft-Verbindungsuntersuchung hat die AutoErmittlung-Einstellungen erfolgreich durch das Senden von AutoErmittlung-POST-Daten abgerufen. Weitere Details Verstrichene Zeit: 1277 ms. Testschritte Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://autodiscover.meinedomain.de:443/Autodiscover/Autodiscover.xml für Benutzer meine@email abzurufen. Die XML-Antwort der AutoErmittlung wurde erfolgreich abgerufen. Weitere Details AutoErmittlung - Kontoeinstellungen XML-Antwort: <?xml version="1.0"?> <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006"> <Culture>en:us </Culture> <User> <DisplayName>Mein Anzeige Name aus dem AD</DisplayName> <EMailAddress>meine@email</EMailAddress> </User> <Action> <Settings> <Server> <Type>MobileSync</Type> <Url>https://remote.meinedomain.de/Microsoft-Server-ActiveSync</Url><Name>https://remote.meindomain.de/Microsoft-Server-ActiveSync</Name> </Server> </Settings> </Action> </Response> </Autodiscover> HTTP-Antwortkopfzeilen: request-id: e104e48c-733b-46bb-8820-fb9ddb9b5965 X-CalculatedBETarget: exchange-server.domäne.local X-DiagInfo: EXCHANGE-SERVER X-BEServer: EXCHANGE-SERVER Persistent-Auth: true X-FEServer: EXCHANGE-SERVER Content-Length: 720 Cache-Control: private Content-Type: text/xml; charset=utf-8 Date: Wed, 24 Jun 2015 07:59:52 GMT Set-Cookie: X-BackEndCookie=S-1-5-21-1958032487-xxxxxxxxx-4064754212-1170=u56Lnp2ejJqBnZrHzMbPmZnSyxxxxxxxmp3G0p7Jzc/SnMvKyM2bzxxxxxxxGgYHPyNDNy9DNz87K38/IxcrGxcrN; expires=Fri, 24-Jul-2015 05:59:52 GMT; path=/Autodiscover; secure; HttpOnly Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Verstrichene Zeit: 1276 ms.

wie gesagt, läuft der autodiscover Test von Microsoft problemlos durch. Der DNS Eintrag ist vorhanden und verweist auf den Exchange Server. Was mir jetzt noch aufgefallen ist, ist wenn ich bei dem Test das "SSL Vertrauensstellung ignorieren" nicht anwähle, läuft der Test auf Fehler. Zertifikatsvertrauensstellung wird überprüft. Fehler bei der Überprüfung der Vertrauenswürdigkeit des Zertifikats. Testschritte Die Microsoft-Verbindungsuntersuchung versucht, Zertifikatketten für Zertifikat CN=exchange-server.meinedomain.local, OU=xx, O=xxxx, L=xxx, S=xxx, C=DE zu erstellen. Für das Zertifikat konnte keine Zertifikatkette erstellt werden. Weitere Details Die Zertifikatkette konnte nicht erstellt werden. Möglicherweise fehlen erforderliche Zwischenzertifikate. Verstrichene Zeit: 16 ms Wenn die das Ignorieren der SSL Vertrauensstellung jedoch aktiviere und den Test erneut durchführe ist das Ergebnis erfolgreich und liefert am Ende folgendes: Die XML-Antwort der AutoErmittlung wurde erfolgreich abgerufen. Weitere Details AutoErmittlung - Kontoeinstellungen XML-Antwort: <?xml version="1.0"?> <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006"> <Culture>en:us</Culture> <User> <DisplayName>Mein Anzeige-Name aus dem AD</DisplayName> <EMailAddress>Meine Email Adresse</EMailAddress> </User> <Action> <Settings> <Server> <Type>MobileSync</Type> <Url>https://remote.meinedomain.de/Microsoft-Server-ActiveSync</Url> <Name>https://remote.meinedomain.de/Microsoft-Server-ActiveSync</Name> </Server> </Settings> </Action> </Response> </Autodiscover> HTTP-Antwortkopfzeilen: request-id: 69307396-cb1a-40d1-b162-xxxxxxxxxxxx X-CalculatedBETarget: exchange-server.domäne.local X-DiagInfo: EXCHANGE-SERVER X-BEServer: EXCHANGE-SERVER Persistent-Auth: true X-FEServer: EXCHANGE-SERVER Content-Length: 720 Cache-Control: private Content-Type: text/xml; charset=utf-8 Date: Wed, 24 Jun 2015 07:42:20 GMT Set-Cookie: X-BackEndCookie=S-1-5-21-1958032487-xxxxxxxxx-4064754212-1170=u56Lnp2ejJqBnZrHzMbPmxxxxxxxxdLLmp3G0p7Jzc/xxxxxxxxbzJycycvGgYHPyNDNy9DNz87K38/IxcvNxc3P; expires=Fri, 24-Jul-2015 05:42:20 GMT; path=/Autodiscover; secure; HttpOnly Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Verstrichene Zeit: 1349 ms.

Das Smartphone - ein iPhone 5S, ein Sony Xperia Z3 und ein Lumia830 - meldet: "Servereinstellungen konnten nicht gefunden werden, bitte geben Sie die Daten manuell ein" - So oder so ähnlich ist die Rückmeldung. Dann gibt man die Daten ein und es geht. Aber eben diesen Schritt möchte ich gerne automatisieren. So weit ich informiert bin, sollte das eigentlich gehen.

Guten Tag zusammen, sicherlich ist dieses Thema schon sehr häufig diskutiert worden. Leider habe ich jedoch trotz intensiver Suche keinen passenden Thread zu meiner Problematik finden können. Ich hoffe also, dass mir hier jemand meine Frage beantworten kann. Ich möchte im Prinzip nur folgendes erreichen: Wenn ich am Smartphone ein neues Emailkonto anlege, Exchange wähle, meine Email-Adresse und Passwort eingebe, sollen alle restlichen Informationen zur Einrichtung des Emailkontos vom Smartphone automatisch ermittelt werden. (Domäne, Username und Server-Url) Dies ist aktuell bei mir leider nicht der Fall, obwohl autodiscover und ActiveSync einwandfrei zu funktionieren scheinen. Wenn ich auf testconnectivity.microsoft.com den Test durchlaufe, erfolgt dieser erfolgreich. Auch Outlook macht keinerlei Anstalten. Ich habe einen Exchange Server 2013 laufen, der das ganze verarbeiten soll. Getestet habe ich das Verhalten mit Windows Phone, iOS und Android. Überall muss ich URL, Domäne und Username anschließend manuell eingeben, damit das Emailkonto eingerichtet wird. Wenn ich von einem externen PC die URL https://remote.meinedomain.de/autodiscover/autodiscover.xml aufrufe, erhalte ich eine HTTP 600 Meldung, was aber normal sein soll, sowie ich mir habe sagen lassen. Ich hoffe, ich konnte deutlich machen, was mein Problem ist, und das mir hier geholfen werden kann. Ich freue mich über jeden konstruktiven Beitrag und bedanke mich vorab. mfG Simon

Weil der SBS zu träge ist. Viele Dinge wie z.B. Sharepoint und IIS werden gar nicht benötigt und belasten das System unnütz. Zudem ist in diesem Fall Exchange 2013 gewünscht. Durch jahrelanges "Hin und Her" mit verschiedensten Assistenten und/oder manuellen Veränderungen am SBS weis da keiner mehr so genau was wie konfiguriert wurde und Fehlerbehebungen bringen oft neue Fehler an anderer Stelle wieder mit sich.

OK, also lieber 2 virtuelle Instanzen starten und eine davon als DC / DHCP / DNS / AD umfunktionieren? Irgendwie hab ich kein gutes Gefühl dabei, eine VM als einzigen DC laufen zu lassen. Prinzipiell kann der Server mit dem SQL darauf ja auch DC sein. Oder sollte er das vielleicht sogar? Wie gesagt, von der Hardware her sollte das kein Problem sein.

Hallo zusammen, vorab: Ich habe mithilfe der SuFu zwar ähnliche Themen gefunden, aber nichts, was meine Frage wirklich beantwortet. Folgendes Szenario: Meine Frage bezieht sich auf ein kleines Unternehmen mit 2 Servern. Hardware ist recht neu und auch ganz gut bestückt für die Betriebsgröße. Ein Server ist ein SBS2011 DC auf dem DHCP/DNS/AD und Exchange 2010 läuft. Auf dem Zweiten läuft 2012R2 und SQL Server für die Warenwirtschaftssoftware. Ich würde jetzt gerne den SBS2011 durch einen 2012R2 ablösen. Meine Idee war, für den Exchange2013 eine virtuelle Instanz zu nutzen und die physische Instanz als DC mit DHCP / DNS / AD laufen zu lassen. Der SQL Server könnte als DHCP Failover-Cluster mitgenutzt werden und dient ebenfalls als DNS Server. Ich habe eine weitere Maschine dort stehen um die Migration des Exchange vorher in einer virtuellen Umgebung test-weise durchzuspielen. (SBS als VHD einbinden und auf weitere Hyper-V exchange2013 laden und migrieren) Jetzt zur Frage: Ist das grundsätzlich eine gute Idee oder auf welchem Weg könnte ich das besser machen, bzw. welche Fettnäpfchen habe ich vielleicht übersehen? Ich bin für alle Tipps, Anregungen und Kritiken an diesem Plan offen und bedanke mich vorab.