11
Userprofile werden nicht gespeichert beim Einsatz von Nvidia Graphikkarten
Sehr geehrte Damen und Herren,
anbei folgendes Problem:
Wir setzen in allen Kundennetzwerken (Windows 2003 Std, SBS) servergestütze Userprofile ein, da die jeweiligen Mitarbeiter zeitweise die Arbeitsplätze wechseln, und Ihre gewohnte Arbeitsumgebung vorfinden wollen.
Seit einiger Zeit werden die Userprofile beim Logout nicht mehr auf den jeweiligen Server repliziert.
Dies betrifft userspezifische Einstellungen in allen MS Office Produkten (ab V. 2002) und in AutoCAD 2006. Fehler in den ActiveDirectories bzw. in den Profilkonfigurationen können wir ausschließen.
Wir haben das Problem eskaliert und konnten eindeutig und reproduzierbar die Ursache feststellen:
Auf den CAD-Workstations und Desktops setzen wir vorwiegend Nvidia-GPUs (Quattro FX, NV7xxx, NV8xxx) mit aktuellen Treibern (162.65_quadro_winxp2k_international_whql) ein. Diese verhindern jedoch beim Logout den Zugriff auf den im ActiveDirectory spezifizierten Profilordner. Unsere Tests ergaben, dass dieses Verhalten seit der Treiberversion 93.72_WHQL auftritt.
Onboard-Graphiken, z.B. von Intel, sind nicht betroffen.
Wird der Nvidia-Treiber vollständig vom System entfernt, so funktioniert die Profilreplikation wieder einwandfrei.
Als Workaround verwenden wir für die Quattro-GPUs nun veraltete Treiber bis 91.36_WHQL.
Leider gibt es für aktuelle NVIDIA-GPUs (z.B. 8xxx) keine "alten" Treiber, so dass wir die Graphikkarten in Netzwerken mit "roaming userprofiles" nicht verwenden können. Auch aktuelle Treiber-betas (169.xx_) liefern keine Verbesserung.
Seit Juli 2007 sind wir diesbezüglich per mail mit Nvidia in Kontakt. Ebenso mit Microsoft, da wir eine WHQL-Zertifizierung im beschriebenen Zusammenhang nicht nachvollziehen können.
Bis dato ohne Erfolg.
Unsere Recherchen ergaben, dass dieses Problem seit Januar 2007 in einigen amerikanischen Foren gepostet wurde - die letzten (frustrierten) Beiträge stammen dort vom Januar 2008.
Wir hoffen nun auf Hilfe oder Mitwirkung zum Problem in diesem Forum. Vielen Dank dafür ...
erb-wa
anbei folgendes Problem:
Wir setzen in allen Kundennetzwerken (Windows 2003 Std, SBS) servergestütze Userprofile ein, da die jeweiligen Mitarbeiter zeitweise die Arbeitsplätze wechseln, und Ihre gewohnte Arbeitsumgebung vorfinden wollen.
Seit einiger Zeit werden die Userprofile beim Logout nicht mehr auf den jeweiligen Server repliziert.
Dies betrifft userspezifische Einstellungen in allen MS Office Produkten (ab V. 2002) und in AutoCAD 2006. Fehler in den ActiveDirectories bzw. in den Profilkonfigurationen können wir ausschließen.
Wir haben das Problem eskaliert und konnten eindeutig und reproduzierbar die Ursache feststellen:
Auf den CAD-Workstations und Desktops setzen wir vorwiegend Nvidia-GPUs (Quattro FX, NV7xxx, NV8xxx) mit aktuellen Treibern (162.65_quadro_winxp2k_international_whql) ein. Diese verhindern jedoch beim Logout den Zugriff auf den im ActiveDirectory spezifizierten Profilordner. Unsere Tests ergaben, dass dieses Verhalten seit der Treiberversion 93.72_WHQL auftritt.
Onboard-Graphiken, z.B. von Intel, sind nicht betroffen.
Wird der Nvidia-Treiber vollständig vom System entfernt, so funktioniert die Profilreplikation wieder einwandfrei.
Als Workaround verwenden wir für die Quattro-GPUs nun veraltete Treiber bis 91.36_WHQL.
Leider gibt es für aktuelle NVIDIA-GPUs (z.B. 8xxx) keine "alten" Treiber, so dass wir die Graphikkarten in Netzwerken mit "roaming userprofiles" nicht verwenden können. Auch aktuelle Treiber-betas (169.xx_) liefern keine Verbesserung.
Seit Juli 2007 sind wir diesbezüglich per mail mit Nvidia in Kontakt. Ebenso mit Microsoft, da wir eine WHQL-Zertifizierung im beschriebenen Zusammenhang nicht nachvollziehen können.
Bis dato ohne Erfolg.
Unsere Recherchen ergaben, dass dieses Problem seit Januar 2007 in einigen amerikanischen Foren gepostet wurde - die letzten (frustrierten) Beiträge stammen dort vom Januar 2008.
Wir hoffen nun auf Hilfe oder Mitwirkung zum Problem in diesem Forum. Vielen Dank dafür ...
erb-wa
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 77950
Url: https://administrator.de/contentid/77950
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
11 Kommentare
Neuester Kommentar
Guten Tag,
mit großem Interesse habe ich Ihren Bericht bezüglich der Nvidia Treiber gelesen. Da ich vor dem selben Problem stehe und es auch mit der ForceWare-Version 174.31 keine Besserung zu geben scheint, würde mich interessieren, ob es von Nvidia einen Patch für dieses Problem gibt, oder ob Sie einen brauchbaren Workaround gefunden haben.
Gruß
J. Storch
mit großem Interesse habe ich Ihren Bericht bezüglich der Nvidia Treiber gelesen. Da ich vor dem selben Problem stehe und es auch mit der ForceWare-Version 174.31 keine Besserung zu geben scheint, würde mich interessieren, ob es von Nvidia einen Patch für dieses Problem gibt, oder ob Sie einen brauchbaren Workaround gefunden haben.
Gruß
J. Storch
Hallo J.Storch,
obwohl wir immer wieder bei nvidia und ms nachfragen wird das Problem von den Herstellern einfach ignoriert.
Generell überrascht mich auch die geringe Resonanz in den Foren, zumal das Problem ja häufiger auftreten sollte.
Übrigens tritt das Problem auch bei Mainboards mit onboard-Nvidia-Graphik auf.
Bei einigen wenigen Treiberversionen 154.x konnten wir das Problem durch Deaktivieren des Dienstes "NVIDIA Display Driver Service" umgehen. Allerdings sind diese Treiberversion wegen schlechter Stabilität nicht zu empfehlen. ansonsten verbleibt nur die Version 93.81, die auch mit 8xxx GPUs funktionieren.
Für typische Büro-PCs verwenden wir nur noch Intel-Mainboards (33er, 43er-Chipsätze) mit onboard Graphik. Die CAD-Workstations mit Mehrschirmlösungen an Quattro-GPUs betreiben wir mit 91.xx.
Leider, leider keine Entspannung in Sicht.
viele Grüße, erb-wa
obwohl wir immer wieder bei nvidia und ms nachfragen wird das Problem von den Herstellern einfach ignoriert.
Generell überrascht mich auch die geringe Resonanz in den Foren, zumal das Problem ja häufiger auftreten sollte.
Übrigens tritt das Problem auch bei Mainboards mit onboard-Nvidia-Graphik auf.
Bei einigen wenigen Treiberversionen 154.x konnten wir das Problem durch Deaktivieren des Dienstes "NVIDIA Display Driver Service" umgehen. Allerdings sind diese Treiberversion wegen schlechter Stabilität nicht zu empfehlen. ansonsten verbleibt nur die Version 93.81, die auch mit 8xxx GPUs funktionieren.
Für typische Büro-PCs verwenden wir nur noch Intel-Mainboards (33er, 43er-Chipsätze) mit onboard Graphik. Die CAD-Workstations mit Mehrschirmlösungen an Quattro-GPUs betreiben wir mit 91.xx.
Leider, leider keine Entspannung in Sicht.
viele Grüße, erb-wa
Hallo erb-wa,
ich habe heute nochmals einige Treiberversionen durchprobiert.
Ich war erfolgreich!!!
Die Version 156.65 in Kombination mit einer Quadro FX 360M und deaktiviertem Dienst "NVIDIA Display Driver Service" behindert nicht das Sichern und Laden von Benutzerprofilen. Die Stabilität des Treibers muss ich erst noch eingehender testen.
HTH
J.Storch
ich habe heute nochmals einige Treiberversionen durchprobiert.
Ich war erfolgreich!!!
Die Version 156.65 in Kombination mit einer Quadro FX 360M und deaktiviertem Dienst "NVIDIA Display Driver Service" behindert nicht das Sichern und Laden von Benutzerprofilen. Die Stabilität des Treibers muss ich erst noch eingehender testen.
HTH
J.Storch
Hallo erb-wa,
nach langer Suche bin ich schlußendlich auf Ihrem Beitrag gelandet, der Licht ins Dunkel bringt.
Das Problem haben sicher viele. Die wenigsten wären aber darauf gekommen, dass der Grafikkartentreiber hier der Spielverderber ist.
Wir haben hier bei uns im Netzwerk (500 Clients) dass gleiche Problem.
Davon werden ca 50 Profile nicht korrekt zurück geschrieben. Tests haben Ihre Beobachtung bestätigt.
Die betroffenen Clients setzen Nvidia-Grafikkarten ein. Nach Deinstallation der Treiber klappt die Speicherung der Profile wieder auf dem Server.
Kaum ist der Treiber wieder auf dem System installiert, war`s das mit servergespeicherten Profilen.....
Bevor wir Ihren Artikel gefunden haben , sind wir dem Problem mit einem Script zu Leibe gerückt.
Als Auslöser, warum das Profil nicht auf den Server geschrieben wird, haben wir 2 Einträge in der Registry identifizieren können.
Diese beiden Einträge werden beim Abmelden neu geschrieben.
Die installierten NVidia-Treiber verhindern hier aber offensichtlich, dass beide Einträge auf den identischen Wert gesetzt werden.
Der Pfad lautet.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ --SID..des..Users---
"NextLogonCacheable"=dword:00000000
"RefCount"=dword:00000001
Wenn diese beiden dword-Einträge, wie hier oben dargestellt, unterschiedlich sind, klappt das zurückspeichern der Profile nicht.
Sind sie allerdings identisch , geht alles wunderbar; auch mit NVidia-Treibern.
Unser Script ermittelt zuerst die SID des angemeldeten Users, weil das Bestandteil des Registry-Keys ist. Danach werden die beiden Werte auf 1 gesetzt.
Das Script muß allerdings bei jedem Anmeldevorgang ausgeführt werden (z.B. über Loginscript).
Solange von Seiten Microsoft und NVidia nichts passiert und man keinen passenden Treiber findet, ist das Script evtl. eine praktikable Lösung.
Hier der Code:
' Beginn Script
Dim objFSO, objFolder, strDirectory, oShell, strUser
set oShell = WScript.CreateObject("WScript.Shell")
' Verzeichnisname ermitteln
ordnerT1 = oShell.ExpandEnvironmentStrings("%userprofile%")
ordnerT2 = "\Lokale Einstellungen\Anwendungsdaten\Microsoft\Credentials"
ordnerT3= ordnerT1 & ordnerT2
set fs = CreateObject("Scripting.FileSystemObject")
'Meldung abgeschalten...kann zu Testzwecken, ob SID korrekt ausgelesen wurde, aktiviert werden
'MsgBox SID(ordnerT3)
' SID des User anhand des Unterordners von Credentials ermitteln
function SID (ordnerT3)
set ordner = fs.GetFolder(ordnerT3)
for each unterordner in ordner.subfolders
SID = SID + unterordner.Name
next
end function
' SID an den Registry-Pfad anhängen und die 2 notwendigen Werte abändern
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & SID(ordnerT3)
strValueName1 = "NextLogonCacheable"
dwValue = 00000001
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName1,dwValue
strValueName2 = "RefCount"
dwValue = 00000001
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName2,dwValue
'Ende des Scripts
Für den Einsatz des Scripts übernehme ich keine Haftung. Also bitte vorher ausgiebig testen...versteht sich aber normalerweise ja von selbst.
Viele Grüße
Scheiffeles
nach langer Suche bin ich schlußendlich auf Ihrem Beitrag gelandet, der Licht ins Dunkel bringt.
Das Problem haben sicher viele. Die wenigsten wären aber darauf gekommen, dass der Grafikkartentreiber hier der Spielverderber ist.
Wir haben hier bei uns im Netzwerk (500 Clients) dass gleiche Problem.
Davon werden ca 50 Profile nicht korrekt zurück geschrieben. Tests haben Ihre Beobachtung bestätigt.
Die betroffenen Clients setzen Nvidia-Grafikkarten ein. Nach Deinstallation der Treiber klappt die Speicherung der Profile wieder auf dem Server.
Kaum ist der Treiber wieder auf dem System installiert, war`s das mit servergespeicherten Profilen.....
Bevor wir Ihren Artikel gefunden haben , sind wir dem Problem mit einem Script zu Leibe gerückt.
Als Auslöser, warum das Profil nicht auf den Server geschrieben wird, haben wir 2 Einträge in der Registry identifizieren können.
Diese beiden Einträge werden beim Abmelden neu geschrieben.
Die installierten NVidia-Treiber verhindern hier aber offensichtlich, dass beide Einträge auf den identischen Wert gesetzt werden.
Der Pfad lautet.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ --SID..des..Users---
"NextLogonCacheable"=dword:00000000
"RefCount"=dword:00000001
Wenn diese beiden dword-Einträge, wie hier oben dargestellt, unterschiedlich sind, klappt das zurückspeichern der Profile nicht.
Sind sie allerdings identisch , geht alles wunderbar; auch mit NVidia-Treibern.
Unser Script ermittelt zuerst die SID des angemeldeten Users, weil das Bestandteil des Registry-Keys ist. Danach werden die beiden Werte auf 1 gesetzt.
Das Script muß allerdings bei jedem Anmeldevorgang ausgeführt werden (z.B. über Loginscript).
Solange von Seiten Microsoft und NVidia nichts passiert und man keinen passenden Treiber findet, ist das Script evtl. eine praktikable Lösung.
Hier der Code:
' Beginn Script
Dim objFSO, objFolder, strDirectory, oShell, strUser
set oShell = WScript.CreateObject("WScript.Shell")
' Verzeichnisname ermitteln
ordnerT1 = oShell.ExpandEnvironmentStrings("%userprofile%")
ordnerT2 = "\Lokale Einstellungen\Anwendungsdaten\Microsoft\Credentials"
ordnerT3= ordnerT1 & ordnerT2
set fs = CreateObject("Scripting.FileSystemObject")
'Meldung abgeschalten...kann zu Testzwecken, ob SID korrekt ausgelesen wurde, aktiviert werden
'MsgBox SID(ordnerT3)
' SID des User anhand des Unterordners von Credentials ermitteln
function SID (ordnerT3)
set ordner = fs.GetFolder(ordnerT3)
for each unterordner in ordner.subfolders
SID = SID + unterordner.Name
next
end function
' SID an den Registry-Pfad anhängen und die 2 notwendigen Werte abändern
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & SID(ordnerT3)
strValueName1 = "NextLogonCacheable"
dwValue = 00000001
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName1,dwValue
strValueName2 = "RefCount"
dwValue = 00000001
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName2,dwValue
'Ende des Scripts
Für den Einsatz des Scripts übernehme ich keine Haftung. Also bitte vorher ausgiebig testen...versteht sich aber normalerweise ja von selbst.
Viele Grüße
Scheiffeles
Hallo Scheiffeles,
eine lustige Sache Ihr script, haben's getestet und funktioniert recht gut.
Nichts desto trotz sind wir der Meinung dass im Dunstbereich der WHQL-Zertifizierung solche Fehler nicht vorkommen dürfen. Man stelle sich ja vor, dass das Problem seit 1,5 Jahren bekannt und dokumentiert ist., und wie - sollte es anders sein - natürlich auch Vista betroffen ist.
Wie auch immer, die Ursache ist ein Konflikt zwischen dem "NVIDIA Display Driver Service" und dem unter HKLM\...\RUN geladenen Nvidia Control Panel API.
Wenn man den Desktopmanager nicht braucht können die Registryeinträge gelöscht, und der Display- Service deaktiviert werden. Der Treiber wird ja trotzdem beim Systemboot geladen.
Bei diesem Konstrukt funktionieren stets die aktuellen Hardware-Treiber für den LowCost-Bereich, Multimonitorlösungen benötigen jedoch Ihr script.
viele Grüße
erb-wa
eine lustige Sache Ihr script, haben's getestet und funktioniert recht gut.
Nichts desto trotz sind wir der Meinung dass im Dunstbereich der WHQL-Zertifizierung solche Fehler nicht vorkommen dürfen. Man stelle sich ja vor, dass das Problem seit 1,5 Jahren bekannt und dokumentiert ist., und wie - sollte es anders sein - natürlich auch Vista betroffen ist.
Wie auch immer, die Ursache ist ein Konflikt zwischen dem "NVIDIA Display Driver Service" und dem unter HKLM\...\RUN geladenen Nvidia Control Panel API.
Wenn man den Desktopmanager nicht braucht können die Registryeinträge gelöscht, und der Display- Service deaktiviert werden. Der Treiber wird ja trotzdem beim Systemboot geladen.
Bei diesem Konstrukt funktionieren stets die aktuellen Hardware-Treiber für den LowCost-Bereich, Multimonitorlösungen benötigen jedoch Ihr script.
viele Grüße
erb-wa
Dieser Beitrag hat mir unglaublich weiter geholfen. Ich hatte das o.g. Problem in einer relativ neuen Umgebung, bestehend aus Windows Server 2008 64bit und 5 Clients mit Windows Vista Ultimate 64bit.
Als ich den Server vor ca. 6 Monaten eingerichtet habe, war mit den servergespeicherten Profilen alles in Butter.
Seit 2 Wochen trat dann das oben beschriebene Fehlverhalten auf und ich war echt Ratlos.
Abhilfe hat bei mir folgendes Vorgehen gebracht:
1. via Systemsteuerung-Software den nVidia-Treiber deinstallieren
2. neu starten
3. mit dem Driver-Sweeper (Ver. 1.5.5 von http://www.guru3d.com/) sämtliche nVidia-Reste eliminieren
4. neu starten
5. Download der aktuellen Treiber (Ver. 182.50 vom 02. April 2009) + Install
6. neu starten
7. siehe da - alles in bester Ordung!!!
Also, Danke noch mal für den Beitrag - ich hätte sonst keinen Lösungsansatz gehabt!!!
Als ich den Server vor ca. 6 Monaten eingerichtet habe, war mit den servergespeicherten Profilen alles in Butter.
Seit 2 Wochen trat dann das oben beschriebene Fehlverhalten auf und ich war echt Ratlos.
Abhilfe hat bei mir folgendes Vorgehen gebracht:
1. via Systemsteuerung-Software den nVidia-Treiber deinstallieren
2. neu starten
3. mit dem Driver-Sweeper (Ver. 1.5.5 von http://www.guru3d.com/) sämtliche nVidia-Reste eliminieren
4. neu starten
5. Download der aktuellen Treiber (Ver. 182.50 vom 02. April 2009) + Install
6. neu starten
7. siehe da - alles in bester Ordung!!!
Also, Danke noch mal für den Beitrag - ich hätte sonst keinen Lösungsansatz gehabt!!!
Hallo,
ich habe das Problem jetzt auch bei uns im Netzwerk bemerkt!
Kann ich das Script welches oben gepostet wurde einfach verwenden?
Auch auf Rechnern wo keine Nvidia Grafikkarte verbaut wurde oder kann es hier zu Problemen führen?
Danke
ich habe das Problem jetzt auch bei uns im Netzwerk bemerkt!
Kann ich das Script welches oben gepostet wurde einfach verwenden?
Auch auf Rechnern wo keine Nvidia Grafikkarte verbaut wurde oder kann es hier zu Problemen führen?
Danke
Hallo fotofabi,
vermutlich geht es um die generelle Einbindung des Scripts in ein Loginscript.
Ich denke es ist verwendbar, habe es aber nicht getestet.
Übrigens können wir den Kommentar von ruecker vom 08.04.2009 nicht reproduzierbar bestätigen. Tatsächlich hat es einigemale funktioniert, in der Mehrzahl jedoch nicht. Defekt wird die Profilreplikation bei unseren Tests stets wenn versehentlich die MS Geräteupdates installiert wurden (!).
Aktuell verwenden wir für die Graphik-Workstations keine Nvidia-GPUs mehr sondern AMD (ATI-Fire-Serien). Diese bieten unter 3d-max und autocad aus unserer Sicht die bessere Performance und Systemunterstützung - besonders auch bei der Verwendung von Zeigegeräten von 3dconnexion. Die normalen Büro-PCs sind mit onboard-Graphiken von Intel völlig ausreichend bedient.
vermutlich geht es um die generelle Einbindung des Scripts in ein Loginscript.
Ich denke es ist verwendbar, habe es aber nicht getestet.
Übrigens können wir den Kommentar von ruecker vom 08.04.2009 nicht reproduzierbar bestätigen. Tatsächlich hat es einigemale funktioniert, in der Mehrzahl jedoch nicht. Defekt wird die Profilreplikation bei unseren Tests stets wenn versehentlich die MS Geräteupdates installiert wurden (!).
Aktuell verwenden wir für die Graphik-Workstations keine Nvidia-GPUs mehr sondern AMD (ATI-Fire-Serien). Diese bieten unter 3d-max und autocad aus unserer Sicht die bessere Performance und Systemunterstützung - besonders auch bei der Verwendung von Zeigegeräten von 3dconnexion. Die normalen Büro-PCs sind mit onboard-Graphiken von Intel völlig ausreichend bedient.
hab grad dies hier gefunden: KB897101
vielleicht hilfts ja jemandem noch mal...
vielleicht hilfts ja jemandem noch mal...
Hallo ruecker,
zu obigem Link, den wir natürlich auch kennen:
Methode 1) ist nicht zielführend, da auch die neuesten NVIDIA-Treiber stets das selbe Problem haben. Typisch WHQL.
Methode 2) setzen wir generell seit etlichen Monaten ein. Ist unkritisch bei normalen Desktop-Anwendungen mit einem Monitor.
Bei unseren Multimonitor-CAD-Anlagen reagieren die Quadro-Treiber empfindlich auf userspezifische Desktopkonfigurationen.
Nvidia ist bis zum heutigen Tag nicht in der Lage das Desktopmanagement vernüntig zu programmieren, sodaß roaming Profiles einschränkungsfrei funktionieren. Matrox hat das besser im Griff. Matrox hat allerdings Probleme mit Quad-Cores und Quad-Xeons auf Intel-Boards und liefert keine für Autodesk zertifizierten 3D-Karten.
viele Grüße
erb-wa
zu obigem Link, den wir natürlich auch kennen:
Methode 1) ist nicht zielführend, da auch die neuesten NVIDIA-Treiber stets das selbe Problem haben. Typisch WHQL.
Methode 2) setzen wir generell seit etlichen Monaten ein. Ist unkritisch bei normalen Desktop-Anwendungen mit einem Monitor.
Bei unseren Multimonitor-CAD-Anlagen reagieren die Quadro-Treiber empfindlich auf userspezifische Desktopkonfigurationen.
Nvidia ist bis zum heutigen Tag nicht in der Lage das Desktopmanagement vernüntig zu programmieren, sodaß roaming Profiles einschränkungsfrei funktionieren. Matrox hat das besser im Griff. Matrox hat allerdings Probleme mit Quad-Cores und Quad-Xeons auf Intel-Boards und liefert keine für Autodesk zertifizierten 3D-Karten.
viele Grüße
erb-wa
Bei uns wurden auf einem Client auch keine servergespeicherten Profile gespeichert.
Grund war auch die nvidia Grafikkarte.
Es hat allerdings ausgereicht, den nvidia-Dienst zu deaktivieren und den Client PC neu zu starten.
Seit dem wird das Profil auf dem Server gespeichert.
Grund war auch die nvidia Grafikkarte.
Es hat allerdings ausgereicht, den nvidia-Dienst zu deaktivieren und den Client PC neu zu starten.
Seit dem wird das Profil auf dem Server gespeichert.
