Candy

Hallo, kleiner anderer Ideenansatz, da wir einen vergleichbaren Fall hatten. Schau doch einfach mal im OWA ob der betroffene User dort alles einsehen kann. Wenn ja, hat es bei uns geholfen den Exchange Cache Modus einmal zu deaktivieren inkl. Outlook Neustart und wieder zu aktivieren. Und schon war alles wieder ersichtlich.

Hallo, LLDP-MED für ARUBA 2530 ist hier ganz gut erklärt. Aruba 2530 switch - LLDP-MED | Wired Intelligent Edge (arubanetworks.com)

Hallo, wenn vom Kunden Wert darauf gelegt wird und es auch bezahlt wird, kann ich nur Patchbox empfehlen. Da habe ich in der Praxis noch nichts vergleichbares besseres gesehen. Kostet aber spürbar Geld. :) https://patchbox.com/de/?utm_term=patchbox&utm_campaign=AA | DE | Patchbox Brand&utm_source=adwords&utm_medium=ppc&hsa_acc=8967533774&hsa_cam=18658190394&hsa_grp=142090782625&hsa_ad=629719422959&hsa_src=g&hsa_tgt=kwd-1412382254141&hsa_kw=patchbox&hsa_mt=e&hsa_net=adwords&hsa_ver=3&gclid=EAIaIQobChMI0siKu-SoggMVG5CDBx1cHw6aEAAYASAAEgJ5YvD_BwE

Ja. Es macht sich das Gefühl breit das der Helpdesk, in welcher Stufe auch immer, gar nicht mehr weiss was dort technisch passiert. Fazit ist, die Backup Strategie mehrfach zu überdenken u. anzupassen. Das mal ein Dienst, oder eine Anwendung in der „heilen MS365 Welt“ nicht funktioniert ist ja technisch völlig normal. Das haben wir bei on premise Systemen genauso. Aber das durch den AD Connect aktiv Benutzer gelöscht werden hat eine neue Dimension! Kaum auszudenken wenn wir eine bidirektionale Synchronisierung gehabt hätten. Das vielleicht restliche technische Vertrauen in MS365 ist dahin. Einfach nur verrückt.

Bin ich völlig bei Dir Norbert, der "System Engineer" wollte die Remote Session gar nicht verlassen, ohne das ich Sterne für ihn vergebe. :/ Klare technische Antworten gab es aber nicht, deswegen auch keine Sterne.

Hallo, ergänzend die heutige Antwort des Managers. Keine Ahnung, was ich davon halten soll. :/ Vielen Dank für Ihre Email Es tut mir leid, dass Sie aufgrund des Backendfehlers Unannehmlichkeiten erfahren haben. Ich möchte Ihnen jedoch versichern, dass der Fehler inzwischen behoben wurde und Sie sich keine weiteren Sorgen machen müssen.

Hallo Community, wie immer hoffe ich auf euer „Schwarmwissen“ und bedanke mich im Vorfeld bei Euch! Kurz zu den Gegebenheiten. Microsoft Domain Umfeld. Viele virtuelle Server. Die Microsoft 365 Umgebung wird eingesetzt inkl. einem eigenständigen VM MS Server 2019 mit installierter Microsoft Azure AD Connect Anwendung. Der genannte MS Server 2019 hat nur die Aufgabe den AD Connect zu bedienen und synchronisiert nur in die MS 365 Welt (z.B. Kennwortänderungen). Der AD Connect läuft seit ca. 3 Monaten. Am 01.11.23 haben wir damit begonnen, für alle Mitarbeiter die Multi Faktor Authentifizierung zu implementieren. Einen Benutzer nach dem anderen. Da auch einige Erklärungen für die Mitarbeiter dazu gehören. Am 01.11.23 haben wir 23 Mitarbeiter mit MFA technisch umgesetzt. Am 02.11.23 kam die erste Nachricht auf unserem „Notkanal“ das keine E-Mail Funktion mehr gegeben ist. Und das Unternehmen von extern nicht mehr erreichbar wäre (E-Mail). Wir schauten uns das MS 365 Admin Portal an und stellten erschreckend fest, dass alle Benutzer, 42 an der Zahl, gelöscht worden sind. Alle Benutzer befanden sich unter „gelöschte Benutzer“. Außer die Benutzer die nicht mit ADC synchronisiert werden ( reine Postfächer usw.). Wir stellten die gelöschten Benutzer wieder her und suchten parallel was dort passiert ist. Im log MS 365 stellten wir fest, dass um 4.39Uhr der AD Connect innerhalb von 1 sec alle 42 Benutzer gelöscht hat. In der AD hat sich nichts geändert. Support Ticket bei Microsoft eröffnet. Es gab ein Telefonat u. der MS Mitarbeiter schaute einmal mit auf das System. Seine Antwort war wie folgt: Vielen Dank für die Zusammenarbeit mit Microsoft Office 365 Support. Die Serviceanfrage wird in unserem System archiviert. Sollten Sie weitere Fragen haben, diese könnte innerhalb der nächsten 7 Tage von portal.office.com wieder eröffnet werden. Problembeschreibung: Wie telefonisch besprochen, das Problem war ein Sonderfall, der wegen der Aktivierung von MFA ausgelöst und von alleine im Server behoben wurde, allerdings passiert es nicht immer. Der Grund dieses Problems ist dass die Server aktuell einige Updates erfahren, was zu Vorfällen bei manchen Diensten führt, die man auch im Admin Center unter Dienststatus sehen kann, diese Vorfälle werden entweder von alleine behoben oder unser Entwicklerteam arbeitet sofort daran, um sie zu lösen. Lösungsschritte: Der Fall von alleine behoben Natürlich geben wir uns mit der Antwort nicht zu frieden. Und haben beim angegebenen MS Manager nochmals eine Anfrage gestellt, um eine technisch plausible Antwort zu erhalten. Antwort steht noch aus... Habt ihr so etwas schon gehabt? Oder einen Ansatz was diesen “Delete ALL” Befehl ausgelöst haben könnte? Danke für eure Unterstützung!

