Gerber

Moin zusammen, ein kurzes Feedback von meiner Seite: Ich habe es nun zunächst so umgesetzt, dass die Exchange Online Benutzer momentan noch auf den lokalen "PF" zugreifen, was alles perfekt funktioniert. Jetzt am Wochenende wollte ich ein ersten Test Sync der PF Struktur durchführen. - Ich muss dazu sagen, die Struktur hat 8000 PF Ordner, was eine doch krassere Ordnerstruktur ist. - Insgesamt ist der PF Ordner 23 GB groß. - Keiner der PF Ordner ist Mail Enabled. ############ Ich habe wie von MS beschrieben alle notwendigen Schritte durchgeführt. Ich habe alle "/" und "\" ausgetauscht, so dass diese nicht mehr im Namen vorhanden sind. Nun habe ich per Script die Mailboxen erstellt und den ersten Sync gestartet. Folgenden Fehler erhalte ich beim Synchronisieren nach M365: Hat jemand eine Idee hierzu oder hatte einmal bereits solch einen Fehler? Danke im Voraus. Grüße Phil

Gibts News?

Hey Thomas, Alles klar. Bleibt den die Immutable ID beim Cloud Benutzer vorhanden oder ändert sich diese? Gibt es weitere Cloud Benutzer mit der gleichen Immutable ID? Gibt es eventuell gleiche Sourche Anchors aus dem lokalen AD? Für mich sieht es immer mehr nach dem Problem (von mir oben beschrieben) aus. Wenn neue User bereits diesen Fehler aufweisen, hat es definitiv nicht mit dem klonen am Hut. Eher mit einem der oben genannten Attribute: Durch das klonen deiner Server (mehrfach), kann es allerdings schon ganz gut sein, dass du irgendwo einen doppelten Eintrag vorhanden hast und somit Azure AD keinen Sync vornimmt. ProxyAddresses UserPrincipalName Hast du einmal intern das FixTool bemüht? Nochmal: Was sagt der Azure AD Synch Health Monitor? Edit: Kurzer Nachtrag. Hast du mal geprüft ob die Funktion "Identitätssynchronisierung und Resilienz bei doppelten Attributen" bei den AD Connect Clients aktiviert ist? Somit würden Fehler zunächst übersprungen werden und isoliert. Danach bekommt der Admin eine E-Mail zum Fehler oder kann im Health Monitor den Fehler sich genauer ansehen. Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency Grüße Phil

Ein kurzes Edit: Waren die Benutzer schon einmal mit dem Azure AD Synchronisiert? Wurden bei den lokalen Benutzern welche einen Fehler verursachen lokal etwas geändert? Eventuell kannst du ja wie oben beschrieben nochmals die genaue Fehlermeldung posten und beschreiben was du in welcher Reihenfolge gemacht hast. Aus meiner Erfahrung kommt der Fehler "AttributeValueMustBeUnique" am häufigsten, wenn zwei Objekte mit verschiedenen Source Anchors irgendwo den gleichen Wert im Attribut haben. z.B. proxyAdress oder UserPrincipalName. Ebenso können gleiche Aliase zu Problemen führen. Ich würde ebenfalls einmal das IdFix Tool in deiner Umgebung laufen lassen um solche Fehler zu finden. Diese hatte ich vergesse dir mit an die Hand zu geben. Grüße Phil

Hi, naja ich muss leider sagen, dass du mit den Informationen ziemlich sparsam umgehst. Vllt mal ein wenig mehr Infos: - Handelt es sich um komplett neue Benutzer - Benutzer bereits in M365 angelegt - Was hast du jetzt gemacht? Etc etc Edit: Was sagt denn der Azure Active Directory Connect Health im Azure AD?

