Edvvde

Auch interessant: - Copy & Paste auf leeren Ordner (keine Reaktion, es passiert also nichts), normalerweise sollte hier ein weiterer leerer Ordner als Kopie angelegt werden - Ausschneiden und einfügen auf einen leeren Ordner (ebenfalls keine Reaktion) Legt man nun ein leeres Textfile in diesem Ordner an, wird bei Copy & Paste dieses Textfile im Ordner als Kopie angelegt, nicht aber der Ordner selbst. Mache ich ein Ausschneiden und Einfügen auf den !Ordner!, meldet er mir, dass die QuellDATEI und ZielDATEI identisch seien. Auf anderen Maschinen wird hier gemeldet "Quell- und ZielVERZEICHNIS" sind identisch ...

Hallo Zusammen, aktuell kann ich mir noch keinen richtigen Reim darauf machen, vielleicht sehe ich auch den Wald vor lauter Bäumen nicht aber wir haben aktuell auf einem Netzlaufwerk (Windows Fileserver VM) das Verhalten, dass wenn ich einen Ordner kopiere und diesen im selben Verzeichnis einfüge, keine Kopie dieses Ordners angelegt wird, sondern eine Kopie dessen Unterordner und Dateien im zuvor zum kopieren ausgewählten Ordner angelegt wird. Dieses Verhalten haben wir jedoch nicht bei allen Ordnern sondern nur bei "älteren". Nicht bei Ordnern die neu angelegt wurden (zum Test z.B.). Außerdem tritt das Verhalten nicht von allen Clients auf. Es ist jedoch kein Muster zu erkennen ... Weiß jemand was dieses Verhalten hervorbringt? Danke & Gruß

Du sagst es, es schafft neue Probleme. Die Softwarequalität ist einfach unter aller Sau. Wir zögern Updates schon bis aufs letzte raus und wenn wir dann quasi wegen irgend welchen neuen CVEs gewzungen sind zu handeln, dann kann man eigentlich schon für die kommenden Tage das Feldbett am Rack aufbauen.

Der Microsoftsupport lässt weiterhin auf sich warten ... scheinbar Fachkräftemangel im 1st level ... // Kurzes Update: Die Ursache ist ein Softwarefehler in der aktuellen Version von FSLogix 2210 (2.9.8361.52326). Ein Downgrade auf Version FSLogix 2201 hotfix 2 (2.9.8228.50276) löst das Problem in Luft auf. Zwei Schlaflose Nächte am Produktivsystem weil wieder irgend ein Mist gepulished wurde ... I love it ...

Moin zusammen, hier mal wieder eine Odyssee, wir befinden uns noch mitten drin. Kurz zur Erklärung: - Windows Server 2019, RDS (FSLogix) -- Updatestand 01/23, FSLogix 2210 (2.9.8361.52326), Office (Version 2212 Build 16.0.15928.20196) 64 Bit --- getrennte Container für Userprofile als auch Office ---- M365 E3 bei allen Usern, MFA aktiviert Seit Update auf 12/22 (weiterhin vorhanden aktuell auch bei 01/23) verlangen die Office 365 Apps nach An-/Abmeldung vom Server ständig einen neuen Login (auch mit Abfrage MFA). Ist man angemeldet und die RDS-Sitzung wird nicht abgemeldet, kann man ungestört arbeiten, sobald die RDS Sitzung aber ausgeloggt wird, muss man sich wieder neu Anmelden. Problem betrifft nur RDS, lokale Clients nicht betroffen. Was schon versucht wurde: - DISM Online / als auch Offline-Image erfolgreich - SFC Reparatur erfolgreich, chkdsk erfolgreich - Credentials im Credentialsmanager gelöscht - Online Reparatur M365 - Reparaturinstallation FSLogix - Registry Identity Ordner innerhalb des Current User gelöscht (führte nur größeren Loginproblem) - komplett neuer User sowohl in AD also auch AzureAD (mit und ohne MFA) - GPO FSLogix Aktivierung Office in Office Container ein-/ausgeschalten - Microsoft Support und Wiederherstellungs-Assistenten (SetupProd_RoiScanFull, SetupProd_Act, SetupProd_OfficeSharedComputer, SetupProd_OfficeSignIn) Es ist zum Mäuse melken. Ticket bei Microsoft läuft, Antwortzeit aktuell aber eine mittelschwere Katastrophe ... Vielleicht noch jemand eine Idee? Ansonsten bleibt nur Recovery auf Stand vor Update, aber irgendwann müssen die Updates ja gemacht werden ... LG

