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.

Um das Thema abzuschließen, es gibt keine (bessere) Lösung (für die o.g. Konstellation) als FSLogix, damit läuft alles mehr als einwandfrei und bietet noch zahlreiche weitere Schmankerl. Gruß

Glaub mir Norbert, der Fehler unterläuft nicht nochmal ;) Aber was passiert in der Karnevalszeit nicht alles, das eigentlich nicht hätte passieren sollen

Nils, keine Frage hätte nicht passieren sollen. Es gibt aber noch einiges an Konfiguration drum herum, welche deutlich mehr Zeitaufwand bedeutet hätte. Wäre es ein blanker DC, stimme ich dir zu 110% zu. Allein den Text hier fürs Forum wäre es zeitlich nicht wert gewesen. Ist aber vielleicht interessant für jemanden, der mal in einer ähnlichen Situation ist. Es scheint doch möglich zu sein. Vielleicht besteht ja überhaupt kein technischer Hintergrund sondern es ist vielleicht nur dem Umstand geschuldet, dass die Evaluation nicht für Produktivumgebung zugelassen ist. Oder es ist mittlerweile supportet nur (noch) nicht offiziell kommuniziert, wer weiß ...

Moin Nils, kurz, knapp und ehrlich - es ist ein Fehler unterlaufen. Statt mit der normalen ISO, wegen mir auch der DVD, wurde zur ISO der Evaluation gegriffen (wer lesen kann ist klar im Vorteil). Es sind bereits zwei DCs im Einsatz und ich wollte jetzt nicht beide DCs wieder neu aufsetzen inkl. DNS, DHCP usw. auch nicht mit einem dritten auf dem FSMO übertragen wird usw. usw. Zum testen wurde jetzt der zweite DC mal aktiviert, was wie gesagt zu funktionieren scheint. Ich dachte vielleicht hat jemand Info dazu oder kennt den technischen Hintergrund warum es nicht möglich sein soll bzw. warum es funktioniert hat. Woran ich gedacht hatte ist, dass es vielleicht nicht funktioniert von Standard auf Datacenter und umgekehrt aber Standard zu Standard sehr wohl ... Aber du hast natürlich recht, hätte nicht passieren dürfen.

Moin, danke für deine Antwort. Also merkwürdigerweise wird es egal ob 2012, 2016 und auch 2019 als nicht möglich in den Microsoft Foren und ich meine auch in den Support Dokumenten beschrieben, wie du auch geschrieben hast. Der Server wird aber definitiv als aktiviert mit Server 2019 Standard angezeigt, die letzten Ziffern des verwendeten Keys sind sichtbar und das Evaluation unten rechts ist verschwunden. Die AD ist vollständig und die Anmeldung am Client funktioniert. Das wundert mich ... wird also glückliche Mondstand gewesen sein?

Hallo zusammen, angeblich soll es ja nicht möglich sein, einen als Evaluation Standard installierten Server welcher als DC fungiert zu aktivieren als Standard. Ich hab es jedoch ohne Probleme via DISM /Online /Set-Edition:ServerStandard /ProductKey:X /AcceptEula machen können und scheint auch zu laufen. Kann da jemand was zu sagen? Danke!

Hi Jannik, ihr habt also einen RDS unter Win Srv 2019 im Einsatz und nutzt FXLogix Container? Nutzt ihr denn OneDrive in den User Profilen? Welche GPOs habt ihr sinnvoll im Einsatz? Gruß, Carsten

Hallo zusammen, folgende Ausgangssituation: - User arbeiten auf einem Terminalserver unter Win Srv 2019 - Es werden User Profile Disks genutzt (für die Zukunft sind wir am liebäugeln mit FSLogix) - Office ist installiert, User verfügen alle über E3 Lizenzen Nun wollen die User OneDrive auch auf dem RDS nutzen. Müsste ja möglich sein, laut Anforderung wird Windows Server 2019 benötigt welches dann sogar files on demand unterstützen soll. Irgendwie ist das Ganze aber nicht so wirklich für RDS gedacht, habe ich zumindest den Eindruck. Es beginnt schon bei der Installation. Der Installer legt als "Pro User" die .exe ins User Profil des Administrator ab, alle anderen User sehen davon erstmal nichts. Es muss also die Installationsvariante "Pro Computer" gewählt werden, mit OneDriveSetup.exe /allusers wird die Installation ins normale Programmverzeichnis x86 abgelegt. Von dort aus können die User auch Verknüpfungen erstellen und OneDrive starten. Das funktioniert auch, für jeden User wird ein eigener Prozess gestarten. Die User können sich authentifizieren, aber an dem Punkt an dem dann im Userverzeichnis ein Ordner angelegt werden soll scheiterts. Klar könnte ich jetzt wahrscheinlich irgendwo eine Freigabe erstellen und die User dort syncen lassen. Aber ist das Sinn der Sache? Kurz und knapp gefragt: Hat jemand OneDrive produktiv auf einem RDS 2019 im Einsatz und vielleicht ein paar Best-Practices parat? Danke und schönen Abend.