Hallo, nun hat sich dazu bei uns einiges geändert. Und ich dachte ich schreibe euch nun unseren Lösungsansatz u. Umgang. Vielleicht habt ihr auch noch andere Erfahrungen damit. :) 1. Wir haben den AAD Connect umgesetzt. Auch aus dem Grund, um die Kennwort Synchronisierung für die Domain Welt u. MS365 Welt für alle MAs zu Verfügung zu stellen. 2. Wir haben auf beiden Terminal Server Farmen nur noch Microsoft 365 Produkte installiert (keine Volume Lizenzen mehr) Dadurch beruhigte sich die ganze Problematik deutlich! "Outlook lässt sich nicht öffnen" oder "Office Anmeldung klappt nicht" Was wir zwischendurch u. unregelmäßig aber immer wieder und nur auf den Terminal Server Farmen haben, sind nach Benutzer Kennwort Änderungen (alle X Tage), dass die MS365 Anmeldung dann schief geht und nicht genommen wird. Der ganze Synch Prozess AAD Connect usw. dauert natürlich eine Zeit, aber das haben wir berücksichtigt. Trotzdem können wir ungeduldige Mitarbeiter nicht ausschließen. :) Unsere Lösung dafür ist, der betroffene Mitarbeiter bleibt z.B. auf dem Terminal Server 1 angemeldet, beendet alle Office Anwendungen, wir löschen im Hintergrund die Datei %APPDATA%\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy im betroffenen Benutzer Ordner auf dem Terminal Server 1. Danach meldet der Benutzer sich ab und wieder an. Dann greift sofort die MS365 Anmeldung. Maximal müssen noch einmal die Anmeldedaten eingegeben werden.

Hallo in die Runde, Ja, es war ein Switch (HPE CX6100). Paketverluste gingen in die 100.000de . Bei jedem weiteren "Copy Job" kamen tausende hinzu.... Firmware usw. nochmals aktualisiert, aber gleiches Verhalten. Switch rausgeschmissen und seit ca. 21 Tagen haben wir vom Kunden keine Beschwerden mehr und konnten den Fehler auch nicht wieder nachstellen. Danke und viele Grüße

Hallo in die Runde, leider habe ich mal wieder ein nicht nachzuvollziehendes Phänomen in einer Microsoft Windows Domain Umgebung. Im allgemeinen Internet habe ich dazu leider auch keine Antworten finden können. Umgebung: Rechenzentrum Colocation Windows Domain Anbindung Standort A LAN/ LAN Kopplung mit Hilfe von Fortigate. Anbindung 1Gbit/s up wie down Anbindung Standort B LAN/ LAN Kopplung mit Hilfe von Fortigate. Anbindung 1Gbit/s up wie down An Standort A u. B wird „gemischt“ gearbeitet, entweder auf einer Terminal Server Farm, oder auch lokal für Grafikbearbeitungen usw. Alle Client Endgeräte sind Mitglied in der Windows Domain. Nun das Phänomen, was ich mir noch nicht erklären kann. An Standort A, oder B ist ein Grafiker mit einer Workstation. Wenn er sich über eine Freigabe vom File Server normale Grafiken lokal auf seine Workstation kopiert. Als Beispiel Standard .jpg oder .png Grafiken, werden diese Grafiken verändert. Entweder sieht man nur noch das halbe Bild, oder die Farben sind vermischt oder, oder. Die Größe der Datei bleibt aber gleich. Das tritt ebenfalls auf, wenn z.B. ein WORD Dokument mit Grafikinhalt vom File Server geöffnet, oder lokal kopiert wird. Die Grafiken im WORD-Dokument werden verändert, sind nicht mehr erkennbar, oder mit Fehlern dargestellt. Irgendein Vorgang greift aktiv in die Datei und verändert Sie. Das passiert nicht immer u. nur sporadisch. Zusätzlich habe ich im Rechenzentrum einen kleinen Management PC der ebenfalls in der Domain eingebunden ist. Da habe ich genau das Gleiche Problem. Wird im Gegensatz auf der Terminal Server Farm gearbeitet. Gerne mit den gleichen Dateien und Grafiken, existiert das Phänomen nicht. Lokalen Virenschutz hatte ich Client seitig schon deaktiviert bzw. deinstalliert. Leider gleicher Effekt. Im Anhang eine Beispiel Grafik wie das aussieht. Vorab, vielen Dank für Eure Hilfe.

