Sunny61

Auf einem Testclient kannst Du diese Vorgehensweise ausprobieren: http://windows.microsoft.com/de-DE/windows-vista/Fix-a-corrupted-user-profile Der Benutzer muss sich allerdings schon einmal angemeldet haben, dann kannst Du versuchen den Inhalt des alten in das neue Profile zu kopieren. Anschließend unbedingt neu starten. Kann funktionieren, muss aber nicht.

Gibt es dafür denn auch einen guten nachvollziehbaren Grund? Sind das evtl. mobile Geräte und Du möchtest das sich die Benutzer auch ohne Kontakt zu einem DC anmelden können? Ist der Benutzer denn dann auf dem Client in den lokalen Benutzerkonten zu sehen? Auf einem solchen Client: Start > Ausführen > lusrmgr.msc [ENTER]. Wird der Benutzer hier angezeigt? Du hast das GPO auf eine OU gelegt in der sich das *Computerkonto* befindet? Anschließend mußt Du den Rechner einmal neu starten, jetzt anmelden und LUSRMGR.MSC aufrufen. Ist der lokale Benutzer vorhanden? Wenn ja, dann kannst Du hier weitermachen: http://www.gruppenrichtlinien.de/artikel/verwaltung-der-lokalen-administratoren/ http://www.gruppenrichtlinien.de/artikel/zentrale-vergabe-lokaler-berechtigungen/ http://www.gruppenrichtlinien.de/artikel/lokaler-administrator-install-agent-delegation-pro-computer/

Du hast im SYSTEM-Protokoll nachgesehen? Erscheint überhaupt eine Meldung im Log?

Dort ist von einer RDP-CAL nichts zu lesen. Du hast ein OS gemietet und da ist ein administrativer Zugang via RDP enthalten. Wie der Name schon sagt ist das ein Zugriff zum administrieren. Wenn Du in VS effektiv arbeiten willst bzw. tust, benötigst Du sog. RDP-CALs, zumindest eine für dich.

Starte auf einem Client den Dienst Windows-Zeitgeber neu und sieh nach 30 Sekunden im System-Eventlog nach. Time-Service EventID 35 sollte gelogt werden.

Freut mich für Dich und Danke für die ausführliche Rückmeldung. ;)

Mit dem User State Migration Tool kannst Du die Profile migrieren: http://technet.microsoft.com/de-de/library/dd560801%28v=ws.10%29.aspx

Auf die Fragen hast Du sicher schon gewartet: Was sagt der Hersteller der SW? Wer hat die SW installiert?

Und was ist mit den restlichen Fragen/Hinweisen? Zugriff verweigert deutet sehr stark auf 'raus aus der Domain, und wieder rein in die Domain'.

Alles komplett in den Schrank legen, Rechnung auch dazu legen, sollte reichen.

Falls die Frage noch aufkommen sollte, der SBS kann auch keine Vertrauensstellung aufbauen. Und ja, es kann durchaus sein dass trotz unterschiedlicher NetBIOS Namen sich einer oder beide SBS alle 2 Stunden abschalten. Wenn das der Fall ist, mußt Du einen vom Netz nehmen. Weshalb habt ihr nicht den SBS2011 als Ablösung für den SBS2003 konfiguriert? Swing-Migration nennt man so etwas. Dabei bleibt das vollständige AD erhalten. Der SBS2003 ist auch IMHO schon aus dem Support, sollte eigentlich auch vollkommen abgeschaltet werden.

So ein Exchange ist ein lebendes System, das sollte man regelmäßig aktualisieren. Sei froh dass Du bisher noch nicht in größere Bugs gelaufen bist. Off-Topic: Finde ich auch nervig dass mein Auto 14 Tage seinen Dienst verrichtet hat, und dann plötzlich ohne Benzin liegen bleibt! :)

Im SQL Server-Management Studio Rechtsklick auf die Datenbank > Tasks > Sichern. Auf dem Ziel SQL-Server dann über Tasks > Rechtsklick > Wiederherstellen > Dateien.

lt. http://technet.microsoft.com/library/hh135098%28v=exchg.150%29.aspx ist dein Exchange auf einem sehr alten Stand. IMHO solltest Du erst vollständig updaten, dann erneut testen.

Die FSMO-Rollen mußt Du nicht aufteilen. Gibt es Fehlermeldungen im Ereignisprotokoll? Wenn Du auf DC1 im Netlogon eine Datei anlegst, wird auch auf DC repliziert?

Das ist nicht das Ereignisprotokoll, sieh im Ereignisprotokoll nach, wie zahni schon schrub.

Mag ja sein, aber wenn die Chemie nicht stimmt ist es IMHO besser selbst die Reißleine zu ziehen als das sie evtl. später jemand anders für dich zieht.

Welche genaue Fehlermeldung findest Du dazu im Ereignisprotokoll?

Off-Topic: Dann sollte man das IMHO auch tun.

Viele der heutige AV-Scanner klinken sich IMHO einfach viel zu tief ins System ein, das nervt ungemein. Off-Topic: Wir verwenden F-Secure, das nervt auch immer wieder ungemein. Bei NOD32 gibt es auch den ein oder anderen Kritikpunkt, einer davon ist die Admin-Konsole. So umfangreich wie sie ist, sie gewöhnungsbedürftig ist sie. ;)

Wie soll man dir aufgrund deiner Aussagen helfen? Mir fällt nur ein dass alle Benutzer ein und dasselbe servergespeicherte Benutzerprofil haben und du Chrome ins Benutzerprofil installiert hast. So können alle Leute davon profitieren. ;) Weshalb installierst Du Chrome auf einem Server? Ist das ein Terminalserver? Wenn ja, dann frag deinen Admin was Du falsch gemacht hast. BTW: Deine ?-Taste prellt.

Bevor ich mich mit einem Problem wie in PANDA rumschlage, greife ich lieber zu bewährtem. ;)

Es wird wohl am besten sein, Du installierst den Client vollständig neu. Dann nimmst Du ihn neu in die Domain auf und probierst es erneut.

Es ist auch kompetent wenn man zum Chef geht und deutlich macht, dass man diesen Job, bwz. diese Aufgabe nicht ausführen kann. Hol dir einen Dienstleister, schau ihm über die Schulter und lerne dabei.

Bitte, gern geschehen. ;) Freut mich für Dich und Danke für die Rückmeldung. ;) Nein, ein AV-Scanner ist sehr häufig die Ursache für alles mögliche und unmögliche. ;) Wenn er etwas kosten darf, dann NOD32, aber nur den AV-Scanner. Bei Freeware kannst Du die Microsoft Securty Essentials verwenden.