2336
23.11.2007, aktualisiert am 29.11.2007
6868
5
0
Win XP Pro x64 Edition Benutzerprofil auf Server 2003 Standard Edition 32 bit
Benutzerprofil läßt sich nicht serverspeichern
Hallo an alle Cracks hier,
Ich habe mich jetzt endlicherweise zu einem 64 bit System für meine Workstation durchringen können, habe aber jetzt folgendes Problem:
Auf dem Domaincontroller (Server 2003 Std Edition) wird im AD ein neues Benutzerprofil angelegt. Danach melde ich mich an meiner Workstation mit diesem Benutzernamen an - Profil wird erstellt, auch ein Verzeichnis im Profiles Verzeichnis auf dem Server. So weit so gut, aber wenn ich mich jetzt
abmelde, wird das Profil nicht auf dem Server aktualisiert - was heisst, nicht aktualisiert, es wird gar nichts in das Verzeichnis geschrieben. Der Ordner ist einfach leer.
Das ganze habe ich nicht glauben wollen, habe mich gleich drei mal an und abgemeldet, aber das Verzeichnis auf dem Server bleibt leer.
Auf der Workstation ist Windows XP x64 Pro installiert (englisch ohne language pack ger). Ich dachte mir, vielleicht liegt´s ja an der 64 bit Edition, aber ich habe auch schon Vista 64 bit im Einsatz gehabt, aber aus Kompatibilitätsgründen wieder gekillt. Da wurde auch problemlos ein Profilverzeichnis angelegt und auch akutalisert.....
Jetzt liegt natürlich nahe, dass es am fehlenden deutschpack liegt. Ist das möglich? Oder welche anderen Alternativen gibt es noch? Ich habe auch nicht gerne ein Mix Betriebssystem, entweder oder, aber wenn es daran liegt, werde ich wohl das german pack drüber laufen lassen müssen.
Was meint ihr dazu?
Vielen Dank schon mal und beste Grüße,
Roman
Hallo an alle Cracks hier,
Ich habe mich jetzt endlicherweise zu einem 64 bit System für meine Workstation durchringen können, habe aber jetzt folgendes Problem:
Auf dem Domaincontroller (Server 2003 Std Edition) wird im AD ein neues Benutzerprofil angelegt. Danach melde ich mich an meiner Workstation mit diesem Benutzernamen an - Profil wird erstellt, auch ein Verzeichnis im Profiles Verzeichnis auf dem Server. So weit so gut, aber wenn ich mich jetzt
abmelde, wird das Profil nicht auf dem Server aktualisiert - was heisst, nicht aktualisiert, es wird gar nichts in das Verzeichnis geschrieben. Der Ordner ist einfach leer.
Das ganze habe ich nicht glauben wollen, habe mich gleich drei mal an und abgemeldet, aber das Verzeichnis auf dem Server bleibt leer.
Auf der Workstation ist Windows XP x64 Pro installiert (englisch ohne language pack ger). Ich dachte mir, vielleicht liegt´s ja an der 64 bit Edition, aber ich habe auch schon Vista 64 bit im Einsatz gehabt, aber aus Kompatibilitätsgründen wieder gekillt. Da wurde auch problemlos ein Profilverzeichnis angelegt und auch akutalisert.....
Jetzt liegt natürlich nahe, dass es am fehlenden deutschpack liegt. Ist das möglich? Oder welche anderen Alternativen gibt es noch? Ich habe auch nicht gerne ein Mix Betriebssystem, entweder oder, aber wenn es daran liegt, werde ich wohl das german pack drüber laufen lassen müssen.
Was meint ihr dazu?
Vielen Dank schon mal und beste Grüße,
Roman
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 74352
Url: https://administrator.de/contentid/74352
Ausgedruckt am: 26.11.2024 um 14:11 Uhr
5 Kommentare
Neuester Kommentar
Also die Sprache würde ich ausschließen,ich denke das Problem liegt woanders. Zumindest gibt es in unserer Umgebung XP (allerdings 32-Bit) und 2k Rechner mit Multilingual User Interface. Auch wenn alle auf Englischer Basis sind, sind doch die Profile alle gemixt: Einige User haben deutsche - andere Englisch, je nachdem welche Sprache sie gewählt haben.
Ich kann mir das Problem eigentlich auch nicht erklären, also nenne ich mal die Punkte, die ich alls erstes Prüfen würde:
- Profil Pfad im Objekt des Benutzers im AD korrekt eingetragen (gehe ich mal von aus, da der Ordner auf dem Server ja erstellt wurde)
- Stimmen die Berechtigungen für den Profilordner auf dem Server
- Ist es möglich manuell mit dem entsprechendem Benutzer Datein in den Profil-Ordner auf dem Server zu speichern? (Dabei den Pfad aus dem AD 1 zu 1 übernehmen)
Ich kann mir das Problem eigentlich auch nicht erklären, also nenne ich mal die Punkte, die ich alls erstes Prüfen würde:
- Profil Pfad im Objekt des Benutzers im AD korrekt eingetragen (gehe ich mal von aus, da der Ordner auf dem Server ja erstellt wurde)
- Stimmen die Berechtigungen für den Profilordner auf dem Server
- Ist es möglich manuell mit dem entsprechendem Benutzer Datein in den Profil-Ordner auf dem Server zu speichern? (Dabei den Pfad aus dem AD 1 zu 1 übernehmen)
Hallo
Lies mal das, vielleicht hilft dir das weiter. Ich hatte auch dieses Problem und nach dem Anpassen der Rechte hat alles funktioniert.
Hier ein wichtiger Hinweis zur Installation im Hinblick auf DCOM und
Remotezugriffsrechte:
MS hat in den Release Notes zum SP1 darauf hingewiesen, daß die DCOM-Konfiguration
abgeändert wird, um sie entsprechend härten zu können. Die Änderungen sind hier auch im
Detail beschrieben. Wenn also nach der Installation massive Probleme im Hinblick auf den
Remote-Zugriff auftreten, so sollte man die Release Notes noch einmal genau lesen und ggfs.
die für DCOM eingestellten Rechte mit der MMC-Konsole dcomcnfg.msc überprüfen.
Hier ein die DCOM-Komponenten betreffender Auszug aus den Release Notes (Quelle:
Microsoft):
Quelle: Microsoft
MfG Michel
Lies mal das, vielleicht hilft dir das weiter. Ich hatte auch dieses Problem und nach dem Anpassen der Rechte hat alles funktioniert.
Hier ein wichtiger Hinweis zur Installation im Hinblick auf DCOM und
Remotezugriffsrechte:
MS hat in den Release Notes zum SP1 darauf hingewiesen, daß die DCOM-Konfiguration
abgeändert wird, um sie entsprechend härten zu können. Die Änderungen sind hier auch im
Detail beschrieben. Wenn also nach der Installation massive Probleme im Hinblick auf den
Remote-Zugriff auftreten, so sollte man die Release Notes noch einmal genau lesen und ggfs.
die für DCOM eingestellten Rechte mit der MMC-Konsole dcomcnfg.msc überprüfen.
Hier ein die DCOM-Komponenten betreffender Auszug aus den Release Notes (Quelle:
Microsoft):
Security Certificate Services: Effects of security enhancements to the DCOM protocol
Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM
protocol. Specifically, SP1 introduces more precise rights that give an administrator
independent control over local and remote permissions for launching, activating, and
accessing COM servers.
Windows Server 2003 Certificate Services provides enrollment and administration services by
using the DCOM protocol. Certificate Services provides several DCOM interfaces to make
these services available. For correct access and usage of these services, Certificate Services
assumes that its DCOM interfaces are set to permit remote activation and access permissions.
However, because of the enhanced default security settings for DCOM that are introduced by
SP1, you may have to update these security settings to make sure of the continued availability
of these services after you install SP1. The following information explains how to do this.
By default, all DCOM interfaces in Windows Server 2003 SP1 are configured to grant remote
access permissions, remote launch permissions, and remote activation permissions only to
administrators. However, when you upgrade to Windows Server 2003 SP1, security
configuration changes are made to the global DCOM interface and to the CertSrv Request
DCOM interface. These changes are made to enable Certificate Services to work correctly.
Note that any changes that have been made to the CertSrv Request DCOM interface security
settings before the installation of SP1 will be lost. The SP1 installation procedure resets all
previous security settings in the CertSrv Request DCOM interface to their default settings.
During the SP1 installation process, Certificate Services automatically updates the DCOM
security settings as follows:
• CertSrv Request DCOM interface:
• The Everyone security group is granted local and remote access permissions.
• The Everyone security group is granted local and remote activation permissions.
• The Everyone security group is not granted local or remote launch permissions.
• DCOM Computer Restriction Settings:
• A new security group, CERTSVC_DCOM_ACCESS, is automatically created.
If the certification authority is installed on a member server, CERTSVC_DCOM_ACCESS is
a computer local group, and the Everyone security group is added to it.
If the certification authority is installed on a domain controller, CERTSVC_DCOM_ACCESS
is a domain local group. The Domain Users security group and the Domain Computers
security group from the certification authority’s domain are added to it.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote access
permissions.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote activation
permissions.
• The CERTSVC_DCOM_ACCESS security group is not granted local or remote launch
permissions.
Note that if the certification authority is installed on a domain controller, and the enterprise
is made up of more than one domain, Certificate Services cannot automatically update the
DCOM security settings for enrollees from outside the certification authority’s domain.
Therefore, these enrollees will be denied enroll access to the certification authority.
To resolve this issue, you must manually add the users to the CERTSVC_DCOM_ACCESS
security group. Because the CERTSVC_DCOM_ACCESS security group is a domain local
group, you can add only domain groups to it. For example, if users and computers from
another domain, a domain named Contoso, have to enroll with the certification authority, you
must manually add the Contoso\Domain Users group and the Contoso\Domain Computers
group to the CERTSVC_DCOM_ACCESS security group.
If any enrollees that should be authorized by the certification authority are denied
authorization after the installation of SP1, you can have Certificate Services update the
DCOM security settings again. To do this, run the following commands at the command
prompt in the following order. Press ENTER after each command.
1. certutil –setreg SetupStatus –SETUP_DCOM_SECURITY_UPDATED_FLAG
2. net stop certsvc
3. net start certsvc
The DCOM_SECURITY_UPDATED_FLAG is an internal Certificate Services registry flag
that indicates that the DCOM security settings were updated completely and successfully.
Certificate Services checks this flag every time that it is started. The commands in the
previous list reset the flag and then stop and start Certificate Services, causing it to update
the DCOM security settings again.
Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM
protocol. Specifically, SP1 introduces more precise rights that give an administrator
independent control over local and remote permissions for launching, activating, and
accessing COM servers.
Windows Server 2003 Certificate Services provides enrollment and administration services by
using the DCOM protocol. Certificate Services provides several DCOM interfaces to make
these services available. For correct access and usage of these services, Certificate Services
assumes that its DCOM interfaces are set to permit remote activation and access permissions.
However, because of the enhanced default security settings for DCOM that are introduced by
SP1, you may have to update these security settings to make sure of the continued availability
of these services after you install SP1. The following information explains how to do this.
By default, all DCOM interfaces in Windows Server 2003 SP1 are configured to grant remote
access permissions, remote launch permissions, and remote activation permissions only to
administrators. However, when you upgrade to Windows Server 2003 SP1, security
configuration changes are made to the global DCOM interface and to the CertSrv Request
DCOM interface. These changes are made to enable Certificate Services to work correctly.
Note that any changes that have been made to the CertSrv Request DCOM interface security
settings before the installation of SP1 will be lost. The SP1 installation procedure resets all
previous security settings in the CertSrv Request DCOM interface to their default settings.
During the SP1 installation process, Certificate Services automatically updates the DCOM
security settings as follows:
• CertSrv Request DCOM interface:
• The Everyone security group is granted local and remote access permissions.
• The Everyone security group is granted local and remote activation permissions.
• The Everyone security group is not granted local or remote launch permissions.
• DCOM Computer Restriction Settings:
• A new security group, CERTSVC_DCOM_ACCESS, is automatically created.
If the certification authority is installed on a member server, CERTSVC_DCOM_ACCESS is
a computer local group, and the Everyone security group is added to it.
If the certification authority is installed on a domain controller, CERTSVC_DCOM_ACCESS
is a domain local group. The Domain Users security group and the Domain Computers
security group from the certification authority’s domain are added to it.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote access
permissions.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote activation
permissions.
• The CERTSVC_DCOM_ACCESS security group is not granted local or remote launch
permissions.
Note that if the certification authority is installed on a domain controller, and the enterprise
is made up of more than one domain, Certificate Services cannot automatically update the
DCOM security settings for enrollees from outside the certification authority’s domain.
Therefore, these enrollees will be denied enroll access to the certification authority.
To resolve this issue, you must manually add the users to the CERTSVC_DCOM_ACCESS
security group. Because the CERTSVC_DCOM_ACCESS security group is a domain local
group, you can add only domain groups to it. For example, if users and computers from
another domain, a domain named Contoso, have to enroll with the certification authority, you
must manually add the Contoso\Domain Users group and the Contoso\Domain Computers
group to the CERTSVC_DCOM_ACCESS security group.
If any enrollees that should be authorized by the certification authority are denied
authorization after the installation of SP1, you can have Certificate Services update the
DCOM security settings again. To do this, run the following commands at the command
prompt in the following order. Press ENTER after each command.
1. certutil –setreg SetupStatus –SETUP_DCOM_SECURITY_UPDATED_FLAG
2. net stop certsvc
3. net start certsvc
The DCOM_SECURITY_UPDATED_FLAG is an internal Certificate Services registry flag
that indicates that the DCOM security settings were updated completely and successfully.
Certificate Services checks this flag every time that it is started. The commands in the
previous list reset the flag and then stop and start Certificate Services, causing it to update
the DCOM security settings again.
Quelle: Microsoft
MfG Michel
Hallo Roman
Hab erst mal die Übersetzung deines Fehlers und vielleicht auch die Lösung
Durch die Berechtigungseinstellungen (Computerstandard) wird der SID (S-1-5-19) für Benutzer > NT-AUTORITÄT\LOKALER DIENST keine Aktivierungberechtigung (Lokal) für die
COM-Serveranwendung mit CLSID
{555F3418-D99E-4E51-800A-6E89CFD8B1D7}
gewährt. Diese Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für
Komponentendienste geändert werde
"----"
MfG Michael
Hab erst mal die Übersetzung deines Fehlers und vielleicht auch die Lösung
Durch die Berechtigungseinstellungen (Computerstandard) wird der SID (S-1-5-19) für Benutzer > NT-AUTORITÄT\LOKALER DIENST keine Aktivierungberechtigung (Lokal) für die
COM-Serveranwendung mit CLSID
{555F3418-D99E-4E51-800A-6E89CFD8B1D7}
gewährt. Diese Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für
Komponentendienste geändert werde
Der Fehler sollte verschwinden, wenn du: in der Diensteverwaltung beim Dienst
Shellhardwareerkennung in den Eigenschaften im Reiter <Anmelden> den Punkt <Dieses
Konto> aktivierst und dort dann NT AUTHORITY\LocalService einträgst.
Diesen Namen am besten vom Dienst Remote-Registrierung rauskopieren, dann stimmt er auch > überein.
Kopier dir den Namen in den Editor, das Passwort dann über STRG-C & STRG-V in das Feld kopieren und zum Schluss den Kontonamen.Shellhardwareerkennung in den Eigenschaften im Reiter <Anmelden> den Punkt <Dieses
Konto> aktivierst und dort dann NT AUTHORITY\LocalService einträgst.
Diesen Namen am besten vom Dienst Remote-Registrierung rauskopieren, dann stimmt er auch > überein.
MfG Michael