testperson

Hi, was wird denn vom SBS alles genutzt? Nur der Exchange? Dann mal in der EMS testen: Set-Content -Path "C:\cert.req" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName "c=<Land>, s=<Bundesland>, l=<Ort>, o=<Antragsteller>, cn=<Host>.<Domain.tld>" -domainName <Host>.<Domain.tld>, autodiscover.<domain.tld>; -PrivateKeyExportable $True) Und dann bei der entsprechenden öffentlichen CA einreichen und später importieren und aktivieren: $Cert = Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\cert.cer -Encoding byte -ReadCount 0)) Enable-ExchangeCertificate -Thumbprint $Cert.Thumbprint -Service IIS, IMAP, SMTP, POP Gruß Jan

Der Content Filter für den Lancom scheint ja schon mit (ab) ~300€ für 3 Jahre den Rahmen zu sprengen.

Hi, bei Windows 10 ist mir das noch nicht untergekommen. Aber bei RDS 2012, 2012 R2 und 2016. Wenn du die "alte" Druckeransicht (%SystemRoot%\explorer.exe shell:PrintersFolder) aufrufst, wirst du vermutlich alle Drucker sehen. Dazu gibt es hier auch nen recht langen Thread: In dem Thread sind einige Ansätze drin. Gruß Jan

Hi, evtl. gibt es ja noch andere Möglichkeiten. Warum denn zwingend eine Endlosschleife bzw. was tust du da "endlos"? Gruß Jan

Hi, entweder Richtlinie nicht nutzen oder den Exchange z.B. über einen Reverse Proxy (Netscaler o.ä.) mit Pre-Authentication veröffentlichen. Siehe auch: https://www.faq-o-matic.net/2013/08/07/dos-angriff-fr-jedermann-ad-konten-sperren/ Gruß Jan

Hi, falls es auch PowerShell sein darf: $objWord = New-Object -ComObject Word.Application $WordFile = "C:\install\test.docx" $PDFFile = "C:\install\test.pdf" $document = $objWord.Documents.Open($WordFile) $document.SaveAs([ref] $PDFFile, [ref] 17) $document.Close() Gruß Jan P.S.: Habe das vor einiger Zeit mal gebraucht und irgendwo im Internet gefunden. Quelle: Keine Ahnung :) Vermutlich GitHub oder Stack Overflow.

Hi, wir hatten bei einem Kunden ein ähnliches EAS-Sync-Problem. Bei einem User hatte geholfen, ihn in eine andere Mailboxdatenbank zu schieben. Da er dann keine Probleme mehr hatte, haben wir einfach alle User in eine neue DB geschoben. Seit dem alles i.O. dort. Gruß Jan

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