Der Sync läuft, lässt sich zwar nicht abstellen (vielleicht gibt es hier eine Wartezeit?!) Aber der Sync läuft. Er synct halt nicht weil er ein Duplikat meldet, das ist auch in Azure zu sehen: UserPrincipalName Error Type: AttributeValueMustBeUnique Unable to update this object because the UserPrincipalName value ....... associated with this object may already be associated with another object in your local directory services. To resolve this conflict, first determine which object should be using the conflicting value. Then, update or remove the conflicting value from the other object(s). Und das ist ja gewollt ... er soll die beiden ja miteinander verknüpfen, logisch das es ein Duplikat gibt. //Okay wie vermutet, entweder gibt es eine Wartezeit oder irgend ein Prozess lief noch, jetzt ließ sich der Sync auch wieder anhalten. Bleibt also nur noch die Frage, wie die OnPremise und Azure Duplikate zusammengeführt werden können ...

Bin nun etwas weitergegekommen. Folgendes habe ich gemacht: - Mit Azure via Powershell verbunden: Connect-MsolService) - Azure AD Sync geprüft, gab True zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled - Azure AD Sync deaktiviert: Set-MsolDirSyncEnabled -EnableDirSync $false - Azure AD Sync geprüft, gab False zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled Nach wenigen Minuten verschwanden dann im Admin Portal das Zeichen für OnPremise AD sync und es waren nur noch Cloud Benutzer, welche sich auch wieder editieren ließen, schließlich war ja kein Sync mehr aktiv. - Powershell gab leere LastDirSyncTime spalte zurück: Get-MsolUser | ft UserPrincipalName,immutableid,LastDirSyncTime Nun wollte ich die User ja wieder syncen. Dafür habe ich im lokalen AD bei allen Usern das Attribut proxyAdresses gesetzt mit der jeweiligen E-Mail Adresse. Zusätzlich habe ich, da die lokalen User ja über keinen Wert im Attribut ms-ds-consistencyGUID verfügten folgendes gemacht um diese auch bei den Azure Usern zu löschen: - Azure AD Powershell: Set-MsolUser ` -UserPrincipalName testuser@mailadresse.de ` -ImmutableId "$null" - Powershell gab leere immutableid Spalte zurück: Get-MsolUser | ft UserPrincipalName,immutableid,LastDirSyncTime Nun wollte ich den Sync wieder starten also: - Powershell: Set-MsolDirSyncEnabled -EnableDirSync $true - Azure AD Sync geprüft, gab True zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled Schaue ich nun jedoch im Azure Sync Service Tool für meinen Testuser, erhalte ich dort einen Error: - Error: AttributeValueMustBeUnique "Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind: "UserPrincipalName testuser@mailadresse.de;". Korrigieren oder entfernen Sie die doppelt vorhandenen Werte in Ihrem lokalen Verzeichnis." Es findet auch kein Sync statt. Nun wollte ich noch eine Möglichkeit versuchen, Nämlich die zuvor von mir im Azure AD gelöschte (aber gesicherte) immutableid welche dort als BASE64 codiertes Feld hinterlegt ist umzuwandeln in einen HEX Wert um diesen dem User im lokalen AD im Attribut ms-ds-consistencyGUID zuzuweisen. Allerdings bekomme ich den Sync nicht mehr gestoppt ... - Azure AD Sync deaktivieren bringt Fehlermeldung: Set-MsolDirSyncEnabled -EnableDirSync $false --> Set-MsolDirSyncEnabled : You cannot turn off Active Directory synchronization. Noch jemand ne Idee, wie ich die neu angelegten lokalen AD User mit den Azure AD Usern gesynct bekomme -./ ?