NorbertFe

Ja und? Nennt sich "localpart", was ich oben geschrieben habe, oder?

Warum so umständlich? Bau ne neue Emailadressrichtlinie und vergib die neue Emailadresse (domain oder localpart) und definiere sie als Antwortadresse. Bestehende Adressen werden _NICHT_ gelöscht.

Ich hab das jetzt nicht komplett verfolgt, aber im Endeffekt sind das also zwei (oder mehr ) GALs, oder? ;)

Erfahrungsgemäß testet man mit sowas maximal eine "korrekte" Installation. Allerdings auf die Gefahr Test und Produktion recht schnell zu verwechseln und vor allem in der Testumgebung Produktivdaten zu verwenden. Im Allgemeinen ist das zumindest für obiges Szenario absolut überflüssig imho und selbst wenn in der "Testumgebung" alles läuft, heißt das leider noch lange nicht, dass es dann in der Produktion auch so ist. Bye Norbert

Weil man dafür keinen Support bekommt. Kannst ja mal überlegen, warum das so sein könnte. :)

Tja, ob das aber schon ausreicht, eine nicht DSGVO-Konforme Umgebung vorauszusetzen? Ist sicher diskussionswürdig. Aber ich bin da bei Nils. Schönen Abend noch Norbert

Du wirst aber mindestens eine neue benötigen, in der dann die Freelancer stecken. Wenn die sich auch nicht sehen sollen brauchst du für jeden eine eigene.

Würde ich aktuell zumindest so sehen.

Vielleicht klären wir ja erstmal, über welche Exchange Version in welchem Patchstand wir überhaupt sprechen. :)

Du meinst auf dem gleichen darunterliegenden RAID (Physik)? Volumes können es ja trotzdem unterschiedliche sein. ;) Ich konfiguriere das meist als Mountpoints um etwas (für mich) Übersicht zu bekommen. Wenn alles auf einem Volume liegt, dann muß man länger forschen, welche DB und welche Logfiles grad anwachsen. Performancetechnisch dürfte es in diesen Fällen aber egal sein. Im DAG Verbund braucht manches aber logs und dbs auf dem selben Volume fürs afair Autoreseed. Aber das hast du ja nicht. Bye Norbert

Danke für die Info. Das Thema VC++ 2012 Ist ja gar nicht mal so "umständlich" beschrieben. ;)

Korrekt, wenn nur die Notebooks auf den Terminalserver zugreifen, dann benötigst du keine weiteren Lizenzen, sondern hast 15x Office Pro zuviel.

Wenn du mal zahlen nennen würdest... wenn du genauso viele standardlizenzen hast wie PCs (Notebooks) sind nur die professional Lizenzen übrig. Die kannst du dann verkaufen oder verschenken oder einlagern oder auf Geräten installieren, die nicht auf die terminalserver zugreifen.

Üblicherweise müßte man doch nicht auf DB einschränken, sondern auf den Scope der "impersonierten" Nutzer. Wo (in welcher DB) die dann liegen dürfte egal sein und verhindert im übrigen auch Fehler, wenn man mal eine Mailbox verschieben würde.

Nein Windows 2012R2 + Windows 10. Nicht Windows Server 2016.

Dann definiere das doch einfach in den GPP (als Filter für die Laufwerksmappings). Das ist sinnvoller in meinen Augen, als da mit dem Background Refresh rumzuprobieren. Also bei _meiner_ Arbeitsweise ohne Reboots würde das bedeuten, dass neue GPOs mich sehr selten erreichen würden, weil ich mein Notebook selten boote. Keine Ahnung wie das bei euch gehandhabt wird.

Er kann sie lizenzieren. Ja. Jeder KMS Serverkey kann alle Client OS selber oder älterer Versionen aktivieren. Also 2012R2 kann Windows 8.1, 8 7 und Vista aktivieren (sowohl Pro als auch Enterprise).

OK, wenn ich obige Fehlermeldungen richtig deute erfolgt aber die Kontosperrung im Zusammenhang mit Exchange (Mobile Devices, EWS usw.) Evtl. verhält sich das dann anders als bei interaktiven Anmeldeversuchen. Kann ich grad nicht testen.

Ein GPUPdate ist aber nicht background sondern foreground und ein Force erzwingt halt die Übernahme auch wenn keine Änderungen stattgefunden haben. Was im Allgemeinen ja auch keinen Backgroundrefresh erfordert, denn wenn sich nichts ändern gibts nix zu refreshen. Ich denke du hast einfach ein "Logikproblem". Vergiß doch einfach mal den Backgroundrefresh. Wofür willst du den abschalten?

Nach einem Reboot erfolgt im VPN weiterhin ein Background Refresh? Und die Policy wird auch übernommen? Was genau sollte jetzt ein gpupdate /force deiner Meinung nach bewirken?

Auch bei einem deaktivierten Konto kann man ja fehlerhafte Anmeldeversuche anstellen. Irgendwann wirds halt gesperrt, wäre jetzt meine Vermutung, ohne dass ich das jetzt mit Quellen belegen könnte. Aber kannst du ja relativ einfach nachvollziehen. Leg dir ein neues Konto an, deaktiviere es und gehe an einen PC und versuche dich mit falschem Kennwort mit diesem Konto x-mal anzumelden. Irgendwann sollte es gesperrt werden (je nachdem wie eure Lockout Policy aussieht). Bye Norbert

Doch das funktioniert. Nur vermutlich nicht so wie du erwartest. https://gpsearch.azurewebsites.net/#335 Note: If you make changes to this policy setting, you must restart your computer for it to take effect. Heißt der Computer erhält die Vorgabe im VPN den Background Refresh zu deaktivieren, aber das würde erst nach einem Reboot passieren. ;) Denn vorher weiß er davon j a nix.

Damit man den Hintergrundrefresh deaktiviert. Warum man das tut, die Gründe kannst du dir selbst ausdenken. ;)

Du sollst auf den Laufwerksmappings den Filter setzen, dass die Laufwerke _nicht_ gemappt werden, wenn du im VPN steckst. Dann ist die Hintergrundaktualisierung doch egal.

Die kannst du doch dann aktiviert lassen, wenn es dir rein um das Thema GPP Laufwerksmapping geht.