Kurzes Update: Es hat den Anschein, dass das Problem mit OneDrive Preview 22.166.0808.0002 nicht mehr existiert. Zumindest tritt der Fehler nun seit ca. einer Woche nach Installation nicht mehr auf und lässt sich auch nicht mehr provozieren. Man darf gespannt sein, ob dies auch für das nächste offizielle Release gilt.

In der Microsoft Communiy existiert nun seit dem 17.08. ein Eintrag eines französischen Users welcher den selben Fehler Unter Win 10 21H2 beschreibt. Ich habe mich dem Thema mal angeschlossen sowie ein Ticket beim M365 Support eröffnet. https://answers.microsoft.com/en-us/windows/forum/all/onedrive-constantly-disappears-on-file-explorer/2faa1d87-5bb8-4b3e-b48f-a31eb215bf93?rtAction=1660817114279 //Update: In dem Thread häufen sich mittlerweile die Meldungen von Usern mit der selben Problematik. Man kann den Fehler auch reproduzieren in dem z.B. im Browser eine Datei hochgeladen wird oder aus einer anderen OneDrive (Freigabe). Sobald der Client lokal anfägt zu syncen, verschwindet das OneDrive Symbol als der Sidebar im Explorer. Ist man in diesem Moment über dieses Symbol aus der Sidebar in einem Ordner innerhalb OneDrive am arbeiten erscheint zusätzlich die Fehlermeldung "explorer.exe ..." Es scheint sich also um ein Softwareproblem zu handeln, bis jetzt vermutlich aufgetreten nach KB5016616 und KB5012170 ...

Kleines Update: Der Fehler besteht leider immernoch. Inzwischen ist auch klar, dass es nicht nur ein Profil betrifft, sondern sich sogar provozieren lässt indem man den OneDrive Ordner über das Cloudsymbol links (unter Schnellzugriff) aufruft und dort dann einwenig "wild umherklickt". Was auch noch nachvollzogen werden konnte ist, dass statt des Pfads also z.B. C:\Benutzer\OneDrive\ im Explorer dann eine ID steht z.B. : Diese ID konnte ich in der Registry finden unter HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace Der Eintrag dort verschwindet in dem Moment in dem der Fehler auftritt aus der Registry. Ich vermute es fehlt dann schlicht und einfach die Verknüpfung in diesem Moment. Das würde auch erklären, wieso das Problem nur auftrtitt, wenn man mit dem OneDrive Ordner über die die Schnellzugriff-Liste links arbeitet, nicht wenn man z.B. via Doppelklick auf das OneDrive Symbol in der Taskleiste neben der Uhrzeit geht ... Was bereits versucht wurde sind die klasischen Ansätze DISM /restorehealth und sfc /scannow welche auch einwandfrei durchliefen. Der Server hat nun das August Update bekommen, FS Logix ist ebenfalls auf dem aktuellsten Stand FSLogix 2201 hotfix 2 (2.9.8228.50276) und OneDrive auf 22.151.0717.0001 (64-Bit) installiert als machine-based. OneDrive wurde auch mal zum Test deinstalliert sowie die das online-repair von Office ausgeführt, ohne Erfolg.

Um die ganze Geschichte mit M365 (Exchange Cache) und OneDrive lauffähig zu haben, ist hier FSLogix im Einsatz. Es handelt sich also um Profilcontainer mit seperaten Containern für alle Daten was M365 angeht. Ich hatte hier bereits beide Container mal gelöscht und frisch aufsetzen lassen, was aber nicht zur Problemlösung beigetragen hat, leider ...

Hallo zusammen, ist jemandem vielleicht schon mal dieser Fehler begegnet? "Explorer.EXE: Der Datei ist keine App zum Ausführen dieser Aktion zugeordnet. Installieren Sie eine App, oder erstellen SIe auf der Einstellungsseite für Standard-Apps eine Zuordnung, wenn bereits eine App installiert." Aufgetreten hier auf einem Windows Server 2019 welcher als Terminalserver fungiert, jedoch bisher nur bei einem User. Habe mehrere Communityeinträge dazu gefunden, aber meist eher unspezifisch und aufgetreten auf Clients. Wobei es hier auch mutmaßlich immer in Verbindung mit dem OneDrive Sync Ordner auftritt. Interessanterweise verschwindet die OneDrive Wolke links im Schnellzugriff, sobald der Fehler auftritt, ist ähnlich wie bei diesem User hier: https://answers.microsoft.com/en-us/windows/forum/all/error-explorerexe-this-file-does-not-have-an-app/6eefb639-08fc-42e3-ab1d-d3b5343d4105 Erst nach einer sauben Ab-/Anmeldung ist alles wieder für mehrere Minuten manchmal Stunden normal ...

