testperson

Das solltest du ändern.

In der Konstellation würde ich vermuten, liegt es an der Firewall vom Hyper-V Host. Aber keine Ahnung, ich halte das Routing über den Hyper-V Host, wie im Hetzner Wiki beschrieben, für nicht sinnvoll. Bzw. das Gesamtkonstrukt halte ich für nicht so ideal. Die Firewall VM kannst du doch nach belieben installieren. Ich würde da einfach eine fertige Firewall Appliance (z.B. Sophos UTM Essentials / Home) nehmen. Oder pfsense, da wäre quasi genau das beschrieben: https://www.netgate.com/docs/pfsense/virtualization/virtualizing-pfsense-with-hyper-v.html

Hast du, wie ich es im anderen Thread vorgeschlagen hatte, eine Firewall VM aufgesetzt oder macht der Hyper-V das Routing? Hier noch mal mein Hinweis:

Hi, wie sind denn jetzt deine VMs bzw. auch der Host angebunden? Es ist immer noch der Hetzner Hyper-V Root Server? Gruß Jan

Warten, ggfs. Server und Client durchbooten, warten. Hatte aber auch schon Fälle, da hat nur neues OL Profil geholfen. Hast du denn jetzt autodiscover mit im Zertifikat?

Wenn man weiß was man tut nimmt man ja beispielsweise den LegacyExchangeDN mit. Dann weiß man aber auch, dass es trotzdem einfacher und sinnvoller ist über 2013 zu 2016 zu gehen.

Ich würde noch autodiscover.externedomain.de für alle primären SMTP-Adressen dazu packen. Und halt auch ins Zertifikat.

Hi, mit Smartcards geht das. Siehe z.B.: http://www.datev.de/dnlexom/client/app/index.html#/document/0903434/D27021599867986187 Gruß Jan

Poste doch mal ein Bild von der Outlook Zertifikatswarnung. Ohne autodiscover.<domain>.<tld> wirst du aber definitiv Probleme haben. Let's Encrypt bietet AFAIK doch auch SAN Zertifikate an. Dann prüfe mal, ob tatsächlich alles passt und poste mal die Ausgaben: $Exch = Get-ExchangeServer | where { $_.AdminDisplayVersion -like "Version 14.3*" } Get-OwaVirtualDirectory -Server $Exch | fl Name, InternalUrl, ExternalUrl Get-EcpVirtualDirectory -Server $Exch | fl Name, InternalUrl, ExternalUrl Get-OABVirtualDirectory -Server $Exch | fl Name, InternalUrl, ExternalUrl Get-ActiveSyncVirtualDirectory -Server $Exch | fl Name, InternalUrl, ExternalUrl Get-WEbServicesVirtualDirectory -Server $Exch | fl Name, InternalUrl, ExternalUrl Get-ClientAccessServer -Identity $Exch.Name | fl Name, AutoDiscoverServiceInternalUri Get-OutlookAnywhere -Server $Exch | fl ServerName, ExternalHostname Test-Connection $((Get-OwaVirtualDirectory | select-object ExternalURL -ExpandProperty InternalURL).Host) Test-Connection $((Get-OwaVirtualDirectory | select-object ExternalURL -ExpandProperty ExternalURL).Host)

Solange der Hyper-V Host / die Hyper-V Hosts in der Domäne sind, ist das ja nicht zu dramatisch. Aber die beste Methode ist es definitiv nicht. Es ist aber mit Sicherheit eine gute Methode sich mit der PowerShell anzufreunden. :-D

An der Stelle könnte man jetzt noch fragen, was du da überhaupt im Detail vor hast. Warum dieses Konstruk mit dem so isolierten Quellhost? Was soll am Ende denn passieren?

Ich würde zuerst einmal die Kommunikation mit allen DCs / DNS ermöglichen.

Da fehlt doch autodiscover.<domain>.<tld>. Und mit dem Zertifikat sollte der Browser sowohl bei autodiscover.<domain>.<tld> wie auch mail.<domain>.<tld>. eine Zertifikatswarnung ausspucken. P.S.: Beim Subject solltest du ggfs. den CN noch anonymisieren.

Der Quellhost ist aber in der Domäne und hat auch eine entsprechende Verbindung zur Domäne bzw. den DCs? Dort ist mit der Firewall auch alles i.O.?

Und welche Netze werden für die Live Migration genommen? Welche Leistungsoption (TCP/IP / Komprimierung / SMB)? Sind die Hosts in einer bzw. in der gleichen Domäne? Die Windows Firewall passt?

