jimmyone

Hallo Zusammen, gibt es Erfahrungen bezgl. dem Einsatz des SPO Migrations-Manager und der betreffenden Agents bezgl. Zuverlässigkeit und Durchführung in der Migration von Fileservern? Zusätzlich wäre interessant (ich weiß nicht ob ich das bei der umfangreichen Doku einfach überlesen habe) ob und wie ggf. NTFS Berechtigungen migriert werden. LG

Hallo Zusammen, ich befasse mich derzeit mit dem Thema Migration on-prem Exchange nach Exchange Online. Ich betreue das derzeit alleine, deshalb habe ich niemanden, mit dem ich mal Gedanken austauschen kann. Nicht das noch jemand denkt, ich habe hier Lack gesoffen. Keine Ahnung davon und will migrieren, so ist das nicht. Es geht hier nur um Überlgungen zu einem möglichen Szenario. Zur Zeit verwenden wir den Agent Hybridmouds mit AD-Connect und zugehörigen Settings. Meine Frage bezieht sich ganz konkret auf den Mailflow im Hybrid-Szenario. Derzeit zeigen die MX'er auf ein Mailgateway, das vor dem on-prem Exchange in einer DMZ steht. Mailgateway als auch Exchange sollen in dem Szenario migriert werden. Für das Mailgateway gibt es derzeit noch die Problemstellung des blocked Port 25 in Azure ohne Ent. Agreement. Die machen den Port auch nicht frei. Also wandert das GW ggf. nach AWS, weil wir keinen Zusatzdienst für den Mailflow nutzen wollen oder verzichten zukünftig auf das versenden über das Mail GW und regeln nur noch den Empfang. In meinem Szenario wird der MX'er weiterhin auf das Mailgateway zeigen und damit ist kein Flow Problem da. Wie wäre das aber, zum Verständnis, wenn ich das Mailgateway nicht hätte, dann würde der MX'er ja auf den on-prem Exchange zeigen. Der Eintrag müsste aber ja eigentlich zukünftig auf Exchange Online zeigen oder bleibt dieser auf der on-prem Variante solange eingetragen als dieser als Hybrid noch verfügbar ist? Insbesondere wenn nicht unmittelbar alle Postfächer migriert werden oder es Postfächer gibt, die nicht ohne B-Rat oder DS Zustimmung migriert werden dürfen. Auf der anderen Seite muss ich auch auf dem Mailgateway zukünftig entscheiden, wohin ich die Nachricht zustelle. Also müsste doch in der Grundüberlegung ein System das "führende" bleiben, bis ein kompletter Switch auf Exchange Online mit allen Postfächern, Freigaben etc. stattgefunden hat. Könnt ihr da etwas Licht ins Dunkel bringen? Danke vorab.

Vielen Dank, für die Hinweise, für welche Szenarien AADDS geeignet ist. In meinem Fall habe ich dann diese Szenarien so nicht.

Hallo Zusammen, bei einem per VPN an das on-premise angebundene Azure Netzwerk kann eine Azure Windows VM ob Server oder Workstation an das on-premise AD per Join hinzugefügt werden. Nun gibt es aber ja auch noch die Azure AD Domainservices, die ja quasi das Pedant zur on-prem Welt sind. Seht ihr besondere Vor oder Nachteile, warum man Azure AD Domainservices anstelle on-prem nehmen sollte? Jetzt mal ohne Berücksichtigung, das man dadurch mit on-prem wieder stark verzahnt ist und die Ausfallsicherheit wieder stärker auch von on-prem abhängt. Würde mich über einen Meinungsaustausch freuen. LG Jimmyone

Jup. Aber: Mein innerer Monk hatte kurzzeitig Probleme mit dieser Thematik.

Ok, ja dann passt es ja. Ja, genau das meinte ich in meinem Einleitungstext mit ich sehe auch die Änderungen im Filesystem. Ich war nur etwas irritiert. Aber passt dann so für mich. Ganz herzlich bedankt bei allen. :)

Hallo Zusammen, aktualisieren eure Exchange Server 2016 die Buildnumber nach Security Updates im ECP und PS Abfrage auch nicht? Nachweislich sehe ich in der Systemsteuerung die eingespielten Updates durch ihre KB Nummer. Auch die Änderungen im Filesystem. Die Buildnumber bleibt aber im ECP auf der des CU22 (2375.7) für Exchange 2016. Auch über die PS erscheint nicht die Buildnumber des Patches. In der PS nutze ich zur Abfrage: Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion Jetzt interessiert mich: Ist das nur bei mir so oder auch bei euch? LG

