NilsK

Moin, ... nämlich warum? Wenn du dein Problem beschreibst, gibt es eine Chance, dass dir geholfen wird. (Wobei es hier im Board nur wenige Entwickler gibt, daher sind wir für derartige Fragen nicht immer die beste Anlaufstelle.) Gruß, Nils

Moin, hältst du es evtl. für möglich, dass niemand eine Antwort geben kann? Pushen von Beiträgen ist in keinem Forum gern gesehen. Nur so als allgemeiner Hinweis. Gruß, Nils

Moin, die Aufgabe ist nicht schwer zu lösen, aber für die Erzeugung von hochriskanten Kennwörtern gebe ich keine Unterstützung. Tut mir Leid. Vielleicht jemand anders. Gruß, Nils

Moin, wenn es denn unbedingt sein muss: Stufe den "alten" DC herunter und gib dem Server dann eine neue IP-Adresse. Dann ändere die IP-Adresse des neuen DC und starte die Anmeldedienste auf dem neuen DC neu. Danach solltest du noch mal manuell das DNS (und ggf. WINS) untersuchen, ob die Änderung überall korrekt vollzogen wurde. Bedenke auch, dass du für einen sinnvollen Betrieb mindestens zwei DCs brauchst. Gruß, Nils

Moin, das "Offline"-Szenario selbst stellt für das Computerkennwort kein Problem dar. Der Computer kann sein abgelaufenes Kennwort ändern, solange es noch korrekt ist. Die Änderung nimmt AD immer nur vor, wenn es mit dem Computer kommunizieren kann. Problematisch ist das Computerkennwort nur, wenn man einen Rechner auf einen historischen Zustand zurücksetzt: Im Image ist das Kennwort "A" hinterlegt, das zum Zeitpunkt des Image aktuell war. Nach dem Erzeugen ändert der Computer sein Kennwort im AD auf "B", alles OK. Spielt man nun das Image zurück, hat der Computer wieder "A" als Kennwort, im AD steht aber "B". Es muss also in deiner Situation etwas anderes im Spiel sein. Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Gruß, Nils

Moin, die richtige Lösung für dein Szenario ist: mach ein sauberes Backup und gut ist, oder installiere noch weitere DC in der Domaine Gruß, Nils

Moin, definiere "Komplette Konfiguration". Und definiere das Ziel der Dokumentation. Evtl. hilfreich: faq-o-matic.net » José: Version 3.1 faq-o-matic.net » Cindy.vbs 1.1: Windows-Dokumentation korrigiert Gruß, Nils

Moin, du bist dir sicher, dass das sinnvoll ist? Ein Administratorkonto sollte schon ein sehr starkes Kennwort haben ... Gruß, Nils

Moin, wobei man Sharepermissions ja eigentlich nicht ändern muss. Die setzt man auf "Jeder: Vollzugriff" und regelt den Rest über NTFS. Ist die sauberste Lösung. In dem Fall reicht es dann aus, dem betreffenden User die passenden NTFS-Rechte zu geben. Einen lokalen Logon braucht er dann nicht. Gruß, Nils

Moin, meine Empfehlung: Das eigene Benutzerkonto ohne lokale Adminrechte einbinden und für die Administration ein bzw. zwei separate Domänenkonten vorsehen (eins mit Dom-Admin-Rechten, ggf. eins mit lokalen Adminrechten). Dann kann man UAC als flexiblen Runas-Ersatz nutzen und hat gleichzeitig das Sicherheitsniveau bei normalen Arbeiten erhöht. Gruß, Nils

Moin, wenn du als normaler User angemeldet bist, fragt UAC nach Username und Kennwort, um das Programm auszuführen. Bist du schon Admin, dann fragt es nicht. Gruß, Nils

Moin, dann lies noch mal meinen ersten Satz von oben. Es geht per "runas" nicht. Glaub es mir einfach. Gruß, Nils

Moin, unter Windows 7 kannst du mit runas keine erhöhten Rechte mehr anfordern. Das musst du per UAC erledigen. Leg dir also eine Verknüpfung zu deiner MMC auf den Desktop und schalte dort "Immer als Administrator starten" ein. Gruß, Nils

Moin, kannst du bitte noch mal in Ruhe und strukturiert beschreiben, was du vorhast? Hier scheinen mir die Vorgänge und Begriffe doch arg durcheinander zu gehen. Falls du wirklich vorhast, einen DC zu klonen: Nein, lass die Finger davon. Aber jetzt bitte erst mal genau beschreiben, was du vorhast. Gruß, Nils