Hey zusammen, wie der Titel schon sagt geht es um eine Migration von Exchange 2016 nach M365. Ich habe bereits mehrere ONPremise Migrationen hinter mir und auch schon sehr viele Migrationen in die Cloud. Nun wie es im Titel steht geht es hier bei meiner Frage im Detail um die Public Folders. Bisher hatte ich bei den Migrationen in die Cloud immer recht wenige Public Folder, so dass ich diese per PST Export Import migriert habe. Jetzt bin ich allerdings an einem Punkt, bei dem die Public Folder Struktur doch ziemlich groß ist und ich gerne die Batch Migration nutzen würde. Hat jemand von euch Erfahrungen mit der Migration der Public Folder in die Cloud über die von MS bereitgestellten Scripte? Hybrid Konfiguration - Full ist bereits aufgebaut und Funktionsfähig. Fragen: - Wie oben beschrieben "Erfahrungen" eurer Seits? - Wie ist das beste vorgehen. Es gibt ja die Möglichkeit von der Cloud auf die OnPremise Public Folder zuzugreifen oder anders herum nur dürfen die Public Folder nur an einer Stelle sein. Sollten also alle Benutzer-Postfächer zunächst in die Cloud migriert werden und zum Abschluss die Public Folder? - Ich bin mir gerade nicht sicher ob es sich hier um das gleiche handelt. Microsoft beschreibt einmal eine Synchronisation und einmal eine Migration der Public Folder im Technet. Mein Plan wäre so gewesen: Benutzer Postfächer migrieren. Zugriff von Cloud auf lokale Public FOlder bereitstellen und an einem weiteren Abend oder Wochenende die Public FOlder zwecks Downtime migrieren. Danke euch Grüße Phil

Bitte gib kurz Rückmeldung ob es geholfen hat. Danke. Grüße Phil

Da muss ich NorbertFe leider Recht geben. ... Na dann musst du dir mal die Logs vom AzureAD Sync genau anschauen und nachsehen was er anmeckert. Es gibt einige Fehler welche unter diese Fehlermeldung fallen. Im NOrmalfall solltest du mit einem Hard Match klarkommen: https://docs.microsoft.com/de-de/archive/blogs/praveenkumar/how-to-do-hard-match-in-dirsync und hier: https://docs.microsoft.com/de-de/archive/blogs/praveenkumar/how-to-do-hard-match-part-2

Hey Defenders, soweit ich weiß wird die SID immer benötigt, genau aus deinem genannten Grund, da die SID nun einmal die Benutzer im AD verankert. Du musst wohl per Powershell Hand anlegen und die Attribute ausgleichen/angleichen. ## Kommt der Fehler bei allen Postfächern? Grüße Phil

Gelöst: zu 1.) Es wird direkt der Broker per Farmname angesprochen, welcher anhand der Sammlung die Sessions verteilt Registry Eintrag muss für ältere Systeme gesetzt werden. zu 2.) GPO ist nicht mehr notwendig. Hier hat es mir im Gegenteil Probleme gemacht. Ein Problem hatte ich noch mit dem Reg Key in Verbindung mit dem Farmname. Im Server Manager hieß die Farm "RDS-Farm", allerdings hieß diese tatsächlich RDS_Farm. Grüße Phil

Hi zusammen, ich bin gerade dabei zum Test eine kleine RDS Farm mit WS2019 aufzubauen. Es sollen keine Remote Apps genutzt werden. Die Server sind alle in einer Sammlung vorhanden und der Endbenutzer soll sich per mstsc auf die Farm verbinden können (ohne angepasste RDP Datei). Folgendes Szenario: 1x - srv-broker-01 = SessionBroker + LizenzServer + WebAccess 1x - srv-sess-01 = Session Host 1x - srv-sess-02 = Session Host ---------- Ich kenne es von den WS2008 Zeiten so, dass ein RoundRobin im DNS konfiguriert werden muss. Alle Session Hosts mussten als Host A Eintrag im DNS vorhanden sein. Z.B: rds-farm = srv-sess-01 rds-farm = srv-sess-02 Der Session Host (welcher vom Client angesprochen wurde) hat dann den Broker kontaktiert, welcher die Verbindung auf Sess-01 oder Sess-02 verwiesen hat. ------------------------ Nun habe ich einiges im Netz gelesen, dass mit WS2019 das RoundRobin nicht mehr notwendig ist und der Session Broker direkt angesprochen werden kann, woraufhin dieser die Verteilung an die Session Hosts vornimmt. Hat bereits jemand von euch eine RDS Farm mit WS2019 Servern eingerichtet? 1.) Was ist an dem Satz oben mit den DNS Einstellungen dran? Muss weiterhin der Session Host angesprochen werden, welcher dann den Broker kontaktiert? 2.) Werden weiter GPOs benötigt? Z.B. muss den Session Host Servern angegeben werden (per GPO) wie die Farm lautet und wer der Broker ist oder wird dies anhand der Sammlung automatisch erledigt und der Session Host weiß dies, da er in einer Sammlung aufgenommen wurde? Danke euch im Voraus. Grüße Phil

