testperson

Hi, ggfs. kommst du schon mit Get-Printer zurecht: Get-Printer | where { $_.PrinterStatus -eq "Offline" } Da müsstest du eben nur ein wenig noch in Richtung USB bzw. lokalem Drucker oder Netzwerk filtern und dann entsprechend mit Remove-Printer löschen. Generell würde ich Drucker weder per GPO verteilen noch per Script. Sowas sollte ein User sich selber und nach Bedarf einrichten bzw. verbinden können. Gruß Jan

Hi, d.h. du betreibst den Cluster jetzt mit je einem Knoten auf je einem der ESXis? Dann macht das ganze ja auch deutlich mehr Sinn (, zumindest in meinen Augen). Dann solltest du ggfs. noch Anti-Affinity-Rules erstellen, dass das auch so bleibt. Was sagt denn die Cluster-IP-Adressressource zu DHCP: Get-ClusterResource -Name "Cluster-IP-Adresse" | Get-ClusterParameter Gruß Jan

Hi, das dürfte der klassische "Alles neu inkl. Exchange Fehler" sein : https://www.frankysweb.de/exchange-migration-sonderfall-pst-migration-550-5-1-1/ Gruß Jan

gpresult /h gpo.html && gpo.html # oder rsop.msc Alternativ erstelle eine neue OU, deaktiviere die Vererbung und schieb User wie auch RDSH da rein. Boote den RDSH durch und prüfe.

