MHeiss2003

Nachdem ich etwas mehr über "External Identities" gelesen habe, wurde von mir unter "Mandantenübergreifende Zugriffseinstellungen" die Organisation des Gastkontos eingetragen, auf der Seite der Organisation des Gastkontos wurde dies ebenfalls erledigt. Wenn ich die Sharepoint Diagnose Überprüfen des Benutzerzugriffs starte, die URL der Sharepoint Seite und die E-Mail-Adresse des Gast Kontos eintrage, erhalte ich folgenden Hinweis/Fehler: Der Benutzer hat nicht die Berechtigung "Öffnen", Die vorgeschlagenen Behebungen des Problems 1. Zugriff verweigert oder Sie benötigen eine Berechtigung in SharePoint Online und OneDrive 2. Freigeben einer Website bringen leider keine Lösung des Problems. Der Benutzer ist in allen vier Mitgliedsgruppen: Websiteadministratoren, Websiteeigentümer, Websitemitglieder und Websitebesucher Zumindest erhalte ich nun eine Meldung beim Zugriff auf die Sharepoint Webseite, die lautet: Sie benötigen eine Berechtigung für den Zugriff auf diese Webseite. Wenn ich nun die Berechtigung anfordere klicke, kann ich auf der Sharepoint Website diese Anforderung sehen und genehmigen. Aber auch das hat keinen Effekt. Die Verweigerung wegen Berechtigungsproblem bleibt bestehen.

Sharepoint Online Lizenzen sind über M365 Business Premium beim Gastbenutzer vorhanden.

Hallo liebe community, ich habe folgendes Problem, wenn sich ein bestimmter externer Gast, der eine reguläre Einladung erhalten und angenommen hat und nie im Azure AD angelegt war, an Sharepoint Online anmelden will: Das hat leider nicht geklappt. Die Anmeldung funktioniert im Moment leider nicht. Wir arbeiten dran! Bitte versuchen Sie es später erneut. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihr Supportteam, und geben Sie diese technischen Details an: Korrelations-ID: xxxxxxxxxxxxxxxxxxxxx Datum und Uhrzeit: xxxxxxxxxxxx URL: SHAREPOINTURL Benutzer: BENUTZERNAME#EXT@TENANTDOMAINNAME Problemtyp: Unbekanntes Problem Betrachte ich mir die Eigenschaften im Azure zu diesem Benutzer fällt mir auf, dass dieser zwei zugewiesene Identitäten hat: 1. Anmeldetyp: federated, Aussteller: ExternalAzureAD, Zugewiesene Aussteller-ID: LEER 2. Anmeldetyp: userPrincipalName, Aussteller: TENANTDOMAINNAME, Zugewiesene Aussteller-ID: BENUTZERNAME#EXT@TENANTDOMAINNAME Was kann ich tun? Danke und Grüße Mario

Danke Norbert für den Link!

Guten Morgen liebe community Mitglieder, ich habe das Phänomen, dass nur bei der Bearbeitung von Benutzerobjekten der Attribut Editor angezeigt wird. Aus meiner Browser Favoriten Liste habe ich diesen Eintrag aus dem Jahr 2025 gefunden: https://itblog.wildi.dk/?p=1422 Allerdings bringt das nicht die Lösung. Befolge ich diese Anweisungen, habe ich die Attribut Editor Registerkarte 3x in einem Benutzerobjekt, allerdings weiterhin keine Anzeige in allen anderen Objekten, wie Computer oder OU's. Habt Ihr noch eine Idee oder einen hilfreichen Link? Grüße Mario

Hallo liebe community, wer kann mir sagen, wie ich in M365 den persönlichen Onedrive Speicher eines Benutzers löschen kann, ohne diesen Benutzer neu anlegen zu müssen? Danke Mario

Danke für den Tipp. VM wäre eine Alternative, ich schlafe nochmal darüber... Ich teile Deine Einschätzung. Nie im Leben hätte mich das Thema beschäftigt, wenn ich nicht zufällig darauf gestoßen wäre, dass es im Eventlog eine Warnung zu einer GPO gab, die sich eben genau auf die Netzlaufwerkproblematik bezog. Auf allen anderen Maschinen habe ich das Problem nicht.

Es gibt einige Kollegen die über den Explorer Freigaben über den ALIAS Namen ansteuern. Grund dieser Einrichtung war ein Serverwechsel und GPO basierte Netzlaufwerkverbindungen. Es musste dann nur der ALIAS im DNS angepasst werden. Danke Jan!

Danke Evgenij für Deine schnelle Antwort. Folgendes habe ich am DC geprüft: netdom verify COMPUTERNAMEDC /domain:DOMAINNAME Als Ergebnis erhalte ich: Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Der Befehl wurde nicht ordnungsgemäß ausgeführt. Prüfe ich auf dem DC mit diesem Befehl einen anderen Computernamen, erhalte ich folgendes: Der sichere Kanal von GEPRÜFTERCOMPUTERNAME zur Domäne DOMAINNAME wurde überprüft. Die Verbindung besteht mit Computer \\GEPRÜFTERCOMPUTERNAME .DOMAINNAME. Der Befehl wurde ausgeführt. Ping auf die Domäne lös die IPv4 des DC auf. Wenn das ein HOST Eintrag sein sollte, dann nein. Geprüft habe ich mit setspn.exe -L COMPUTERNAMEDC Nein, ist er nicht. Nein, ist er nicht.

Hallo zusammen, ich habe ein kurioses Phänomen und hoffe, dass Ihr Rat wisst. Kleines Netzwerk mit Windows Server 2022 und paar Clients im selben Netzwerk. Sobald ich mich auf dem einzigen DC mit einer Netzwerk-Freigabe, die auf dem DC erstellt ist, über einen ALIAS HOST-Namen, der nicht dem Computernamen entsprechen darf, verbinden will, erscheint das Fenster Netzwerkanmeldung. Nach Eingabe der korrekten Daten, erhalte ich trotzdem keinen Zugriff. Verwende ich die IP-Adresse oder den HOSTNAMEN des DC, dann funktioniert es. Getestet habe ich PING und NSLOOKUP auf den ALIAS HOST-Namen. Beide Tests haben als Ergebnis die korrekte IPv4-Adresse des HOSTS. Ebenfalls getestet habe ich die Anmeldung eines zweiten Admin-Benutzers auf dem DC, was dasselbe Fehlerbild zeigt. Von allen anderen Rechnern in diesem Netzwerk funktioniert der Zugriff tadellos. Grüße Mario

Zumindest musste ich am Wochenende keine bezahlte Sonderschicht schieben.

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: Die Zugriffe laufen wieder. :-)

Danke Evgenij für Deinen Hinweis. Das Ergebnis der Abfrage lautet: Invoke-RestMethod : Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.. In Zeile:1 Zeichen:1

Danke, der Vorfall ist mir bekannt und dieser ist auch noch offen. Allerdings bekomme ich nun eine Verbindung, nur nicht mehr aus dem betroffenen internen Netzwerk. Deshalb ist mein Gedanke, dass es doch nicht mehr an MS liegen könnte.

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

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.

Interessanter Ansatz! Über Domänen-/OE-Filterung?

Hallo Jan, mit Dirsync abschalten im Tennant meinst Du? Set-MsolDirSyncEnabled -EnableDirSync $false Danke für Deine erhellende Eingebung! Was genau meinst Du mit Regeln?

Danke.

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.

Danke für Deine Akzeptanz bzgl. des Grundes! Naja, der externe bin ich. Mir selber möchte ich ungern eine Schulnote ausstellen...

Das alte AD ist kompromittiert worden.

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

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ß

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.