Gut ist das ja beides funktioniert und nicht falsch ist. Somit kann jeder machen wie er es für richtig hält

Auch hier hast du natürlich Recht. Man findet es halt oft in Tutorials oder Anleitung, dass der SCP auf autodiscover.domain.de konfiguriert wird

Danke für die ausführliche Antwort Das CAS Array hat mich irgendwie durcheinander gebracht ... Aber das bringt bei mir Licht ins dunkle. Wenn ich mich auch richtig erinnere durfte das Cas Array (Falls eingerichtet) auch gar nicht den gleichen Namen wie z.B: Annywhere besitzen, da es sonst zu Problemen geführt hatte. Danke für die Antworten. Grüße Phil Alles klar. Hast du natürlich Recht. Hier schreibst du den SCP an outlook.domain.de anpassen. Nutzt du hierfür nicht autodiscover.domain.de ?

Ich dachte immer um eine Koexistenz zwischen Exchange 2010 und 2016 herzustellen müssen beide Exchange Server die gleichen URls + Zertifikate besitzen? Und weil in vielen Migrationsanleitungen beschrieben wird, dass vor einer Migration auf Split DNS umgestellt werden sollte. Und aus diesem Grund frage ich ja auch nach eurem genauen vorgehen in solch einer Situation: Bedeutet also: 1.) Exchange 2016 aufsetzen 2.) Split DNS mit Autodiscover und mail.domain.de konfigurieren 3.) Einträge auf den Exchange2016 zeigen lassen (oder sollten diese bis zur Migration auf den EX2010 zeigen, obwohl dort die URLs nicht konfiguriert sind?) 4.) Authentifizierung der virtuellen Verzeichnisse mit dem EX2010 abgleichen Die Postfächer sollen dann bis zum Wochenende noch auf dem EX2010 liegen bleiben, weswegen auch der EX2016 Proxy spielen soll. 5.) SCP vom neuen EX 2016 auf Null setzen -> ist dies notwendig? 6.) Nach der MIgratoin den SCP auf autodiscvoer.domain.de setzen Outlook Profil wird vom Lokalen FQDN automatisch an mail.domain.de angepasst? Grüße Phil

Hey Norbert, danke dir. Okay kannst du mir vllt noch die Frage beantworten wie du dann in so einem Fall vorgehst, wenn der Ex2010 kein SPLITDNS konfiguriert hat und du migrieren willst? Also welche Reihenfolge du wählst? SplitDNS Konfiguration auf dem Ex2010 -> Koexistenz aufbauen -> Postfächer migrieren -> Outlook Profil neu erstellen? Was meinst du hiermit genau? Cas Array benötige ich doch, wenn ich vom lokalen FQDN des Exchange Servers wegkommen will und sich Outlook z.B. mit mail.domain.de verbinden soll. Grüße Phil

