MHeiss2003

Hallo Silvio, Ja, ich habe die Lösung finden können. Das Problem war, dass mein Konto in unserem Microsoft Tennant Gruppenzuweisungen hatte, die entfernt werden mussten. Diese Gruppenzuweisungen erfolgten im Rahmen der Konfiguration des Microsoft Partnerportals und der Zuweisung von Berechtigungen an Endkunden über GDAP. Genaues Vorgehen: 1. Prüfung und Bereinigung der Gruppenzugehörigkeiten des betroffenen Kontos im eigenen Tennant 2. Löschen des Gastkontos, das auf dieselbe E-Mail-Adresse lautet, im Kunden Tennant 3. Neuanlage des Gastkontos im Kunden Tennant 4. Wartezeit einplanen, bevor der Zugriff getestet wurde (bei mir hat es bestimmt 1 Stunde gedauert) In dem Zuge habe ich bei uns in der Firma das Partnerportal Management auf eine andere E-Mail-Adresse gelegt und gleichzeitig die Zuweisungen der Benutzer zu den Gruppen neu angelegt, das ist optional. Aufräumen gehörte hier zu den Hauptaufgaben, denen ich mich gleich angenommen hatte. 😉 Grüße Mario

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.