Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Win XP Pro x64 Edition Benutzerprofil auf Server 2003 Standard Edition 32 bit

Frage Microsoft Windows Userverwaltung

Mitglied: 2336

2336 (Level 1)

23.11.2007, aktualisiert 29.11.2007, 6201 Aufrufe, 5 Kommentare

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
Mitglied: 47674
23.11.2007 um 19:50 Uhr
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)
Bitte warten ..
Mitglied: 2336
23.11.2007 um 21:35 Uhr
Hallo Daedalus,

Danke schon mal für deine Antworten.
Berechtigungen sind schon richtig gesetzt, Profilpfad auch richtig erstellt und eingetragen \\server\profiles\%username%
Zugriff auf den Profilpfad über die Netzwerkumgebung auch möglich, also genau auf dem gleichen Weg, wie eingetragen... Habe das ganze Profil von lokal auch schon da hin kopiert.
Ich habe jetzt auch mal im eventlog nachgesehen (besser spät als nie) und da steht was von DCOM drinne..... den genauen Wortlaut schaue ich mir morgen nochmal an und poste den hier.
Ich denke, damit hängt das zusammen, die Fehlermeldung hört sich ganz stark nach einer lokalen Einschränkung an.
Das Problem mit der Sprache schien mir eigentlich auch unplausibel,, weil es ja eigentlich nur irgendwelche Daten sind, die da gespeichert werden sollen, keine Daten mit denen der Server etwas anfangen muss.....

Bis morgen, danke nochmal,

Roman
Bitte warten ..
Mitglied: Wappel
23.11.2007 um 22:57 Uhr
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):


>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.

Quelle: Microsoft

Mit freundlichen Grüßen Michel
Bitte warten ..
Mitglied: 2336
24.11.2007 um 09:52 Uhr
Hallo Michel,

Danke auch dir für deine Beschreibung. Habe es versucht, doch bei mir gibt es keine CERTSVC_DCOM_ACCESS security group, weder auf derm Server, noch auf dem Client...
Auch der Befehl wird wohl eher nicht verstanden (certutil –setreg SetupStatus –SETUP_DCOM_SECURITY_UPDATED_FLAG ) weder auf dem Server, noch auf dem Client.....

Hier nochmal die Infos: Server: Windows Server 2003 Std Editioni deutsch 32 bit.
Client: Windows XP x64 Edition englisch

Hier die Fehlermeldung, von der ich ganz stark vermute, dass diese durch das Nichtspeichern verursacht wird:
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{555F3418-D99E-4E51-800A-6E89CFD8B1D7}
to the user NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19). This security permission can be modified using the Component Services administrative tool.

hmm... sagt mir jetzt wenig, was da zu tun ist. in dem angesprochenen tool habe ich schon nachgeschaut, aber wo soll ich da die Berechtigungen ändern /setzen....

Danke nochmal,

Roman
Bitte warten ..
Mitglied: Wappel
29.11.2007 um 17:45 Uhr
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
"----"
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.


Mit freundlichen Grüßen Michael
Bitte warten ..
Neuester Wissensbeitrag
CPU, RAM, Mainboards

Angetestet: PC Engines APU 3a2 im Rack-Gehäuse

(1)

Erfahrungsbericht von ashnod zum Thema CPU, RAM, Mainboards ...

Ähnliche Inhalte
Windows Netzwerk
SMBv2 in Windows 7 - Windows XP - Windows Server 2003 Domäne deaktivieren (4)

Frage von Mario.Steinberg zum Thema Windows Netzwerk ...

Windows Netzwerk
Windows Server 2003 SBS Netzwerk durch neuen Server Ersetzen (9)

Frage von MultiStorm zum Thema Windows Netzwerk ...

Windows Server
gelöst Windows Server 2012 Standard Upgrade auf R2 (8)

Frage von Hendrik2586 zum Thema Windows Server ...

Heiß diskutierte Inhalte
Grafikkarten & Monitore
Win 10 Grafikkarte Crash von Software? (13)

Frage von Marabunta zum Thema Grafikkarten & Monitore ...

DSL, VDSL
DSL-Signal bewerten (13)

Frage von SarekHL zum Thema DSL, VDSL ...

Switche und Hubs
Trunk für 2xCisco Switch. Wo liegt der Fehler? (9)

Frage von JayyyH zum Thema Switche und Hubs ...

Windows Server
Mailserver auf Windows Server 2012 (9)

Frage von StefanT81 zum Thema Windows Server ...