ITZubi

#push Das Problem scheint gelöst zu sein. Vermutlich war App-V der übeltäter, seit dem dieser Deinstalliert ist kommt es auch nicht mehr zu diesem besagten Problem... Anscheinend hilft auch ein Update des App-V Clients auf die Version 5.0 Sp2 Hotfix5, um dieses Problem zu beseitigen. Unter anderem war es noch nötig für den Benutzer "Jeder" die Rechte 1) Lesen, Ausführen 2) Ordnerinhalt anzeigen und 3) Lesen für den Ordner "C:\Users\Default" (vererbt)zu vergeben! Quellen: 1) https://support.microsoft.com/en-us/kb/2985344/de 2) http://support.microsoft.com/en-us/kb/2963211 Thread kann somit geclosed werden. Vielen Dank für die Helfer

Soooo ich hatte nun etwas Zeit wieder zu testen und dabei hab ich komische Ergebnise, so damit ich echt stuzig bin! Getestet wurde mit drei Computern Computer 1: - Keine GPO´s die hier Verteilt wurden - Über OPSI wurde darauf Software verteilt (Kein McAfee) - In der Domäne aufgenommen Probleme: Keine Anzeichen, ich kann mich ohne Probleme einloggen. Ob mit einem Domäne Account oder mit lokalen Benutzer, alles funktioniert! Computer2: - Bekommt GPO´s - Bekommst Software über OPSI (Kein McAfee) - Ist in der Domäne aufgenommen Probleme: Hier hab ich komischerweise Probleme, bei der ersten Anmeldung habe ich mich mit meinem Domäne Admin angemeldet(keine Probleme). Ich habe darauf hin drei lokale Accounts erstellt. Hab mich aber, jetzt, erst am folge Tag an diesem Computer versucht anzumelden(Benutzerprofil konnte nicht geladen werden). Nebenbei habe ich ja "ProcMon" laufen lassen und mir Einträge von der Ereignisanzeige notiert. Computer3: - Bekommt GPO´s - Bekommt aber keine Software darauf verteilt! - Ist in der Domäne Probleme: Hier ebenfalls keine Anzeichen von Problemen, kann mich einloggen! Auch wieder mit Domäne Account und lokalen Accounts gestestet. Der weitere einzige Unterschied bei den Rechnern ist, dass ich mich am Computer 1 und Computer 2 am folge Tag angemeldet habe und an Computer3 erst nach zwei Tage, da ich zeitlich keine Zeit in der Arbeit hatte. Ich denke aber, dass dies nichts ausmachen sollte? ProcMon Prozesse(Computer2) a) Folgende Prozesse, haben auf das gesuchte zugegriffen: 1) svchost.exe 2) MsMpEng.exe (Scheint der Windows Defender zu sein) Auch Stand hier(MsMpEng.exe) bei einem Eintrag als Result: File locked with only Readers b ) Deswegen habe ich mal den Defender abgeschaltet und neugestartet Probleme mit dem Anmelden gab es trotzdem. Habe deswegen hier auch wieder logs erstellen lassen Folgende Prozesse waren hier beteiligt: 1) svchost.exe 2) Explorer.exe 3) SearchProtocolHost.exe Bei Bedarf, lade ich die zwei gefilterten Log Dateien hoch!(Die sind nur einzeln leider alleine schon um die 220MB groß(gezipt:70MB)) Ich würde die Dateien auf uploaded hochladen und als Premium makieren und die links per PN verschicken? Oder ihr habt eine bessere Idee :-) Vielen Dank