Moin, nein, das würde nicht gehen. Aber wenn du einen Virtualisierer zur Hand hast, kannst du den zweiten Server ja einfach als VM normal mit Windows 2008 R2 installieren. Integriere die Maschine in die bestehende Domäne, stufe sie zum DC hoch, kopiere alle Daten drauf, stufe den Alt-DC herunter und installiere ihn neu. Dann den ganzen Prozess nochmal, und am Ende die VM herunterstufen und löschen. Soweit in Kurzform. Im Detail entwickeln und testen musst du den Vorgang selbst. Gruß, Nils PS. Dass Windows 2008 R2 zwingend x64-Hardware braucht, ist dir bekannt?

Moin, wenn du derzeit angemeldet bist, kannst du dein Kennwort über folgende Kommandozeile im CMD-Fenster ändern: net user %username% * /domain Gruß, Nils

Moin, ist irgendwas an den Zugriffsrechten auf die OU gedreht worden? Sind Sonderzeichen im Namen? Gruß, Nils

Moin, meines Wissens geht BitLocker mit Hyper-V weder in der Parent Partition noch in den VMs. EDIT: Wie ich gerade sehe, war ich da auf dem Holzweg. Dann hatte ich wohl einen Hinweis aus den Windows-Server-8-Artikeln missverstanden. Dort wird die Bitlocker-Integration voraussichtlich deutlich verbessert. Möglich ist es aber anscheinend doch: http://blogs.technet.com/b/germanvirtualizationblog/archive/2008/12/01/windows-server-2008-hyper-v-und-bitlocker-verschl-sselung.aspx Ob es im konkreten Szenario Sinn ergibt, muss man natürlich prüfen: Ich weiß z.B. nicht, ob es überhaupt Server mit TPM gibt. Ohne wäre man dann zwingend bei einem Key auf USB-Stick, und das ist in einem RZ wohl kaum sinnvoll umsetzbar. Ließe man den Stick dort stecken, dann könnte man die Verschlüsselung auch gleich unterlassen. Auch die Pre-Boot-Authentisierung per PIN ist auf einem RZ-Server eher weniger sinnvoll ... Gruß, Nils

Moin, bezüglich der Datenbankgröße gibt es bei den kostenpflichtigen SQL-Editionen keine Einschränkungen (jedenfalls keine, die man erreicht, wenn man nicht Google oder Facebook ist). Beim RAM unterstüzt die Standard Edition bis zu 64 GB. Auf dem Link von Franz ist unten ein weiterer Link "Compare Editions", darüber findest du solche Details. Gruß, Nils

Moin, BitLocker und Hyper-V geht mit 2008 R2 noch nicht. EFS ist dafür nicht geeignet. Ob eine Verschlüsselung innerhalb der Datenbank möglich oder sinnvoll ist, kann ich nicht beurteilen (wahrscheinlich aber nicht). Wenn es wirklich sensible Daten sind und ihr dem Hoster nicht trauen könnt, dann gehören die Daten dort nicht hin. Gruß, Nils

Moin, die Öffentlichen Ordner sind kein "Auslaufmodell". Wenn nichts anderes dagegen spricht, kannst du das problemlos damit machen. Gruß, Nils ... ebensowenig wird Exchange auf eine SQL-Datenbank umgestellt. ;)

Moin, dein Gruppenkonzept ist falsch. Du solltest die Druckberechtigungen über Domänenlokale Gruppen in der Ressourcendomäne steuern, also in der Domäne, wo sich die Drucker befinden. Dann musst du nämlich nur die Gruppen der eigenen Domäne abfragen. In diese Gruppen steckst du dann die betreffenden Globalen Gruppen der anderen Domäne rein. faq-o-matic.net » Windows-Gruppen richtig nutzen Gruß, Nils

Moin, da derartige Auswertungen ziemlich sicher in den Bereich der Mitarbeiterüberwachung fallen, solltest du dich rechtlich absichern. Auskünfte dazu darf in Deutschland nur ein Rechtsanwalt erteilen. Technisch betrachtet: Wenn ihr keine zusätzlichen Logging-Systeme nutzt, ist diese Auswertung nur über die Security-Logs des TS bzw. der beteiligten DCs zu leisten. Gruß, Nils

Moin, ihr wollt kein Upgrade machen, sondern eure Datenbanken migrieren. Dafür gibt es mehrere Möglichkeiten, je nach Detailumstand: - Backup der DB auf dem Altsystem und Restore auf dem Neusystem - Abhängen der DB auf dem Altsystem und Einhängen auf dem Neusystem - Migration per Migrationsassistent vom Neusystem aus Gruß, Nils

Moin, du willst dir für deine Zertifizierung so einen Brummer kaufen? Reicht nicht ein PC mit ordentlich RAM und dann ein Virtualisierer drauf? Gruß, Nils