Rufe testweise mal OWA von intern und extern über https://autodiscover.<domain>.<tld>/owa, https://mobil.<domain>.<tld>/owa und https://mail.<domain>.<tld>/owa auf. Was gibt denn: Get-ExchangeCertificate | fl CertificateDomains, Issuer, Subject, Not*, Services, Status

Hi, das neue Zertifikat wurde auch an die Dienste gebunden? Bei der Zertifikatswarnung zeigt Outlook auch das korrekte neue Zertifikat an? Was kommt wenn du im Browser einmal die konfigurierten URLs für OWA aufrufst? Ansonsten boote den Exchange einmal durch und danach einen Client. Gruß Jan P.S.: Der Exchange 2010 und der Windows Server dadrunter sind aktuell gepatched?

Hi, ggfs.: https://blogs.technet.microsoft.com/exchange/2018/07/16/issue-with-july-updates-for-windows-on-an-exchange-server/ Gruß Jan

Hi, funktioniert es denn, wenn du für die Hyper-V Hosts bzw. generell einmal ANY <-> ANY erlaubst? Die Firewall hat auch keine Spezialfunktion für RPC o.ä.? Du verschiebst nur die VM oder auch den Speicher? Wie sind die Einstellungen bzw. Erweiterten Features für Live Migration konfiguriert? Gruß Jan

Hi, man kann so eine VMDK auch auf einen anderen Host kopieren. Oder auf dem alten Host eine neue Dummy-VM aufesetzen, die dann die "alte" Platte des DCs bekommt. Wo läuft denn jetzt der 2te DC? Auf einem ESX oder auf einem Office Rechner? Bzw. was tut ein DC auf einem Office Rechner? So "chirurgisch" ist das nicht wenn man bedenkt wie das damals( ™ ) mit ntdsutil war.. Gruß Jan

Hi, ggfs. wäre was mit einem evtl. vorhandenen Reverse-Proxy zu machen. Mit einem Netscaler davor könnte man OWA z.B. in die Unified Gateway Oberfläche einbinden. Dann hast du oben rechts in der Ecke den Login Namen der ein Menü aufklappt mit dem Punkt "Kennwort ändern". Sowas kann man sich sicherlich auch selber bauen und OWA "einfach" in ein Portal einbetten und das Kennwort über diese Portal ändern. Ging bzw. geht z.B. mit Forefron UAG auch. Gruß Jan

Hi, wenn es eine VM ist, kannst du doch die virtuelle Festplatte danach einfach als weitere Platte an einen anderen Server hängen und dort an die Daten kommen. Daher sollte es genügen, sofern es nur ein DC war und es noch weitere gibt, im ADUC (dsa.msc) das Computer Konto des DCs zu löschen, im ADSS (dssite.msc) am entsprechenden Standort den Server zu löschen. Danach ggfs. noch im DNS aufräumen. Sollte der DC die FSMO Rollen haben, solltest du diese vorher noch auf einen funktionierenden DC verschieben. Gruß Jan

Hi, kannst du mit einem der Beispiele (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/send-mailmessage?view=powershell-5.1) eine kurze Testmail senden? Gruß Jan

Hi, ich verstehe das jetzt so richtig: Es gibt Windows Server 2016 Datacenter / Standard CORE "Lizenzen" die wir melden Es gibt entsprechende SALs für Remote Desktop, Exchange, etc. Es gibt keine Windows Storage Server 2016 CORE "Lizenzen" Es gibt keine Windows Storage Server SAL Heißt unterm Strich, wir können nichts melden, da es nichts gibt und der Zugriff auf einen Windows Storage Server ist wie im "In-House-Fall" durch die mitgelieferte und vorinstallierte OS Lizenz abgedeckt. Vielen Dank @lizenzdoc Gruß Jan

Hi, wir setzen bei uns im Hosting als Backupstorage HP StoreEasy System mit Windows Storage Server 2016 als OS ein. Hier kam jetzt die Frage auf, ob und wie wir ggfs. das Windows Storage Server OS lizenzieren können / müssen. Wir können da ja per SPLA erstmal nur Datacenter und / oder Standard melden. Ist der Storage Server, wie auch In-House, nicht CAL bzw. im SPLA dann meldepflichtig? Ist zwar eigentlich nicht meine Baustelle, aber wir warten da scheinbar schon länger auf eine Antwort. Falls jemand also was dazu sagen kann, wäre ich über eine Info dankbar. Gruß Jan