@Sunny61: So ich hatte nun etwas Zeit zum testen und möchte nun die Ergebnise mitteilen: 1) Ich habe ein blankes Image installiert und über OPSI Software verteilen lassen, ausgenommen "McAfee". 2) Ich habe zwei "lokale" Konten angelegt, einer davon war in der normalen User Gruppe und einer war in der Administratoren Gruppe Die erste Anmeldung erfolgte mit meinem Domäne Admin Account, mit dennen ich auch die User angelegt habe => Ohne Probleme! 3) a)Nach nur fast einem Tag, habe ich jetzt versucht mich mit einem Domäne User(keine Administratorreche) am Computer anzumelden mit der Fehlermeldung: Fehler bei der Anmeldung des "Benutzerprofildienst". Das Benutzerprofil konnte nicht geladen werden. b ) Darauf hin hab ich mich mit dem lokalen User(Gruppe: User) angemeldet, mit folgenden Fehler: Die verwendetete Anmeldemethode ist auf diesem PC nicht zulässig. c) Dann habe ich mich mit dem anderen Lokalen User angemeldet(Gruppe: Administrator), mit folgendem Fehler Fehler bei der Anmeldung des Diensts "Benutzerprofildienst" Das Benutzerprofil kann nicht geladen werden. Über OPSI wird Software verteilt und Gruppenrichtlinien werden gezogen. Vor noch einem Monat wurde die Software noch per Gruppenrichtlinien verteilt, da gab es die Probleme aber auch schon Ich hab aber noch einen Rechner aufgesetzt, auf dem keine Software verteilt wird, nur Gruppenrichtlinien.(Wenn ich auf dem fertig getestet habe, gebe ich ebenfalls nochmal bescheid!) @daabm: Ich habe mal den "Process Monitor Tool" ausprobiert und "Enabling Boot Logging" aktiviert. Leider sind nicht die Dinge geloggt die beim Einloggen passiert sind , zumindest stimmen die Uhrzeiten von den Loggs nicht mit der, der Ereignisanzeige überein. Auszug aus der Ereignisanzeige(14.08.2014 08:21:03): Die Datei \\?\C:\Users\Default\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\de-DE\Classic_{33843DB0-24E7-4682-A019-5393D7F2BFFA}.settingcontent-ms konnte nicht nach \\?\C:\Users\TEMP\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\de-DE\Classic_{33843DB0-24E7-4682-A019-5393D7F2BFFA}.settingcontent-ms kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Evtl. kann man mir sagen, wie ich genau vorgehen muss, Vielen dank hierfür im Vorraus.

@lefg: 1) Beim Original, nicht in der Domäne gibt es keine Probleme mit dem "lokalen" Administrator Account 2) Hier ebenfalls keine Probleme mit dem "lokalen" Administrator. 3) Auch hier gibt es mit dem "lokalen" Administrator keine Probleme Getestet habe ich hier nur mit dem "lokalen" Administrator, kann aber auch mal zwei drei normale "Benutzer" anlegen und das testen? @Sunny61: 1) //Noch am testen(Hatte vergessen, dass das Image doch nicht so unangetastet war: Nach der Installation eines erstellen Images, an dem nichts verändert wurde, tritt dieses Problem auf(Info:Computer in der Domäne). Komisch aber: Wenn man sich mit einem Domäne Benutzer, gleich nach der Installation, anmeldet tritt das Problem nicht auf!(Das war auch bei einem angepassten Image so, hatte es nur vergessen zu erwähnen). Nach ca. 2-3h bzw. wenn sich ein paar Domäne Benutzer bereits,erfolgreich angemeldet hatten, fangen die Probleme meistens erst an(so habe ich es zumindest bis jetzt wahrgenommen). 2) Wie gesagt, gleich zu Anfang gab es keine Probleme mit der Anmeldung eines Domain Benutzers, die kommen erst nach einer Zeit... Entschuldigt bitte, dass ich das nicht gleich von Anfang an erwähnt habe. 3) Wir benutzen "zur aller leidwesen" McAfee, aber ich habe auch schon das Image ohne Sicherheitssoftware erstellt. Wobei ich mir nicht ganz sicher bin und glaube, dass wir es mit OPSI oder per GPO nachgeliefert haben. Könnt es echt sein, dass es echt wegen "McAfee" auftritt? Müsste ich ab Montag dann in der Arbeit ausprobieren...