Hi zusammen, ich habe eine kurze Verständnisfrage in Bezug auf einen Exchange Server 2010 und das CAS Array. Das CAS Array wird im Exchange 2010 benötigt um vom lokalen FQDN des Exchange Servers wegzukommen und die Outlook Verbindung auf z.B. den Servernamen mail.domain.de zu konfigurieren. Oder natürlich um Lastenausgleich zu konfigurieren. Nun ist ein Exchange 2010 Server vorhanden, welcher kein CAS Array und kein SPLIT DNS konfiguriert hat und somit auf den lokalen FQDN "server1.domain.local" verweißt. Es soll eine Migration von Exchange 2010 auf 2016 durchgeführt werden und danach auf 2019. Fragen hierzu: 1.) Nach welcher Reihenfolge geht ihr in Bezug auf die DNS Einstellungen vor, wenn noch kein SPLIT DNS konfiguriert ist und ihr migrieren müsst? Also z.B. zuerst SPlitDNS auf EX2010 + CAS Array konfigurieren, neue Outlook Profile und dann die Migration angehen? 2.) Muss für eine Migration das Cas Array auf dem alten Exchange 2010 konfiguriert werden, bzw. für eine Koexistenz? 3.) Angenommen es werden alle Dienste auf "autodiscover.domain.de" und "mail.domain.de" konfiguriert und kein CAS Array erstellt. Gibt es dann Probleme mit dem Zertifikat im Outlook? Es wird natürlich ein neues Zertifikat für die beiden genannten Domains erstellt, allerdings verbindet sich Outlook ja noch auf den lokalen FQDN. Der SCP würde man in diesem Fall dann vorerst auf dem lokalen FQDN lassen und erste wenn die Postfächer auf dem EX2016 sind auf mail.domain.de konfigurieren. Es handelt sich um 15 Postfächer. Vorerst soll autodiscover und mail.domain.de auf den neuen Exchange 2016 zeigen, welcher Proxy für die auf Postfächer auf dem Exchange 2010 spielt. Am Wochenende werden dann die Postfächer auf einen Rutsch auf den Exchange 2016 migriert und der lokale SCP vom lokalen FQDN auf mail.domain.de umgestellt. Danke euch Grüße Phil

Da hast du völlig Recht. Aus dem Grund ist natürlich ein WSUS sehr sehr Sinnvoll. Grüße Phil

Ich habe es nun einfach mal ein zwei Tage testen lassen. Es sind Geräte dazugekommen, Somit sieht es aus, dass es mit der Wartezeit gut funktioniert hat. Naja eigentlich nur wann die Updates geladen und installiert werden sollen. Grüße Phil

@testpersonen Danke dir für die Idee mit dem Powershell Script. Danke dir für die Info . Sogar Tippfehler werden direkt angemerkt . Naja wenn noch kein WSUS vorhanden ist wird es momentan über die GPO gesteuert ... Mir ist schon klar was ein WSUS macht, keine Angst ... Grüße Phil

Danke euch für die Unterstützung. Euren Antworten gibt es natürlich nichts hinzuzufügen . Gerne würde ich dies natürlich auch über z.B. einen WSUS machen, aber für Verteilung einer einzigen Software bin ich mir momentan noch nicht sicher ob ich einen WSUS wirklich aufsetzten will. Würdet ihr dann den WSUS Server nur zur Softwareverteilung nutzen und weiterhin die Updates übers Internet ziehen lassen? Grüße Phil

Kurzes EDIT: Es gibt über die Webiste -> Websiteinformationen -> Alle Websiteninformationen anzeigen -> Speichermetriken die Möglichkeit die Sites, bzw. Dokumente der Sites zu browsen und nachzusehen, was genau den Speicher in der Site beantspruch...

Alles klar ich werde die Tests fahren, danke dir.

@Sunny61 Danke dir für die Antwort. Jetzt vllt noch eine blöde Frage: Sollte für die Wartezeit eine eigene GPO konfiguriert werden oder in die GPO mit der Verteilung mit eingefügt werden? Wenn ich nun die GPO mit der Wartezeit konfiguriere, wird diese überhaupt gezogen? Wenn die bisherige GPO für die Computerrichtlinie nicht gezogen wird, wird doch auch diese für die Wartezeit nicht gezogen, oder? P.S. ES geht hier wirklich nur um eine MSI. WSUS wäre hier zu viel des guten.

Hi zusammen, ich habe eine kleine Herausforderung mit einer GPO. Ich will über die GPO ein MSI Paket von TrendMicro an die Clients verteilen. Nun ist es so, wenn ich den PC Neustarte wird die GPO nicht angewandt. Sobald ich allerdings ein "gpupdate /force" auf dem PC durchführe kommt sofort die Meldung, dass neue Daten bereit stehen und ein Neustart angefordert wird. - Die GPO ist auf der richtigen OU verknüpft (Clients) - Die Authentifizierten User haben lese REcht auf die GPO - Die einzelnen PCs auf denen TM installiert werden soll ist in einer Sicherheitsgruppe und hat das GPO übernehmen Recht Dies funktioniert ja auch alles sauber, wenn ich ein gpupdate durchführe. Hat jemand eine Idee, wieso es erst nach einem gpupdate und nicht nach einem Neustart vom Rechner funktioniert? Danke euch. Grüße Phil