Also dann kannst du dir den Aufwand eigentlich auch sparen. Ich zitiere dazu mal aus o.g. Link (https://kb.vmware.com/s/article/2147661):

Hi, noch als Ergänzung, der In-Guest Cluster ist in einer supporteten Konfiguration: https://kb.vmware.com/s/article/2147661 Gruß Jan

Hi, wenn Autodiscover korrekt eingerichtet ist und funktioniert, dann funktioniert das beides intern wie extern "automagisch". Am simpelsten dafür wäre Split-DNS und ein vertrauenswürdiges Zertifikat. In dem Fall _sollte_ es entsprechend MAPI over http und somit korrekt sein. Gruß Jan

Hi, vermutlich kannst du wieder eine "schöne Lösung" draus machen, wenn du dir das durchließst: https://docs.microsoft.com/de-de/archive/blogs/askds/deploying-group-policy-security-update-ms16-072-kb3163622 Gruß Jan

Hi, dann hast du doch deine Lösung. Das Outlook einfach per MAPI (over HTTP) anbinden und glücklich sein. Gruß Jan

Hi, sind das die einzigen beiden Einstellungen die nicht im Profil gespeichert werden oder nur Beispiele? Im Default sind das zumindest (AFAIK) beides Einstellungen, die vom Client in die Session übernommen bzw. bei Anmeldung vom Client überschrieben werden. Ansonsten wäre die Frage, wie deine Profile konfiguriert sind und was da konfiguriert ist. GPO und "müsste" solltest du prüfen. Schau dir mit "gpresult /h gpo.html" an, was tatsächlich angewendet wird. Gruß Jan

Evtl. könnte man sich hier auch bei einem Wiki-Systeme bedienen ggfs. auch eine Lösung aus dem Bereich Inventarisierung / Dokumentation wie bspw. Docusnap?

https://www.solarwindsmsp.com/de/produkte/rmm/managed-antivirus (Derzeit sollte das die Bitdefender Endpoint Security sein). Ich muss dazu sagen, dass das von uns genutzte "komplett Paket" (für On-Prem-Kunden) von Solarwinds durchaus in Ordnung ist. Für meinen Bereich (im Hosting) möchte ich es mal nicht in Worte fassen...

Da scheinbar jeder AV Hersteller "deaktivieren" frei interpretiert und je nach Versionsstand "mal das" deaktiviert und/oder "mal das" und mit etwas Glück auch alle "Schutzmechanismen", ist mein Schluss der Verzicht auf AV auf dem Exchange (sofern es nicht gefordert wird). Das bei uns zuletzt selbst Ausnahmen je nach Protection unterschiedlich Interpretiert und teils ignoriert wurden machts dann eben auch nicht besser. (Bei mir könnte die Abneigung zum AV (bzw. zu unserem AV) halt von meinem CU14 Dilemma mit "C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml" kommen.)

Bei dem AV auf dem Exchange wurden die empfohlenen Ausschlüsse gesetzt (https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2016)? Wenn der AV nicht der Defender ist, hast du den Defender noch installiert (Remove-WindowsFeature "Windows-Defender-Features")? (Generell bin ich der Meinung, dass ein AV auf dem Exchange mehr "schadet" wie hilft.)

Ich würde vorsichtig behaupten, dass das nichts mit dem Exchange Update zu tun hatte. Das wollte zumindest keinen Reboot, habe halt "vorsichtshalber" nur durchgebootet. Ich hatte ebenfalls noch einen anderen Server gebootet, wo gar nichts installiert wurde. Der hatte auch recht lange mit "Windows wird vorbereitet" zu kämpfen. Als Gemeinsamkeit hätten die beiden Systeme nur den Juni Patchday, der letzten Freitag/Samstag durchgeführt wurde.

Die "Spielwiese" ist durch. Bis jetzt ist mir nur aufgefallen, dass es im Setup keinen "Schritt 2 von 17" gibt, dafür aber zweimal "Schritt 1 von 17" . Ansonsten hat der Server grade eine gute Stunde mit "Windows wird vorbereitet" verbracht, obwohl keine Windows Updates installiert wurden...

Also die "Neuerungen" hauen mich noch nicht vom Hocker: 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2016 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2016 Mit etwas Wohlwollen: 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 and 2016 Und von den "Issues" ist mir glaube ich noch keiner über den Weg gelaufen. Mal schauen, ob (m)ein Testsystem heute noch dran glauben muss.

Hi, soeben wurde das Exchange 2019 CU6 sowie das Exchange 2016 CU17 veröffentlicht: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-june-2020-quarterly-exchange-updates/ba-p/1458993 Exchange 2019 CU6: https://support.microsoft.com/en-us/help/4556415/cumulative-update-6-for-exchange-server-2019 Exchange 2016 CU17: https://support.microsoft.com/en-us/help/4556414/cumulative-update-17-for-exchange-server-2016 Viel Erfolg beim Patchen! Gruß Jan

Die Mailkette kann ja auch schon vor der Zielorganisation (teilweise und/oder ggfs. unbewusst) außerhalb der Hände beider Beteiligter liegen. Es ist ja leider nicht so unüblich, dass man Mails bei Hostern (Strato, 1und1, Host Europe und Co.) einliefert und es ab da "abenteuerlich" weitergeht. Hier und da finden sich dann evtl. noch "Backup MX" von Providern. Natürlich läuft dann E-Mail-technisch bei der Zielorganisation vermutlich was nicht richtig. Da hilft dann aber eben auch kein Mailgateway, welches auf dem ersten Hop mit "sicheren Ciphern" und vertrauenswürdigen Zertifikaten TLS erzwingt.

Ähm, das ist so vermutlich nicht korrekt. Du solltest vermutlich Autodiscover korrekt einrichten und die entsprechende(n) URL(s) mit ins Zertifikat aufnehmen.

Genau darauf zielt @Dukels Einwand doch ab. Du bist dir doch niemals sicher, ob du tatsächlich in den richtigen/finalen Briefkasten eingeworfen hast. Es können ja noch einige Briefkästen auf dem Weg zum Ziel kommen.

Die Bindings sehen irgendwie nicht nach "Default" aus.

Hi, du hast im April das Zertifikat am Exchange erneuert und jetzt hast du das Problem? D.h. bis gestern gab es noch kein Problem und heute meldet der Browser das Zertifikat sei abgelaufen? Prüfe mal, ob die Zeit am Exchange Server und/oder den zugreifenden Clients korrekt ist. Ansonsten: Ist das ein vertrauenswürdiges Zertifikat einer internen / externen CA? Ist das ein self-signed Zertifikat? Der Browser zeigt dir tatsächlich das neue bzw. richtige Zertifikat, welches auch tatsächlich gültig ist? Der Exchange ist auf einem aktuellen CU (16 oder 15)? Gruß Jan

Hi, losgelöst vom Backup würde ich den Host immer in die Domäne aufnehmen, sofern eine Domäne vorhanden ist. Gruß Jan

Hi, an dieser Stelle sollte dir bewusst sein, dass im Fall der Fälle so ein Windows Server Backup vom Active-Directory das einzige vom Hersteller selbst supportete Backup ist. Im "worstesten Case" kann dir das WSB bzw. der dann benötigte Support vom Hersteller durchaus den Allerwertesten retten. Und für umsonst kostenlos würde ich das definitiv mitnehmen. Ebenfalls nützt dir das beste AD Backup nichts, wenn der Restore nie getestet und dokumentiert wurde. Damit man nicht "andauernd" ans Backup muss, wäre auch der AD Papierkorb noch ein guter Ansatz (aber kein Backup-Ersatz): https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100- Gruß Jan