Ja meine Formulierung war jetzt nicht wirklich 1a, was ich so ihm nachhinein bemerkte. Ich hoffe mit folgenden Satz mache ich es richtig, ansonsten bitte ich um korrektur ^^ "Dadurch das wir in einer Domäne sind, ist es ja möglich sich bei uns mit Domäne Accounts anzumelden, ohne das Profile von diesen Domäne Accounts bereits auf diesem Computer existieren bzw. angelegt wurden. Das andere ist, ich habe wegen des Verdachts eines "Verbogenen Profils" mehrere neue Images, von Grund auf neu, erstellt. Trotzdem immer dass selbe Problem. Nein dieser Begriff wurde noch nicht erwähnt, aber natürlich haben wir auch in die Ereignisanzeige geschaut. In einem Code-Fenster habe ich einen Auszug aus der Ereignisanzeige Ereignisanzeige 1) Die Datei \\?\C:\Users\Default\AppData\Roaming\Microsoft\Bibliography\Style\GostTitle.XSL konnte nicht nach \\?\C:\Users\uocuz\AppData\Roaming\Microsoft\Bibliography\Style\GostTitle.XSL kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509 2) Das lokale Benutzerprofil wurde nicht gefunden. Sie werden mit einem temporären Benutzerprofil angemeldet. Änderungen, die Sie am Benutzerprofil vornehmen, gehen bei der Abmeldung verloren. Ereignis-ID: 1511 3) Sie konnten nicht angemeldet werden, da das lokal gespeicherte Profil nicht geladen werden konnte. Überprüfen Sie, ob eine Netzwerkverbindung besteht und das Netzwerk ordnungsgemäß funktioniert. Details - Nur ein Teil der ReadProcessMemory- oder WriteProcessMemory-Anforderung wurde abgeschlossen. Ereignis-ID: 1500 4) Die Datei \\?\C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Documents.lnk konnte nicht nach \\?\C:\Users\TEMP\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Documents.lnk kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509 2) Die Datei \\?\C:\Users\Default\AppData\Roaming\Microsoft\Bibliography\Style\CHICAGO.XSL konnte nicht nach \\?\C:\Users\TEMP\AppData\Roaming\Microsoft\Bibliography\Style\CHICAGO.XSL kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509 3) Die Datei \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\WinX\Group3\09 - Mobility Center.lnk konnte nicht nach \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\WinX\Group3\09 - Mobility Center.lnk kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509 4) Die Datei \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\WinX\Group3\08 - Power Options.lnk konnte nicht nach \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\WinX\Group3\08 - Power Options.lnk kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509 5) Die Datei \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\WinX\Group3\04-1 - Network Connections.lnk konnte nicht nach \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\WinX\Group3\04-1 - Network Connections.lnk kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Ereignis-ID: 1509

Nein, wir arbeiten nicht mit Servergespeicherten Profilen. Accounts, werden an jedem Computer immer wieder neu erstellt. Dieses Problem besteht erst seit Windows 8.1, unter Windows 8 hatten wir dieses Problem nicht! edit:\\ Lokale Accounts anlegen und mit diesen Anmelden, haben wir nicht probiert. Nur mit dem "Lokalen Administratoren" anmelden, und dass geht.

@lefg: Ja ist uns bewusst, aber dass ist die Standard-Vorlage für Profile. Sprich, diese wurde von uns "testweise" einfach mal gar nicht verändert. Auch haben wir das Problem, wenn wir einfach nur mal ein nacktes Image aufnehmen und wieder weiter verteilen.

Wie gesagt, in diesem Image bestehen keine Profile außer der "Lokale Administrator" und der funktioniert. Wie beschrieben, werden die Profile erst beim ersten Login erstellt und da kommt ja schon dieser Fehler! Auch habe ich auch schon versucht folgende Dinge von Microsoft anzuwenden: http://support2.microsoft.com/kb/947215/en-us Aber wie gesagt, wenn es dieses Profil noch nicht mal gibt, wie soll ich dann überhaupt nach oben gennanten Link verfahren...

Sehr geehrte Community, ich plage mich seit dem erscheinen von Windows 8.1 mit einem großen Problem herum. Erstmal Informationen zur Umgebung: ca. 150 Windows Clients Alle sind in einem Domäne-Netzwerk Images werden selbst entworfen und über das Netzwerk, automatisiert, verteilt/installiert! Softwareverteilung findet hier unter anderem auch über GPO´s und/oder OPSi statt. Benutzerprofile, außer der lokale Administrator, existieren nicht von Anfang an. Wie melden sich User bei uns an: Dadurch das wir in einer Domäne sind, ist es möglich sich mit einem Domäne Account anzumelden, ohne dass dieser davor auf dem Rechner existiert hat! Dieser sollte bei der erstmaligen Anmeldung, an den jeweiligen Rechner, erstellt werden. Problem: Das Problem ist, dass bei der erstmaligen Anmeldung mit einem Domäne -Account, der zuvor noch nie angemeldet war an diesem jeweiligen Rechner folgender Fehler kommt: Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen Das Benutzerprofil kann nicht geladen werden. Kleine -Problemlösung: Damit man sich trotzdem an diesem Rechner anmelden kann, hat nach der Fehlerhaften Anmeldung ein "Restart" des Computers geholfen. Jeder weitere anderer neuer User, der sich nacher an diesem Rechner anmeldet, hat die selben Probleme! Aber das ist leider keine vollwertige Lösung. Würde mich über eure Hilfe freuen. Schönen Tag euch

Ja dass ich mir jetzt soweit klar, verstehen kann ich aber dann nicht warum die GPO "GoogleChrome", obwohl dies nur Benutzereinstellungen enthält, trotzdem wirkt und diese sich bei Computerobjekten befindet? Und diese wirkt auch, wenn ich denn Loopbackverarbeitungsmodus nicht drinnen habe! Ich habe die "Ersten Schritte" gelesen es war mir aber trotzdem nicht so klar gewesen weswegen ich hier nochmal nachgefragt habe!