Hallo zusammen, wenn es nach Microsoft geht, ist der Terminalserver ja eigentlich ein weiteres Mal (war ja schon bei 2019 angekündigt, wurde aber ja zurückgerudert) als Totgeburt auf den Markt geworfen. Office 365 wird nicht unzerstützt laut Microsoft: https://docs.microsoft.com/de-de/deployoffice/endofsupport/windows-server-support Fakt ist aber auch, es läuft auf einem Windows Terminalserver 2022 mit entsprechender E3 Lizenz einwandfrei, als wäre nichts. Hat hier vielleicht jemand in die Glaskugel geschaut und kann sagen, ob Microsoft nur den Support meint oder es ggf. eines Tages einfach einen Lizenzfehler schmeißen wird? Und Server 2019 ist ja auch so eine Sache: "Wird bis Oktober 2025 unterstützt." Kann mir nur vorstellen, dass auch der Support hiermit gemeint ist. Aber einfach durch Lizensierung abschalten ... kann ich mir eigentlich nicht vorstellen da 2019 selbst ja bis Ende 20er Jahr laufen soll ... LG

Wollte hier noch kurz auflösen: Anscheinend hatte sich ein Windows Service Update festgefahren. Habe mit einem Windows Image in CMD gebootet und mit DISM mir die installierten Packages anzeigen lassen DISM /Image:C:\ /Get-Packages /format:table > C:\updates.txt Notepad C:\updates.txt Dort dann das austehende bzw. fehlerhaft installiert Package ausfinding gemacht und mit DISM /Image:C:\ /Remove-Package /PackageName:hier_der_packagename Das fehlerhafte Package entfernt. Die VM ließ sich danach wieder booten und das Update konnte wiederholt werden. Falls jemand mal in ähnliche Probleme läuft ;) Gruß

Danke für deine Antwort. An den Druckerspooler glaube ich eigentlich nicht. Alle anderen VMs auf dem Host und sogar der Host selbst haben das selbe Update erhalten und machen keine Probleme, nicht mal die VM über die von Clients lokale Drucker angesteuert werden ...

Hallo zusammen, ich habe hier eine VM (Server 2019 Standard, keine Rolle, Server für DMS & ERP inkl. Datenbank) die mich noch in den Wahnsinn treibt. Aufgefallen ist das Problem gestern Abend, Windows Updates wurden eingespielt (KB5005568). Dann fing das Theater an, die VM wollte nicht mehr booten, wirft dreimal einen Bluescreen (Fehlercode 0xc000021a) und bootet dann in den Recovery. Habe aus Backup vom Freitag Abend die komplette VM zurückgespielt, läuft einwandfrei. Datenbanken laufen alles supi. Also Update erneut eingespielt, gleiches Problem. Also wieder Backup zurückgespielt. Dann sfc /scannow (kann keine Probleme feststellen). Beim booten chkdsk /f /r findet auch nichts. DISM /scanhealth meldet das repariert werden kann. DISM /recoverhealth bricht bei um die 97% ab und meint dann 0x800f081f source not found. Dann ISO von Server 2019 Eval 1809 besorgt und DISM befehl mit source abgesetzt (sowohl Online dism /online /cleanup-image /restorehealth /source:WIM:E:\sources\install.wim:2 als auch offline im Recovery Mode dism /image:c:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:2, Fehler 0x800f081f source not found bleibt bestehen. Also VM wieder zurückgespielt aus Backup. Update manuell versucht sowohl KB5005568 als auch die Preview nach erneutem rückspielen KB5005568, landen wir wieder am Anfang bei Fehlercode 0xc000021a. Also wieder rückgespielt, als nächstes SFCFix versucht, DISM schlägt weiterhin fehl. .NET Framework 4.0 entfernt, Update versucht, wieder Bluescreen. Hat hier vielleicht noch jemand eine Idee, außer die komplette VM neu aufzusetzen? ...

Die Clients über die Systemeigenschaften aus der Domäne entfernen bzw. statt Domäne wieder in eine Workgroup packen. Netzwerkfreigaben sind (bis auf die zugwiesenen Berechtigungen aus der AD) unabhängig davon ob in einer Domäne oder nicht. Mir erschließt sich aber nicht weshalb du die Domäne auflösen möchtest ... dann macht der "Server" meiner Meinung nach wenig Sinn, dann hätte es auch ne NAS getan wenn es nur um Dateifreigaben geht.