testperson

Hi, wir setzen das schon länger entsprechend bei uns(eren) Kunden um. Ab und an finden Kunden das nicht gut, sind aber nach einem Gespräch meistens mit diesem Weg einverstanden. Ebenfalls kommen manchmal DSBs oder Versicherungen um die Ecke, dass Kennwörter regelmäßig geändert werden müssen. Wenn der Kunde sich dann für den Weg des DSBs entscheidet oder die Versicherung es als Bedingung hat, setzen wir das halt um. Im Rahmen von "Cross Selling" haben das fremd Dienstleister unseren Kunden auch schon als "unverantwortlich" verkauft. Gruß Jan

Wenn die Mail "an sich" archiviert werden darf, dann sollten die dazugehörigen Logs auch kein Problem sein. Aber das soll im Zweifelsfall der DSB oder ein Anwalt klären :). Ich meine mich zumindest zu erinnern, dass es seinerzeit auf einer Schulung zur Reddoxx Archivierung hieß, dass das Log ebenfalls archiviert werden muss(?)/sollte(?), da nur die Mail und ein "250 Ok" tatsächlich ein Beweis sind. Das waren aber auch noch Vor-DSGVO-Zeiten.

Sofern die Logs revisionssicher archiviert wurden. (Ja, dann wird man wohl die eigentliche Mail ebenso archiviert haben ;).)

Hi, ggfs. kommst du am schnellsten und sichersten "ans Ziel", wenn du die Applikation(en) in der VM in eine neue VM migrierst. Alternativ könntest du noch versuchen, VM herunterfahren, VHDX kopieren und eine neue identisch konfigurierte VM mit der kopierten Platte erstellen. Gruß Jan

Evtl. wäre es noch ein Ansatz die "IMAP Ordner" per IMAP Migration (https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/imap-migration-in-the-admin-center) ins O365 zu holen und den Usern per Anleitung anzuraten, die Kalender / Kontakte / Aufgaben per Drag&Drop zu übertragen.

Die beste Möglichkeit wäre wohl gewesen, sich beim Einrichten der IMAP-Konten bzw. dem Kalender Gedanken zu machen und die OST nicht als Default-Speicher anzugeben bzw. die Daten eben bei Einrichtung zu trennen ;). Die jetzt verbleibende Möglichkeit wäre wohl an alle Clients zu stiefeln und die Daten händisch in PST zu exportieren oder alternativ eines der OST Konvertierungs- / Recovery-Tools zu kaufen.

Hi, nein. Wie würdest du dir das vorstellen? Und bevor du den Exchange zweimal bis zur Ziel-Gesamtstruktur migrierst wärst du vermutlich besser dran, direkt "alles" in die "temporäre Domain" zu migrieren und diese einfach nach deinem Wunsch zu benennen. Du solltest dir das aber noch mindestens einmal durch den Kopf gehen lassen: Eine Firmenübernahme bedingt ja nicht zwingend eine AD-Domänen-Umbenennung oder -Migration. Gruß Jan

Ich würde vorsichtig behaupten, dass das was zu tun ist im o.g. Link steht. ;) Hast du auf dem Testrechner vorher ggfs. Teams im Benutzerkontext "installiert"? Das Unterdrücken des Autostarts ist auch im Link beschrieben. Sobald ein User allerdings Teams startet, richtet sich auch der Autostart ein. Das müsste der User danach dann in den Einstellungen wiederum selber verwalten. Ggfs. lässt sich das auch in der "%appdata%\Microsoft\Teams\desktop-config.json" machen.

Hi, Der "Machine Wide Installer" bzw. das MSI legt dann AFAIK auch eine Verknüpfung auf dem Desktop an bzw. startet Teams bei der nächsten Anmeldung am Rechner automatisch, sofern nicht anders konfiguriert: https://docs.microsoft.com/de-de/microsoftteams/msi-deployment Gruß Jan

Hi, das klingt so, als wäre der Server auch DNS Server. Die wichtigste Frage wäre aber, warum schaltet ihr den Server im Betrieb aus? Gruß Jan

Hi, Ja. Aber so will man das nicht! Die wichtigste Frage wäre, was du mit dem Root Server "generell" vor hast und warum soll "dein Fileserver" im Internet erreichbar sein? Gruß Jan

Mir wäre ad hoc auch kein Grund bekannt warum Raider jetzt Twix heißt ;).

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.)