@Sunny61: Sorry dass ich nicht früher zurück schreiben konnte, war terminlich unterwegs gewesen. Ich hoffe ich kann so irgendwie die Struktur unserer Domäne Darstellen: Gesamtstruktur: Firma.Endung => Domänen => => Firma.Endung => => => Abteilung => => => => MISC => => => => => Unterabteilung => => => => => => Computers => => => => => => => Pools Hier liegt die GPO´s "GoogleChrome", "GoogleChrome_MultiLogon" und auch die PC´s Beide GPO´s laufen über die Benutzerkonfiguration. In der Google Chrome GPO ist unter Sicherheitsfilter "Authentificated Users" eingetragen In der GoogleChrome_MultiLogon, unter Sicherheitsfilter, sind die drei User eingetragen und eine Gruppe aller PC´s Gesamtstruktur: Firma.Endung => Domänen => => Firma.Endung => => => Abteilung => => => => STAFF => => => => => Users => => => => => => Funktionskonten => => => => => => => Multilogon Hier liegen die drei User, auf die ich eigentlich die Gruppenrichtlinie "GoogleChrome_MultiLogon" gezogen haben wollte Ich verstehe nur leider nicht was mit "uneingeschränkten Verwaltungsbereich" gemeint ist!

Kann es sein dass es nicht funktioniert, weil der Sicherheitsfilter nur für Objekte die in der OU liegen gelten, in der die GPO angewand wird? @Sunny61: Ich beantworte deine Frage wenn ich zuhause bin!

Also folgendes: Wenn ich bei den Sicherheitsfiltern, Authentifizierte Benutzer hinterlege ist die GPO "GoogleChrome_MultiLogon" wieder verfügbar, sprich diese wird gezogen. Wenn ich aber nur wieder die einzelnen User eintrage, für die diese GPo gelten soll, funkioniert es wieder nicht! edit1:// Ich möchte doch nur dass für bestimmte User etwas andere GPO´s gelten, man... Probiert habe ich die diese drei User in einer Sicherheitsgruppe zu packen und diese bei den Sicherheitsfiltern hinzuzufügen, aber nein natürlich hat es nichts gebracht! edit2:// Wenn ich die "Negative Sicherheitsfilterung" verwende und in der GPO "GoogleChrome", meine drei Spezialuser davon ausschließe, und die GPO "GoogleChrome_MultiLogon" in der OU der drei Spezialuser verschiebe, funktioniert alles so wie es funktionieren soll! Doch leider darf ich keine Negative Sicherheitsfilterung nutzen!

Er hat mir folgendes geschrieben gehabt: 1. Die GPO wird nicht gezogen, wenn du sie auf die Clients verlinkst?! Dann schauts nach einem Problem mit dem Loopback Mode aus. Ich habe alle GPOs auf den Container mit den Clients verlinkt und arbeite mit Loopback Replace, das funktioniert wunderbar. 2. Die Settings werden nicht gesetzt, auch wenn die GPO in der Reihenfolge weiter oben steht?! Ich schreibe so Sachen eigentlich immer direkt in die Registry via GPP und filtere dann über Item Level Targeting. So könntest du auch dieselbe GPO verwenden Meine Antworten dazu: 1) Das mache ich jetzt auch so, bringen tut es aber nichts 2) Ja richtig, obwohl diese weiter oben steht! Bei solchen GPO´s passiert ja nichts anderes als, dass eigentlich meistens dinge in der Registry geändert werden, oder nicht? Und was zum henker ist "Item Level Targeting"?

Joo ich habe nachgeschaut, die Rechte sind richtig gesetzt! edit:// Was mir aber auffällt, wenn ich die GPO "GoogleChrome_MultiLogon" in der OU dort plaziere in der sich die drei User befinden, bekomme ich, wenn ich "gpresult /r" mache die GPO "GoogleChrome_MultiLogon" angezeigt. Leider zieht diese trotzdem nicht, da die GPO "Google Chrome" anscheinend überhand behält! Was mir aber auch auf gefallen ist wenn ich die GPO´s so plaziert habe, wenn ich jetzt z.B in der GPO "GoogleChrome" einen der Werte auf "Nicht konfiguriert" setze, diese Einstellung aber in der GPO "GoogleChrome_MultiLogon" konfiguriert habe, übernimmt er die aus der GPO "GoogleChrome_MultiLogon"!