Hallo Zusammen, kann jemand das folgende Verhalten bestätigen oder nachstellen? Wir haben eine moderne hybrid Exchange Umgebung. Eine Kennwortänderung des hinterlegten Admins in Exchange Online für den Batchvorgang war notwendig. Über den Hybridassistenten auf der on-premise Seite muss man diesen vergeben, also habe ich den Assistent entsprechend gestartet und dort verändert. Dem Anschein nach wird diese Änderung aber nicht nach Exchange Online für den Endpunkt repliziert. Auch dann nicht wenn ich einen völlig anderen Nutzer eintrage. Das führt bei einem Batch zu dem Fehler, dass keine Verbindung mit dem Appproxy hergestellt werden kann. Sobald ich das Kennwort manuell in Exchange Online anpasse ist der Vorgang wieder erfolgreich durchführbar. Ist das ein Fehlerbild nur bei mir oder für euch auch nachvollziehbar?

Also laut Doku war das System niemals PDC oder sonst wie FSMO Owner. Aus Interesse: Von welchem How-to ist hier die Rede? Ich weiß heute ehrlich gesagt nicht mehr wirklich, wo wir die Lösung damals her hatten. Ich weiß noch, das rum gekrebse mit dem Zeitgeber war irgendwann so nervig, dass wir eine Domänenweite Lösung gesucht haben. Vielleicht basiert diese Lösung sogar auf dem von Dir genannten How to.

Prima, das hat geklappt. Danke NorbertFe. Tatsächlich hätte ich darauf ja auch noch kommen können. Insbesondere weil ich diese Möglichkeit kannte. Was solls, vielen Dank für den Tipp. Ich kann aktuell nicht sagen, ob der fehlerhafte DC mal die PDC Rolle hatte. Auszuschließen ist das allerdings nicht. VG Jimmyone

Moin, vielleicht hat jemand einen heißen Tipp, wie ich dem folgenden Problem weiter begegnen könnte... Es fing damit an, dass ein SQL Server nicht mehr per SSMS erreichbar war. Wir nutzen Kerberos an dieser Stelle. Die Untersuchungen zeigten, das Problem entsteht durch Timedrifting. Eigentlich dürfte es das gar nicht geben. Wir haben in der Vergangenheit über zwei GPOs eine Festlegung Domänenweit definiert. Auf Basis der Doku von damals, haben zu dieser Zeit alle DCs die richtigen Zeitdaten empfangen. Dabei wird u.a. per WMI die PDC Rolle erfasst und diese erfragt bei pool.ntp.org die aktuellen Zeitdaten. Eine zweite GPO gibt diese an alle Systeme weiter bzw. legt die Art des Sync fest. Bisher klappte das prima. Ein DC empfängt jedoch keine Zeitdaten mehr. Ein Resync Befehl meldet das entsprechend. Ein Query auf den peer vermeldet, dass er keinen entsprechenden Host mehr zur Abfrage hat. Die anderen DCs orientieren sich jedoch an der PDC Rolle sprich haben diesen als Zeitgeber. Eine RSOP Auswertung liefert für diesen fehlerhaften DC den Hinweis, dass er das GPO Objekt zieht und auch entsprechend synchronisieren sollte. Ein FSMO Query meldet auf dem betreffenden DC auch das richtige System als PDC. Die Vererbung der GPOs auf dem DC Container passt ebenfalls. Die Netzwerker melden, dass es keinen Firewall Blocker gibt. Wir haben das damals so gemacht, weil wir mit dem Thema nie wieder etwas zu tun haben wollten Hat ja gut geklappt. Hat jemand eine Idee, wie wir dem Thema weiter begegnen könnten? LG Jimmyone

Moin, das geht über folgenden Pfad: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections Hier gibt es einmal: Limit number of connections und: Restrict Remote Desktop Services user to a single Remote Desktop Services session auf Deutsch dann entsprechend anders benannt. Mit diesen beiden Elementen kannst Du das steuern. Die GPO musst Du dann nur entsprechend über die Gruppe steuern.

Nein, das geht ja nicht. Das memberOf Attribut ist ja nicht verfügbar. Sonst hätten wir das mittels dynamischer Gruppen so umgesetzt, wie beschrieben. Siehe die Anforderung an das Azure AD Team: Dynamic Groups: Member of group – Customer Feedback for ACE Community Tooling (azure.com)

Hey, Benutzer können keine Gruppen oder Teams erstellen, also die Gruppen dahinter sind von uns erzeugt. Die Frage kann ich aber mit Ja beantworten. Mitglieder der on-premise Gruppe sollen Mitglieder dieses Teams werden.

Hi, eigentlich trivialer. Es geht um Zugehörigkeit in MS TEAMS - Teams. Wer in Gruppe XY ist, ist auch im Team in Teams.