Exchange 2013 Neuinstallation: kein Zugriff auf Exchange Administrative Center
Hallo zusammen!
Vorgeschichte:
Dies ist mein zweiter neuer Server 2012 R2, den ich aufgesetzt habe.
Steht z.Zt. hier bei mir für die Grundinstallation.
Installierte Rollen: AD DS; AD-Zertifikatdienste; Anwendungsserver; Datei/Speicherdienste; DHCP; DNS; IIS; WSUS
Alles ohne Probleme wie bei Server 1, der mittlerweile seit ein paar Monaten ohne Probleme seinen Dienst versieht.
Dieser Server soll aber auch Exchange 2013 bekommen.
(Habe bisher einmal Exchange auf einem Server 2008 SMB konfiguriert. Danach nicht mehr.)
Als Erstes bin ich die Installationsvoraussetzungen und Vorbereitungen mehrfach durchgegangen.
Wird ja alles ausführlich z.B. auf
Technet
beschrieben. Zudem gibt es diverse gute YouTube Kanäle.
Youtube
Auch hier habe ich mich informiert.
ALSO:
Installiert wie auf technet beschrieben.
Das aktuelle Paket:
Exchange2013-x64-cu13
Die Installation läuft ohne Fehler.
Nur letztendlich scheitert der Zugriff auf das "Exchange Administrative Center".
Bevor ich jetzt die komplette Konfiguration des Servers hier aufliste, was ich aber gerne nachholen kann, hat vielleicht einer das gleiche Problem gehabt und sofort den Ansatz zur Lösung parat!
3 x habe ich die Installation nach Rücksetzen auf vorherigen Systemzustand wiederholt.
Starte ich das EAC:
https://localhost/ecp/?ExchClientVer=15
erhalte ich
Hierbei wird keine Eingabe akzeptiert.
Habe dann AD-Zertifikatdienste nach Anleitung installiert (obwohl ich davon überhaupt keine Ahnung habe)
Zertifikatdienste installieren
Hilft auch nicht weiter.
Aufruf von: https://192.168.5.55:444 (Server IP Adresse)
Füge ich die Ausnahme hinzu, bekomme ich:
Aufruf von: https://localhost:444
Beim Aufruf der Management Shell:
Gebe ich dann BBB.CCC ein, kommt noch mal die Meldung:
Was ist bloß schiefgelaufen?
Danke an alle Mitdenker.
Vorgeschichte:
Dies ist mein zweiter neuer Server 2012 R2, den ich aufgesetzt habe.
Steht z.Zt. hier bei mir für die Grundinstallation.
Installierte Rollen: AD DS; AD-Zertifikatdienste; Anwendungsserver; Datei/Speicherdienste; DHCP; DNS; IIS; WSUS
Alles ohne Probleme wie bei Server 1, der mittlerweile seit ein paar Monaten ohne Probleme seinen Dienst versieht.
Dieser Server soll aber auch Exchange 2013 bekommen.
(Habe bisher einmal Exchange auf einem Server 2008 SMB konfiguriert. Danach nicht mehr.)
Als Erstes bin ich die Installationsvoraussetzungen und Vorbereitungen mehrfach durchgegangen.
Wird ja alles ausführlich z.B. auf
Technet
beschrieben. Zudem gibt es diverse gute YouTube Kanäle.
Youtube
Auch hier habe ich mich informiert.
ALSO:
Installiert wie auf technet beschrieben.
Das aktuelle Paket:
Exchange2013-x64-cu13
Die Installation läuft ohne Fehler.
Nur letztendlich scheitert der Zugriff auf das "Exchange Administrative Center".
Bevor ich jetzt die komplette Konfiguration des Servers hier aufliste, was ich aber gerne nachholen kann, hat vielleicht einer das gleiche Problem gehabt und sofort den Ansatz zur Lösung parat!
3 x habe ich die Installation nach Rücksetzen auf vorherigen Systemzustand wiederholt.
Starte ich das EAC:
https://localhost/ecp/?ExchClientVer=15
erhalte ich
Hierbei wird keine Eingabe akzeptiert.
Habe dann AD-Zertifikatdienste nach Anleitung installiert (obwohl ich davon überhaupt keine Ahnung habe)
Zertifikatdienste installieren
Hilft auch nicht weiter.
Aufruf von: https://192.168.5.55:444 (Server IP Adresse)
Füge ich die Ausnahme hinzu, bekomme ich:
Aufruf von: https://localhost:444
Beim Aufruf der Management Shell:
Willkommen bei der Exchange-Verwaltungsshell.
Vollständige Liste der Cmdlets: Get-Command
Nur Exchange-Cmdlets: Get-ExCommand
Cmdlets, die einer bestimmten Zeichenfolge entsprechen: Hilfe *<string>*
Allgemeine Hilfe abrufen: Hilfe
Hilfe für ein Cmdlet abrufen: Help <cmdlet name> oder <cmdlet name> -?
Exchange-Teamblog: Get-ExBlog
Vollständige Ausgabe für einen Befehl anzeigen: <command> | Format-List
Kurzübersichtsleitfaden anzeigen: QuickRef
Tipp des Tages Nr. 18:
Um die Liste der UM-IP-Gatewayservernamen anzuzeigen, die für ausgehende Anrufe deaktiviert sind, sowie die Sammelanschl
üsse, die einem UM-IP-Gatewayserver zugeordnet sind, geben Sie Folgendes ein:
$Gateways = Get-UMIPGateway
$Gateways | ForEach {If($_.OutCallsAllowed -Eq $False){ "Gateway Name = " +$_.Name;ForEach ($HuntGroup In $_.Huntgroups
){"Huntgroups " + $Huntgroup}}}
AUSFÜHRLICH: Verbindung mit AAA.BBB.CCC wird hergestellt.
New-PSSession : [AAA.BBB.CCC] Beim Verbinden mit dem Remoteserver "AAA.BBB.CCC" ist folgender Fehler
aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der WinRM-Client hat versucht, den
Kerberos-Authentfizierungsmechanismus zu verwenden, aber der Zielcomputer (AAA.BBB.CCC:80) hat einen "Zugriff
verweigert"-Fehler zurückgegeben. Ändern Sie die Konfiguration so, dass der Kerberos-Authentifizierungsmechanismus
zulässig ist, oder geben Sie einen der vom Server unterstützten Authentifizierungsmechanismen an. Wenn Sie Kerberos
verwenden möchten, geben Sie den Computernamen als Remoteziel an. Stellen Sie auch sicher, dass der Client- und der
Zielcomputer Mitglied einer Domäne sind. Wenn Sie die Standardauthentifizierung (Basic) verwenden möchten, geben Sie
den Computernamen als Remoteziel an, legen Sie die Standardauthentifizierung fest, und geben Sie Benutzername und
Kennwort an. Vom Server gemeldete mögliche Authentifizierungsmechanismen: Digest Negotiate Weitere Informationen
finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed
Fehler beim Herstellen der Verbindung zu einem Exchange-Server am aktuellen Standort.
Geben Sie den vollqualifizierten Domänennamen des Servers ein, zu dem eine Verbindung hergestellt werden soll.:
Gebe ich dann BBB.CCC ein, kommt noch mal die Meldung:
AUSFÜHRLICH: Verbindung mit BBB.CCC wird hergestellt.
New-PSSession : [BBB.CCC] Beim Verbinden mit dem Remoteserver "BBB.CCC" ist folgender Fehler aufgetreten: Die
Anforderung kann von WinRM nicht verarbeitet werden. Der folgende Fehler ist bei Verwendung der
Kerberos-Authentifizierung aufgetreten: Der Computer "BBB.CCC" konnte nicht gefunden werden. Stellen Sie sicher,
dass der Computer im Netzwerk vorhanden ist und dass der angegebene Name richtig geschrieben ist. Weitere
Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed
[PS] C:\Windows\system32>
Was ist bloß schiefgelaufen?
Danke an alle Mitdenker.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 315010
Url: https://administrator.de/contentid/315010
Ausgedruckt am: 25.11.2024 um 03:11 Uhr
31 Kommentare
Neuester Kommentar
Du hast Exchange auf einem Domänencontroller installiert... Das hat sich wahrscheinlich jetzt gerächt.
Oder warum hat dein Server die AD-Rolle? Exchangeserver sind NIE DCs, immer nur Memberserver (esseidenn sie sin ein SBS).
LG,
tomolpi
AD DS; AD-Zertifikatdienste; Anwendungsserver; Datei/Speicherdienste; DHCP; DNS; IIS; WSUS
And on this fully overloaded machine you want to put an Exchange ?? WTF, are you kidding ? No wonder you get these problems.Regards
Hallo,
mit welchem Konto hast Du den Exchange installiert?
Mit dem Default Administrator der Domäne oder einem anderen Domainadministratorkonto?
Einen Exchange auf einer Windows CA zu betreiben halte ich für eine sehr schlechte Idee!
Sobald eine Windows CA auf einem Rechner installiert ist, hat dieser Rechner einige Besonderheiten und Einschrenkungen.
Davon abgesehen das ein DC wenn überhaupt maximal noch Fileserver seoin sollte aber am besten nur DC und nix anderes (viele Gründe)
Exchange will den IIS konfigurieren, aber die Zertifikatsdienste die schon installiert sind haben was dagegen.
Wenn es so und nicht anders geht musst Du mal googeln nach Exchange auf Windows CA installieren.
Evtl muss der Exchange zuerst laufen und dann die CA.
Gruß
Chonta
mit welchem Konto hast Du den Exchange installiert?
Mit dem Default Administrator der Domäne oder einem anderen Domainadministratorkonto?
Einen Exchange auf einer Windows CA zu betreiben halte ich für eine sehr schlechte Idee!
Sobald eine Windows CA auf einem Rechner installiert ist, hat dieser Rechner einige Besonderheiten und Einschrenkungen.
Davon abgesehen das ein DC wenn überhaupt maximal noch Fileserver seoin sollte aber am besten nur DC und nix anderes (viele Gründe)
Exchange will den IIS konfigurieren, aber die Zertifikatsdienste die schon installiert sind haben was dagegen.
Wenn es so und nicht anders geht musst Du mal googeln nach Exchange auf Windows CA installieren.
Evtl muss der Exchange zuerst laufen und dann die CA.
Gruß
Chonta
Zitat von @bonnerjung:
Ich sehe eigentlich auch nicht, (so wie highload), dass der Rechner überladen ist.
Im Moment läuft hier eine CPU-Auslastung von 1-3%.
That was not was i meant. The combination of all these roles is the problem not the performance.Ich sehe eigentlich auch nicht, (so wie highload), dass der Rechner überladen ist.
Im Moment läuft hier eine CPU-Auslastung von 1-3%.
Wenn es nach highload geht, würde ich jetzt 6 Maschinen hier hinstellen oder wie?
No, only one physical machine as hypervisor (Hyper-V/VMware ESXi) and the machines and services distributed on VMs . This is a common scenario, as well in small companies nowadays.At least the following distribution:
VM1 : AD DS; AD-Zertifikatdienste; DHCP; DNS
VM2: Anwendungsserver; Datei/Speicherdienste ;IIS; WSUS
VM3: Exchange
Normally the DC should be redundant (min. 2), also in small companies, so installing this on a seperate hardware is recommended in most cases.
Da ich einen Zusammenhang mit den Zertifikaten vermutete, habe ich diese Rolle mal nachinstalliert.
You don't need a CA only to assign certificates to IIS and Exchange !! These ar typical results and errors of not reading the documentation, sorry.
Hallo,
Aber der Defaultadmin ist Schemaadmin, von daher passt das.
Wenn die Zertifikatsdienste vorher nicht drauf waren und auch nicht im einsatz sind, runter mit denen vom Exchange
Server 2012 R2 erlaubt es einen Hyper-V als Host zu haben und wenn der Host NUR die Hyper-V Rolle hat 2 VM zu betreiben.
Dann kannst Du DC und Exchange auch trennen.
Microsoft rät dringnd davon ab Exchange und DC auf dem selben System zu haben. Das es nicht geht sagt niemand.
Was waren vor der Installation des Exchange für Webdisynte auf dem Rechner installiert? War der IIS schon vorher drauf? Was hat der IIS für eine Rolle gehabt?
Auf nem normalen DC ist der IIS normalerweise nicht drauf.
Was passiert, wenn die Firewall deaktiviert wird?
Was bekommst Du wenn Du nicht übe rlocalhost versuchst den Exchange zueerreichen?
Normalerweise sollte der auf http://ip.vo.server reagieren und dann auf https://ip.vom.server/ecp umschalten.
Ist noch ein anderer Exchange in der domäne vorhanden?
Gruß
Chonta
installiert habe ich als administrator, der auch in der Gruppe Domänen-Admins ist.
die Domänen-admingruppe ist bei der Exchangeinstallation zweitrangig, wichtig ist das der Admin mit dem isntalliert wird auch Schemaadmin ist, sonst wird das nix.Aber der Defaultadmin ist Schemaadmin, von daher passt das.
Auch ohne Zertifikatdienste besteht das gleiche Problem.
Da ich einen Zusammenhang mit den Zertifikaten vermutete, habe ich diese Rolle mal nachinstalliert.Wenn die Zertifikatsdienste vorher nicht drauf waren und auch nicht im einsatz sind, runter mit denen vom Exchange
Server 2012 R2 erlaubt es einen Hyper-V als Host zu haben und wenn der Host NUR die Hyper-V Rolle hat 2 VM zu betreiben.
Dann kannst Du DC und Exchange auch trennen.
Microsoft rät dringnd davon ab Exchange und DC auf dem selben System zu haben. Das es nicht geht sagt niemand.
Was waren vor der Installation des Exchange für Webdisynte auf dem Rechner installiert? War der IIS schon vorher drauf? Was hat der IIS für eine Rolle gehabt?
Auf nem normalen DC ist der IIS normalerweise nicht drauf.
Was passiert, wenn die Firewall deaktiviert wird?
Was bekommst Du wenn Du nicht übe rlocalhost versuchst den Exchange zueerreichen?
Normalerweise sollte der auf http://ip.vo.server reagieren und dann auf https://ip.vom.server/ecp umschalten.
Ist noch ein anderer Exchange in der domäne vorhanden?
Da http und https mit den Standardports schon an "Default Web Site"
Vor der Exchangeinstallation sollten auf der Kiste keine anderweitigen Webdienste laufen.Gruß
Chonta
Zitat von @bonnerjung:
Ich werde noch mal den Systemzustand vor Exchange zurücksichern, AD-Zertifikatdienste und IIS entfernen und ein letztes Mal Exchange neu installieren.
Ahh Moment! Wenn du einen DC zurücksicherst aus einem Image bitte aufpassen!Ich werde noch mal den Systemzustand vor Exchange zurücksichern, AD-Zertifikatdienste und IIS entfernen und ein letztes Mal Exchange neu installieren.
https://technet.microsoft.com/de-at/video/active-directory-tu-mir-das-ni ...
Bitte das Video anschauen da wird es erklärt was dann passiret. Lieber erst den Exchange runterwerfen, dann den Server wo der Exchange drauf war herunterstufen (dann ist er kein DC mehr und du hast nur noch einen) dann aus der Domäne nehmen. Erst dann installierst du bitte eine neue VM nur mit Exchange. Sonst gibt das schliumme Fehler im Eventlog.
tomolpi
Ich werde immer wieder darauf hingewiesen, das die Verbindung nicht sicher ist.
Normal if you don't have a correct certificate with the entered common names in the URL. You should better use the FQDN of the server,https://serverxyz.domain.com/ecp
Also execute an IISRESET in a console.
Warum muss ein DC unbedingt redundant sein? Fällt der Server aus und ich habe meine Datensicherungen parat, kann das Ganze wieder innerhalb von 12 Stunden oder früher laufen. Je nachdem, was passiert ist. Wenn der Kunde einverstanden ist, warum nicht?
If the company does not loose money and reputation while they are not able to work react to mails etc., it's OK to have only one DC. Everyone has to decide himself.
On your picture your default website is not running, but this is necessary for the ecp to work properly!
Regards
Setup kann nicht überprüfen, ob der Eintrag 'Host' (A) für diesen Computer in der DNS-Datenbank auf Server 192.168.5.55 vorhanden ist.
You should resolve it => Reverse DNS-Zone.So, das ganze habe ich jetzt bis zum ... mehrmals durchgespielt.
I did it one time, running and it works on a test install on a DC ... you are doing something wrong we can't see.Regards
Ich habe noch nie einen 2. Server in einer VM installiert
Man installiert Server 2012R2 auf dem Blech und fügt die Hyper-V Rolle hinzu.
Auf diesem Wird dan NICHTS weiter installiert.
Man legt über den Hyper-V manager 2 VM an und installiert auf beiden Server2012R2
Die eine VM wird DC und die andere Exchange.
Saubere Trennung der Dienste.
Das ganze Prepare etx kannst du dir sparen, das wird automatisch gemacht.
Die Zertifikatswarnung kommt, da dem Zertifikat nicht vertraut wird, Exchange 2013 legt bei der Installation ein eigenes selbst erstelltes Zertifikat an, das genommen wird bis man ein eigenes hat.
Also zustimmen.
Als anmeldedaten die Logindaten vom Domänenadministrator verwenden mit : domäne\administrator Schreibweise.
https:\\exchangefqdn\ecp sollte dich dann in den Exchange rein bringen.
In den IIS Einstellungen kann man das "haatpassesspopup" bestimmt irgendiwe abstellen.
Laut screenshot ist die Defaultwebseite down (beendet)
Server schon neu gestartet?
Sind unter Defaultwebseite auch die nötigen Ordner angelegt?
Gruß
Chonta
Dieser Fehler kommt auch erst NACH der Installation von Exchange.
Vor der Installation ist hier alles OK.Vor der Installation von Exchange sollte es ja eigentlich noch keinen IIS oder eine Defaultwebseite geben, das sollte erst alles mit der Installation von Exchange kommen.
Server neustart? Serverlogs warum die default Webseite nicht startet? Den IIS-Verwaltungsdienst neu gestartet?
Irgendwas ist am Grundsystem nicht sauber sonst würde es keine Probleme geben.
Wenn Du die Hyper-V darf keine weiteren Funktionen Regel beachtest, kannst Du aber 2 VM betreiben und in einer den Exchange getrennt vom DC.
Gruß
Chonta
IP4 Serveradressen: 192.168.5.55
Standardgateway: 192.168.10.254
This cannot work if you have a 24bit mask, a gateway has to lie in the same subnet as the clients address!Standardgateway: 192.168.10.254
Ich vermute auch ein DNS Problem, bin da aber leider überfordert.
Then you should give this to someone who knows what he is doing. Installing an Exchange without basic knowledge how a DNS-Server works ??? My dear ....Ich weiß, dass Diagnosen ohne einmal draufzuschauen, sehr schwierig sind.
Right, too few information about your environment.Und auch die WSUS Seite
WSUS ohne IIS ist nicht möglich, also warum ist da ein WSUS drauf?WSUS nach dem Exchangeinstallationsversuch oder schon vorher?
Das Problem ist, das die Defaultwebseite nicht läuft und die muss laufen.
Ich hab den WSUS auch auf unserem Exchange, aber der WSUS wurde NACH dem Echange installiert.
Mach eine zweite VM und betreibe den Exchange darauf und alles wird gut.
Keine weitere Fremdsoftware installiert.
Für Exchange sind auch Microsoftdienste Fremdsoftware Gruß
Chonta
Was schief gelaufen ist, kann man aus der Ferne immer schlecht beantworten. Auch wenn ich hier nicht beabsichtige, Grundsatzdiskussionen vom Zaun zu brechen, man kann sehr wohl den Exchange auf einem DC betreiben - sonst müssten wir uns bei aller Virtualisierung auch darüber unterhalten, ob ein DC überhaupt virtualisiert werden _darf_ . Ich betreue aktiv ca. 100 Exchange-Installationen, kann also durchaus mir darüber eine Meinung bilden und habe nicht nur einen Exchange installiert. Nicht alle meine Installationen sind auf DCs, aber ca. die Hälfte schon (sind aber nie PDC). Für mich und meine Kunden auch eine Frage von Lizenzkosten, das wird immer gerne ausgeblendet. Macht man richtiges Sizing des Exchange (für eine Firma mittlerer Größe sage ich mal 32GB RAM und 8 Kerne für einen solchen Exchange), ist auch Zusatzfunktionalität wie AD kein Problem. Keiner meiner vielen Exchangeserver hat bis dato irgendwelche Probleme gehabt, die sich nicht lösen liessen, auch als DCs. Keiner musste irgendwann neu installiert werden, auch Migrationen auf neuere Versionen verliefen bis dato ohne nennenswerte Probleme ab. Das sind die Fakten. Grundsätzlich verfolge ich folgende Strategie bei der Installation: 1. Das Netzwerk samt DNS MUSS korrekt funktionieren und eingestellt sein, insbesondere der DNS, denn der ist bei AD die Basis und _lebenswichtig_. 80% aller AD-Probleme kommen von genau daher. Wer sich also an Exchange-Installationen wagt, MUSS vollumfängliche Netzwerkkenntnisse (heute beinhaltet das ebenfalls IPv6 und nicht nur IPv4) mitbringen, die auch Administration des DNS voraussetzt. DA, das hat sich immer wieder gezeigt, werden schon im Vorfeld die meisten Fehler generiert. 2. Ich installiere die Serverplattform grund, danach Windows-Updates. Alle sonstigen Rollen wie WSUS etc. erfolgen bei mir aus Prinzip immer NACH dem Exchange. 3. Abarbeitung der Exchange-Prequisities, diese findet man auf den entsprechenden Supportseiten von MS und sollte man einhalten ! 4. Dann der Exchange, _vorher_ auch die AD ausgiebig mit dcdiag nach möglichen Fehlern absuchen. Fertig. Muss danach eigentlich funktonieren. Nach Dutzenden von Installationen und Migrationen bei mir niemals Installationsprobleme aufgetreten, und das schon seit Exchange 2003 Hält man das alles so ein, wette ich, wird es auch kaum Probleme geben. Auch nutze ich nie self-sign-Certs für SSL, ich generiere statt dessen eine eigene CA samt CRL-Strukturen (nutze aber nicht die Windows-eigene CA der AD). Self-sign-certs haben einige Einschränkungen, die nicht immer gut sind, kann man aber für den Anfang durchaus machen.
Also zurück zu deinem Fall. Wenn alle Stricke reissen und es nicht geht, dann installiere einen zusätzlichen sauberen Server und gehe dann so wie ich das oben beschrieben habe vor. Dann sollte auch der Exchange korrekt laufen.
Gruss Heiko
Also zurück zu deinem Fall. Wenn alle Stricke reissen und es nicht geht, dann installiere einen zusätzlichen sauberen Server und gehe dann so wie ich das oben beschrieben habe vor. Dann sollte auch der Exchange korrekt laufen.
Gruss Heiko
Hallo,
du so nebenbei.
Nen PDC gibt es schon sehr lange nicht mehr. Auch schon zu Zeiten vom Exchange 2003.
Und Lizenztechnisch seit ist es seit neustem auch kein Problem mehr.
Mann kann pro Standard Server Lizenz zwei Virtuelle Hosts erstellen
Das währ dann einer für DC und einen für Exchange.
Und ja man kann und darf einen DC Virtualisieren. Hier gibt es nur ein paar kleine Rahmenbedingungen.
Und ein paar Zeilenumbrüche würden deinem Text gut tun.
du so nebenbei.
Nen PDC gibt es schon sehr lange nicht mehr. Auch schon zu Zeiten vom Exchange 2003.
Und Lizenztechnisch seit ist es seit neustem auch kein Problem mehr.
Mann kann pro Standard Server Lizenz zwei Virtuelle Hosts erstellen
Das währ dann einer für DC und einen für Exchange.
Und ja man kann und darf einen DC Virtualisieren. Hier gibt es nur ein paar kleine Rahmenbedingungen.
Und ein paar Zeilenumbrüche würden deinem Text gut tun.
Also eine der FSMO-Rollen ist sehr wohl noch PDC-Emulator...und das meinte ich damit.
Die aktuellen Lizenzbedingungen sind mir wohl bekannt - darum ging es aber auch nicht, zumal ja in der Praxis sowieso kaum nur ein einzelner Server alles macht - das wäre ja aus Redundanzgründen auch fatal und riskant.
Es ging aber um's Prinzip - möglich ist dieses Szenario EX auf DC sehr wohl, quasi als Single-Server-Lösung.
Ich habe nur meine Meinung zu der Aussage hinzugefügt, die da sinngemäß lautete "Exchange auf einem DC - das geht ja gar nicht". Ich teile diese Meinung nicht.
Es geht sehr wohl - sind aber einige Sachen zu beachten. Ist der Exchange bei der Installation auch GC, kann man das z.B. später nicht mehr ändern. Das darf ihm - wenn auch DC und GC - nicht mehr "weggenommen" werden, sonst nix Exchange mehr. Stimmt auch, habe ich schon getestet, ist so korrekt.
Selbstverständlich wird heute (fast) alles virtualisiert, mache ich ja auch so, da in diesen Fällen ja die Lizenznutzung und auch Hardwarenutzung effektiver wird, das ist unstrittig, allerdings auch mit den dazugehörigen Backupkonzepten und/oder Ausnutzung der Möglichkeiten durch Clustering, was ich meistens empfehle und auch umsetze. Hat aber auch seinen Preis
Ist aber letztlich alles eine Entscheidung des Kunden, was er finanziell in die Hand nehmen will. Und das ist eben nicht immer gleiches Niveau bei allen Kunden und Anwendern.
Kurzum, funktionieren tut es mit Exchange auf einem DC sehr wohl und auch von der Installation her hatte ich zumindest die ganzen Exchangeversionen seit 2003 bis heute 2016 kaum Probleme - zumindest keine die sich nicht schnell lösen liessen - unter Beachtung der vorbereitenden Massnahmen, denn die müssen korrekt umgesetzt sein. Dann klappts auch mit'm Exchange.
Die aktuellen Lizenzbedingungen sind mir wohl bekannt - darum ging es aber auch nicht, zumal ja in der Praxis sowieso kaum nur ein einzelner Server alles macht - das wäre ja aus Redundanzgründen auch fatal und riskant.
Es ging aber um's Prinzip - möglich ist dieses Szenario EX auf DC sehr wohl, quasi als Single-Server-Lösung.
Ich habe nur meine Meinung zu der Aussage hinzugefügt, die da sinngemäß lautete "Exchange auf einem DC - das geht ja gar nicht". Ich teile diese Meinung nicht.
Es geht sehr wohl - sind aber einige Sachen zu beachten. Ist der Exchange bei der Installation auch GC, kann man das z.B. später nicht mehr ändern. Das darf ihm - wenn auch DC und GC - nicht mehr "weggenommen" werden, sonst nix Exchange mehr. Stimmt auch, habe ich schon getestet, ist so korrekt.
Selbstverständlich wird heute (fast) alles virtualisiert, mache ich ja auch so, da in diesen Fällen ja die Lizenznutzung und auch Hardwarenutzung effektiver wird, das ist unstrittig, allerdings auch mit den dazugehörigen Backupkonzepten und/oder Ausnutzung der Möglichkeiten durch Clustering, was ich meistens empfehle und auch umsetze. Hat aber auch seinen Preis
Ist aber letztlich alles eine Entscheidung des Kunden, was er finanziell in die Hand nehmen will. Und das ist eben nicht immer gleiches Niveau bei allen Kunden und Anwendern.
Kurzum, funktionieren tut es mit Exchange auf einem DC sehr wohl und auch von der Installation her hatte ich zumindest die ganzen Exchangeversionen seit 2003 bis heute 2016 kaum Probleme - zumindest keine die sich nicht schnell lösen liessen - unter Beachtung der vorbereitenden Massnahmen, denn die müssen korrekt umgesetzt sein. Dann klappts auch mit'm Exchange.
Kurzum, funktionieren tut es mit Exchange auf einem DC sehr wohl
Sagt auch keiner das es technisch nicht geht!Wenn man eaber einen MS Call für diese Konstelleation brauchen würde, würden die aber nein sagen, weil diese Installation von denen nicht suportet wid und nur Umgebungen die deren Bedingungen entsprechen unterstützt werden.
Das es technisch machbar ist hat der SBS ja bewiesen und das war nix weiter als der Standardserver mit Exchange und erweterten Assistenten für leichteren Zugang.
Es geht sehr wohl - sind aber einige Sachen zu beachten.
Richtig.Das mit dem GC und hinzu kommt der Server kann nicht demotet werden, bis der Exchange deinstalliert ist von diesem Server.
Im Problemfall hast Du zwei Kritische dienste auf dem selben System.
Wenn Du jetzt ein Image vom Server zurücksichern musst, weil das AD zerschossen ist, zack Mails sind auch weg.
Ist aber letztlich alles eine Entscheidung des Kunden, was er finanziell in die Hand nehmen will.
Richtig und der ders macht haftet und muss aufpassen und sich absichern und sich unterzeichenen lassen das der Kunde Mist will Gruß
Chonta