Moin, ich hatte parallel ein Support Ticket bei Microsoft eröffnet. Dort habe ich diesen Link zur Umsetzung erhalten. Für mich auf dem ersten Blick, aber auch der falsche Ansatz, da wir nicht mit diesen Office Versionen arbeiten, sondern mit Microsoft 365. Mit den Vorschlag von Microsoft bin ich auch nicht ganz glücklich/ unsicher und habe es noch nicht umgesetzt. How modern authentication works for Office 2013 and Office 2016 client apps - Microsoft 365 Enterprise | Microsoft Learn

Hallo Jan, nein, sind sie nicht.

P.S. Ich habe nun einen betroffenen Benutzer, der kein Outlook mehr nutzen konnte, in WORD bei M365 abgemeldet. Danach wieder erfolgreich angemeldet und Outlook konnte auch wieder gestartet werden. Gefunden, wird Zeit für Feierabend! Ich Danke dir für die Hilfe. Somit haben wir erst einmal eine Option um zu reagieren, ohne das gesamte Profil neu zu erstellen.

Hallo mwiederkehr. Danke für deine Antwort! Was meinst du mit dem oberen Satz? Das Verzeichnis konnte ich so nicht finden. Diese Einträge habe ich gesetzt u. getestet. Nehme ich danach einen betroffenen Benutzer, kann ich diesen leider immer noch nicht anmelden.

Hallo Community, ich hoffe ich schreibe das hier im richtigen Abschnitt. :) Optisch hat sich hier wirklich viel verändert. Sieht sehr gut aus! Ich muss in Zukunft mal wieder regelmäßig hier vorbei schauen. :) Folgende Ausgangslage: Neue Microsoft Domain aufgesetzt Neue Microsoft Terminal Server Farm mit Hilfe von Microsoft Server 2019 aufgesetzt, als Benutzer Profilspeicher FS Logix im Einsatz. Alle Windows RD Benutzer besitzen eine Microsoft 365 Business Premium Lizenz(gesamt 51stk). Microsoft 365 Anwendungen wurden auf allen Windows Terminal Servern 2019 mit Hilfe des Microsoft Deployment Tool vorschriftsmäßig installiert. Die Lizenz ist auf allen Terminal Servern als „Mehrbenutzer fähige Lizenz“ hinterlegt u. registriert Beim ersten Start von Outlook 365 im Benutzer Kontext kommt ordentlich die Microsoft Benutzeranmeldung und das Postfach wird ohne Outlook Cache Mode dargestellt. Technisches Problem: Aus für uns noch unerklärlichen Gründen, bricht Microsoft Outlook 365, sporadisch bei unterschiedlichen Benutzern, täglich die Verbindung ab. Fehlermeldung: „Outlook kann nicht gestartet werden. Das Outlook Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Der Informationsspeicher steht nicht zur Verfügung.“ Was haben wir zur Behebung versucht? Wir haben danach keinerlei Möglichkeit mehr, die Microsoft 365 Benutzer Anmeldung nochmals durchzuführen. Wir bekommen den Benutzer, den es betrifft, auf keiner uns technisch bekannten Weise wieder bei M365 angemeldet. Fehlermeldung bei Outlook 365 " Da hat etwas nicht geklappt" Auch das Löschen vom Outlook Profil mit wiederholten anlegen eines neuen Outlook Profils bringt die gleiche Fehlermeldung. Wir müssen das gesamte Microsoft Benutzerprofil löschen und wieder neu anlegen. Das funktioniert wenige Tage und wir stehen vor dem gleichen Problem. An allen Standorten haben wir sehr gute Internetanbindungen( 1GB/s up, wie down). Die gesamte DNS, Autodiscover usw. Konfigurationen sind alle grün und zeigen von Microsoft keinerlei Fehler an(online Test durchgeführt). Auch der lokale DNS Server löst alles ordnungsgemäß auf. Das Problem tritt bei den Benutzer nur auf der Terminal Server Farm auf. Nicht lokal in der Outlook 365 Installation. Die Migration vom on premise Microsoft Exchange Server wurde aus "politischen Gründen" komplett händisch u. mit Hilfe von Mail Store umgesetzt. Kennt vielleicht jemand diesen Fehler? Vielleicht Fehlerhafte Lizenz Abfragen von Microsoft? Vielen Dank für eure Unterstützung!