Jump to content

MHeiss2003

Members
  • Gesamte Inhalte

    338
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von MHeiss2003

  1. Danke für Eure sinnvollen Hinweise.

     

    Es ist wie verhext. Ohne, dass ich etwas verändert habe, bekomme ich seit ca. 10 Minuten plötzlich folgendes Ergebnis:

     

    Protocol Url
    -------- ---
    EWS     https://outlook.office365.com/EWS/Exchange.asmx

     

    Dazu habe ich gerade die interessante Parallele bei M365, Vorfall EX1113110, mit Aktualisierung von 17:26 Uhr gelesen:

    Zitat

    We’re investigating reports of continued impact from users in Germany and found a portion of infrastructure that was missed when deploying our initial mitigation steps. We’ve created a new fix to include the missing portion of infrastructure and are testing to confirm it will resolve the issue. Concurrently, we’re adding additional database capacity within the affected infrastructure and we’re seeing service availability recover within our telemetry.

     

    Die Zugriffe laufen wieder. :-)

  2. Hallo zusammen,

     

    folgendes Problem habe ich in einer AD-Domäne. Seit vergangenen Donnerstag, Patchday Microsoft, funktioniert kein Zugriff mehr über Outlook Classic, auch die Neueinrichtung eines Exchange Online Kontos ist in Outlook Classic nicht möglich.

    Der Zugriff über OWA funktioniert intern tadellos. Ebenfalls funktioniert der Zugriff über Outlook Classic und die Neueinrichtung eines Kontos tadellos, wenn die Clients sich außerhalb der internen Domäne und des dazugehörigen Netzwerkes befinden.

    Bei der Umgebung handelt es sich um eine mit HCW nach EXO migrierte Exchange 2019 Umgebung. Der Rückbau der Hybrid Struktur erfolgte, allerdings keine Deinstallation des Exchange onPrem 2019, dieser wurde nur heruntergefahren.

     

    Die Hardware Firewall habe ich ausgeschlossen, da ich testhalber keine Einschränkungen hatte.

    Überprüft habe ich im DNS den autodiscover Eintrag, dieser zeigt nach autodiscover.outlook.com.

    Weiterhin geprüft habe ich am onPrem Exchange den ClientAccessService Eintrag "AutoDiscoverServiceInternalUri", dieser ist leer.

     

    Jetzt fällt mir nichts mehr ein. Im Verdacht habe ich das AD, bin mir aber unsicher.

    Habt Ihr noch eine Idee?

     

    Danke Euch.

    Mario

  3. vor 3 Stunden schrieb NorbertFe:

    Nein, genau das ist dann eben egal wo die Objekte im ad liegen. Ich kann lokal also umstrukturieren, verschieben und umbenennen wie ich will und das hat keinen Einfluss auf den Sync Score der Objekte.

    Wo werden diese Filter gesetzt?

    Hallo zusammen,

     

    kurzes Feedback von meiner Seite: Die Migration konnte ich erfolgreich durchführen.

     

    1. Kontrolle der UPNs und identische Anlage der Benutzer inkl. UPNs im neuen AD des neuen Forests

    2. Deinstallation AADConnect alter Forest

    3. Dirsync abschalten (Wartezeit bis Abschluss einplanen!)

    4. InheritedID aller Objekte im online AD auslesen und zur Sicherheit in eine CSV-Datei exportieren

    5. InheritedID aller Objekte im OnlineAD löschen

    6. AADConnect in neuem Forest installieren

    7. AAD-Sync starten

     

    Die Migration hat damit fehlerfrei funktioniert.

     

    Vielen Dank an Euch!

     

    Gute Nacht.

    • Like 1
  4. vor 3 Stunden schrieb testperson:

    Hi,

     

    in der Theorie sollte der Softmatch über den UPN machbar sein, wenn du im Tenant vorher den Dirsync abschaltest. Da in meinen ersten Tests der Softmatch nie wollte, mache ich seid dem immer den Hardmatch über die "immutableId". Den Wert der "immutableId" der online User kannst du allerdings auch nur ändern, wenn der Dirsync abgeschaltet ist bzw. wenn du im alten AD den User aus dem Syncscope nimmst und diesen online somit löscht. Nach dem Widerherstellen aus dem Papierkorb wäre das dann ein "online only User" und du könntest die "immutableId" setzen.

     

    In grob:

    # Im on-premises AD:
    $ObjectGuId = (Get-ADUser -Identity "username").ObjectGUID
    $immutableID = [System.Convert]::ToBase64String($ObjectGuId.ToByteArray())
    $immutableID
      
    # Entra Id:
    Set-AzureADUser -ObjectId "<User>@<Domain>.<Tld>" -ImmutableId "$immutableID"

     

    HTH

    Jan

     

    Hallo Jan,

     

    mit Dirsync abschalten im Tennant meinst Du?

    Set-MsolDirSyncEnabled -EnableDirSync $false

     

    Danke für Deine erhellende Eingebung! ;-)

     

    vor 3 Stunden schrieb NorbertFe:

    Das was Jan sagt paßt schon. Gleichzeitig sollte man dann beim Neueinrichten des AADC darauf achten, die Regeln gleich so hinzustellen, dass man explizit einzelne User filtern kann. Und dann kann man prüfen ob der Softmatch zum Tragen kommt.

    Das ist natürlich ungünstig, denn die neuen brauchst du gar nicht erst und die kannst du erstmal wieder entfernen (raussynchen).

    Was genau meinst Du mit Regeln?

  5. Gerade eben schrieb Nobbyaushb:

    Spätestens jetzt stellt man fest, ob das Backup was taugt und sauber ist

    Trotzdem solltest du ggf. einen weiteren hinzuziehen, alleine ist das schwer...

    Backups vom lokalen System und von M365 sind vorhanden.

    Unterstützung durch die IT beim Kunden ist vorhanden. Die haben alles bereits neu angelegt und bereitgestellt. Es bleibt der Punkt mir dem AD-Sync übrig.

    Kannst Du mich unterstützen? Wenn nein, welchen Fachmann benötige ich Deiner Meinung nach? Wie gesagt, ich habe ein Testszenario aufgebaut, das ich hierfür bereits im LAB habe. Mir fehlt, so glaube ich, der richtige Hinweis, wie dieses Szenario in M365 umgesetzt werden kann, damit ich zeitsparend unterwegs sein kann.

  6. Hallo liebe community Mitglieder,

     

    meine Frage ist, wie würdet Ihr die Azure AD Synchronisation umziehen und migrieren, wenn folgendes Szenario gegeben ist:

     

    1. Die Windows Domäne bleibt vom Namen her gleich

    2. Die Windows Domäne inkl. 60 Benutzern und 12 Gruppen wird in einer neuen Struktur manuell neu erstellt (ein Trust zwischen alt und neu ist nicht gewünscht)

     

    Gedacht hatte ich mir, dass der UPN als Attribut ausreichen würde, um AAD-Sync 1:1 umziehen zu können, allerdings habe ich das in einem Testszenario nicht so bestätigen können. Nachdem ich auf dem alten AAD-Sync Server der alten Domäne den Stagingmodus aktiviert und auf dem neuen AAD-Sync Server in der neuen Domäne den Stagingmodus deaktiviert hatte, wurden nach dem ersten Sync Verzeichnisfehler gemeldet und alle Benutzer nach dem Schema "<OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain>.onmicrosoft.com" neu angelegt. Nun habe ich die Benutzer des alten AAD-Sync und des neuen AAD-Sync in einem gemeinsamen Verzeichnis.

     

    Danke und Grüße

    Mario

  7. Guten Abend zusammen,

     

    auf einer virtuellen Maschine Hyper-V habe ich das Problem, dass ich mich nicht mehr lokal anmelden kann. Zwar wird das Tastaturkommando Strg-Alt-Entf entgegen genommen, aber dann drehen sich die Windows Punkte im Kreis und nach einer Wartezeit kommt dann wieder der Anmeldebildschirm. Wenn ich mich per RDP anmelde, kann ich mich normal anmelden, auch per mstsc /admin Kommando.

    Versucht habe ich bisher folgendes:

    1. Switch Port entfernt und neuen hinzugefügt

    2. Dienste kontrolliert und keine Auffälligkeiten entdeckt; alle Dienste, die auf automatisch stehen, sind gestartet

     

    Wonach müsste ich suchen?

     

    Auf dem Server wurde heute eine Software "Authentication Subsystems" vom Herausgeber "Seiko Epson Corporation" installiert. Mir ist nicht bekannt, was die Software macht.

    Weiterhin ist mir aufgefallen, dass der Windows-Biometrie Dienst auf automatisch starten stand, habe diesen auf manuell gesetzt.

     

    Danke und Grüße

    Mario Heiß

  8. Zitat
    vor 24 Minuten schrieb NorbertFe:

    Warum dann migrieren? :) Aber muss wohl jeder selbst merken.

     

    Der Gedanke war: Erst die Migration nach M365 sauber durchbekommen, dann die Planung der Gruppen und eine Migration innerhalb des Ökosystems. Als Anleitung dient im zweiten Schritt Verwenden der Batchmigration zum Migrieren von Exchange Online öffentlichen Ordnern zu Microsoft 365-Gruppen

    Eine Rolle spielte auch die noch ausstehende Entscheidung zu den Gruppenkonfigurationen.

  9. Guten Morgen Jan,

     

    danke für Dein aufmerksames Code-Auge!

     

    vor 52 Minuten schrieb testperson:

    Eine andere Frage wäre, was habt ihr denn alles in den Public Folder drin? Kannst du nicht von PFs wegmigrieren?

     

    Gruß

    Jan

     

    Es sind insgesamt 10 Gigabyte an Daten vorhanden. Diese sollen per "Drag-and-Drop" migriert werden, wenn die Öffentlichen Ordner auch in der Cloud liegen, wie es bereits bei allen Postfächern ist. Wir werden von den PFs kurzfristig weggehen.

     

    Grüße

    Mario

  10. Guten Abend,

     

    gemäß der Anleitung von MS zur Migration von Öffentlichen Ordnern Migrieren von öffentlichen Exchange Server-Ordnern zu Exchange Online mithilfe einer Batchmigration, bin ich bei Schritt 4 angelangt und erhalte in der Powershell Online einen Fehler nach folgenden Eingaben:

    $mappings = Import-Csv map.csv
    $primaryMailboxName = ($mappings | Where-Object FolderPath -eq "\" ).TargetMailbox;
    New-Mailbox -HoldForMigration:$true -PublicFolder -IsExcludedFromServingHierarchy:$false $primaryMailboxName ($mappings | Where-Object TargetMailbox -ne $primaryMailboxName).TargetMailbox | Sort-Object -unique | ForEach-Object { New-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false $_ }

     

    Der Fehler sieht so aus:

    New-Mailbox: A positional parameter cannot be found that accepts argument 'Mailbox2'.

     

    In der map.csv sieht es wie folgt aus:

    "TargetMailbox","FolderPath"
    "Mailbox1","\"
    "Mailbox2","\NON_IPM_SUBTREE"

     

    Hängt das eventuell mit dem Subordner NON_IPM_SUBTREE zusammen?

     

    Habt Ihr eine Idee, was ich übersehe?

     

    Danke und Grüße

    Mario

  11. vor 18 Minuten schrieb mikro:

    Und alle deine Custom Konnektoren sind auch von der TransportRole her auf FrontendTransport eingestellt?

    Ich habe keine Custom Connectoren im Einsatz, ist alles Standard Einrichtung Exchange.

    vor einer Stunde schrieb NorbertFe:

    Eine swingmigration oder eine Desaster recover Installation dürfte schneller sein. Wenn’s tatsächlich ein Sicherheitsthema ist, kann man später immer noch suchen. 

    Die entscheidende Frage wird sein, auf wann ich zurückgehen muss, wenn es ein Security Thema ist.

    Irgendwie werde ich den Verdacht nicht los, dass es hier einen Zusammenhang zu dem heutigen weltweiten IT Problem gibt.

  12. vor 5 Minuten schrieb mikro:

    Was sagt das Eventlog? Da muss doch was zum Transportdienst geloggt werden...

     

    1. MSExchangeTransport, 1018, SmtpReceive: The address is already in use. Binding: 0.0.0.0:2525.

    2. MSExchangeTransport, 1019, SmtpReceive: Failed to start listening (Error: 10048). Binding: 0.0.0.0:2525.

    3. MSExchangeTransport, 1036, SmtpReceive: Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly

    4. MSExchangeTransport, 26015, TransportService: EdgeTransport requested that the MSExchangeTransport process terminate with an unhandled exception due to TCP/IP-Socketfehler. Der Dienst wird beendet..  Call stack:    bei System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
       bei System.Environment.get_StackTrace()
       bei Microsoft.Exchange.Transport.Main.Program.StopService(String reason, Boolean canRetry, Boolean retryAlways, Boolean failServiceWithException)
       bei Microsoft.Exchange.Transport.Components.StopService(String reason, Boolean canRetry, Boolean retryAlways, Boolean failServiceWithException)
       bei Microsoft.Exchange.Protocols.Smtp.Receive.SmtpInComponent.OnTcpListenerFailure(Boolean addressAlreadyInUseFailure)
       bei Microsoft.Exchange.ProcessManager.TcpListener.StartListening(Boolean invokeDelegateOnFailure)
       bei Microsoft.Exchange.Protocols.Smtp.Receive.Legacy.SmtpInServer.Initialize(HandleFailure failureDelegate, HandleConnection connectionHandler)
       bei Microsoft.Exchange.Protocols.Smtp.Receive.SmtpInComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState)
       bei Microsoft.Exchange.Transport.Common.CompositeTransportComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState)
       bei Microsoft.Exchange.Transport.Common.CompositeTransportComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState)
       bei Microsoft.Exchange.Transport.Components.Activate()
       bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.RunADOperation(ADOperation adOperation, Int32 retryCount)
       bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.TryRunADOperation(ADOperation adOperation, Int32 retryCount)
       bei Microsoft.Exchange.Transport.Components.ProtectedActivate()
       bei Microsoft.Exchange.Transport.Components.Start(StopServiceHandler stopServiceHandler, Boolean passiveRole, Boolean serviceControlled, Boolean selfListening, Boolean paused)
       bei Microsoft.Exchange.Transport.Main.Program.Run(String[] args)
       bei Microsoft.Exchange.Transport.Main.Program.Main(String[] args)

  13. vor einer Stunde schrieb mikro:

    Mach mal nen ipconfig und schau die die aktuelle IP V6 an danach gehst du im ECP in den DEfault Frontendconnector und unter Bereichsdefinition schaust du welche IPV6 Adresse da drinnen ist, ist die nicht identisch, lösche sie und pack die aktuelle rein.

     

    Hier steht: ::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255

    vor 50 Minuten schrieb Dukel:

    https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/bindings/

     

    Man sollte aber die Bindings direkt in der Übersicht sehen.

    Es gibt keine Bindung zu Port 2525, wobei ich den IIS Workerprozess vorher beendet habe, damit ich den Transportdienst wieder starten konnte.

×
×
  • Neu erstellen...