NilsK

Moin Bob,
 
also, ein letzter Kommentar noch - aber nur, weil du einen meiner Artikel zitierst:
 
Ja, man kann aus dem AD Daten exportieren. Ja, man kann Daten ins AD importieren. Nein, man kann mit einem Datenexport keine Migration in der Art machen, wie sie dir vorschwebt. Ist technisch nicht möglich, weil nicht vorgesehen.
 
Ja, ich habe dir das ganz oben schon gesagt. Und nein, ich habe es deshalb noch nicht gemacht, weil es technisch nicht geht.
Ich habe hingegen schon eine dreistellige Zahl an AD-Migrationen durchgeführt oder betreut. Es gibt Methoden dafür. Das ist die hier auch schon beschrieben worden.
 
Nein, du musst mir nicht alles glauben. Ja, ich gehe aufs Klo.
 
Und ja, ich habe jetzt echt genug von diesem Thread.
 
Gruß, Nils

Moin,
 
läuft auf dem antwortenden Rechner evtl. Bonjour? (Kommt mit der iTunes-Installation.)
Da gibt es ein Verhalten, das dem beschriebenen ähnelt, zumindest der Beschreibung nach.
 
https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy
 
Gruß, Nils

Moin,
 
aargh ... korrekt, das habe ich oben übersehen. Danke fürs Augenöffnen.
 
In 2008/R2 gab es noch keine PowerShell-Integration für Hyper-V. Da kann man sich höchstens hiermit behelfen:
http://pshyperv.codeplex.com/
 
Gruß, Nils

Moin,
 
da du netterweise alle wichtigen Kommentare schon selbst gegeben hast ... ;)
 
[Wie kann ich Active Directory von einem DC gewaltsam entfernen? | faq-o-matic.net]
http://www.faq-o-matic.net/2003/01/19/wie-kann-ich-active-directory-von-einem-dc-gewaltsam-entfernen/
 
Wäre einen Versuch wert.
 
Gruß, Nils

Moin,
 
hast du denn den Editor definiert?
 
[sqlcmd (Hilfsprogramm)]
https://msdn.microsoft.com/de-de/library/ms162773.aspx
 
Und warum so kompliziert? Nimm doch lieber das SQL Server Management Studio ... oder notfalls sowas wie Ofarim:
 
[Ofarim Free: SQL-Client | faq-o-matic.net]
http://www.faq-o-matic.net/2007/02/27/ofarim-free-sql-client/
 
Gruß, Nils

Moin,
 
PST-Dateien auf Netzlaufwerken sind nicht unterstützt. Erfahrungsgemäß kommt es dabei auch tatsächlich sehr schnell zu Problemen.
 
Sinnvoller wäre eine richtige Archivierung mit einem Werkzeug, das dafür gebaut wurde.
 
Gruß, Nils

Moin,
 
ja, das ist die Benutzerkontensteuerung/UAC.
 
[benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net]
http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/
 
Abhilfen:
Berechtigungen per Kommandozeile setzen in einem CMD-Fenster, das als Admin gestartet wurde, z.B. mit SetACL (separater Download) Berechtigungen mit dem "Mercedes" verwalten, SetACL Studio (kostenpflichtiges Tool) Berechtigungen mit einem Dateimanager bearbeiten, der mit UAC umgehen kann, z.B. Total Commander Übergeordnete Berechtigungen so setzen, dass eine andere Gruppe als "Administratoren" die Berechtigungen verwalten darf (nicht empfohlen) Berechtigungen mit dem vordefinierten "Administrator" bearbeiten (nicht empfohlen) UAC abschalten Gruß, Nils

Moin,
 
aus irgendeinem Grund ist die MSDN-Dokumentation da lückenhaft bzw. ungenau. Leider trifft man das beim AD immer mal wieder an.
 
Es könnte sein, dass das Feld als "comment" geführt wird - auch die Namensgebung ist im AD-Schema leider nicht immer einheitlich. (Ich meine, dass ich das auch schon mal rausgefunden habe, habe aber gerade keine Zeit, das zu verifizieren.)
https://msdn.microsoft.com/en-us/library/ms676199%28v=vs.85%29.aspx
 
Demnach kann das Feld bis zu 1024 Zeichen speichern (Range Upper).
 
Auch nach dieser Tabelle hier fasst das Feld 1024 Zeichen:
http://www.kouti.com/tables/userattributes.htm
 
Wozu brauchst du die Angabe? Was ist die Anforderung hinter deiner Frage?
 
Gruß, Nils

Moin,
 
Datenverluste im engeren Sinn sind nicht zu erwarten. "Lingering Objects" sind AD-Objekte, die vor mehr als 60 Tagen gelöscht wurden, von deren Löschung der entfernte DC aber nichts weiß. Man kann sich damit an dem entfernten DC dann anmelden, obwohl es sie ja eigentlich nicht mehr geben dürfte.
 
In deinem Szenario ist das Risiko in dem Sinne einschätzbar. Sobald du den entfernten DC dann entfernst, ist das Problem auch weg.
Der Hinweis mit den vorhandenen Konten bezieht sich darauf, dass mit einem neuen DC dann ja der aktuelle Datenbestand in die Niederlassung kommt; Änderungen auf dem entfernten DC sind dann verloren. Und falls es da eben noch Konten gab, die im Zentral-AD nicht mehr vorhanden sind, können sich die natürlich nicht mehr anmelden.
 
Gruß, Nils

Moin,
 
eine herkömmliche GP-Einstellung gibt es dafür nicht, aber per GPP solltest du das lösen können.
 
Gruß, Nils

Moin,
 
was steht denn in $choice_ou tatsächlich drin?
 
EDIT: Ich habe mal mit dem Variablen-Monitor von ISESteroids nachgesehen. Demnach ist $choice_ou ein Objekt mit einer Eigenschaft namens "DistinguishedName". Du musst also diese Eigenschaft abfragen, dann geht es:
Get-AdUser -Filter * -SearchBase $choice_ou.DistinguishedName Das ist die Tücke: PowerShell arbeitet mit Objekten, nicht mit Strings.
 
Gruß, Nils

Moin,
 
das könnte so ähnlich sein wie hier, schau doch mal, ob das weiterhilft:
 
http://www.mcseboard.de/topic/202012-backup-directory-im-sql-cluster-%C3%A4ndern/?hl=%2Bsql+%2Bcluster&do=findComment&comment=1257882
 
Gruß, Nils

Moin,
 
das, was dein Skript macht, bekommst du ja auch mit GPP hin. Dadurch löst du das Problem zwar nicht, erreichst das eigentliche Ziel aber durchaus "besser".
 
Gruß, Nils

Moin,
 
wie gesagt, ich habe keinen SQL Server bei der Hand. Aber auffindbar sollte das schon sein. Anders als ich es in Erinnerung hatte, wohl doch nicht in den einzelnen Steps, sondern für den Plan als ganzen.
 
[Maintenance Plan (Reporting and Logging Page)]
https://msdn.microsoft.com/en-us/library/ms180370%28v=sql.110%29.aspx
 
Gruß, Nils

Moin,
 
ich verstehe das immer noch nicht.
 
Normalerweise geht es so (wenn der Host/PC nur eine physische Netzwerkkarte hat):
Du richtest einen virtuellen Switch vom Typ "extern" an, den du auf die physische Netzwerkkarte des Hosts (also deines PCs) verbindest Du aktivierst dabei das Häkchen "Gemeinsame Verwendung ... zulassen"Dadurch ist der vSwitch sowohl für die VMs als auch für den Host (= den PC) nutzbar, um über das LAN zu kommunizieren Du richtest deine VMs so ein, dass deren Netzwerkkarte mit dem virtuellen Switch verbunden ist Auf dem Host (= PC) siehst du in der Systemsteuerung nun eine neue virtuelle Netzwerkkarte. Hier konfigurierst du die IP-Adresse so, dass die Kommunikation möglich ist Die physische Netzwerkkarte in derselben Übersicht lässt du unangetastet. Dort ist nur noch ein Häkchen bei "Hyper-V erweiterbarer virtueller Switch" gesetzt - nichts ändern! Innerhalb der VMs konfigurierst du die IP-Adressen dann so, dass sie kommunizieren können Gruß, Nils

Moin,
 
also, technisch betrachtet ist das natürlich Blödsinn. Man macht einen Computer nicht zum Domänenadmin.
 
Das ist das Problem des Supports: Deren Aufgabe ist nicht Forensik, sondern das Herstellen von Funktionsfähigkeit.
 
Probier doch mal, ob es ausreicht, das Computerkonto zum Sicherungs-Operator auf dem Zielserver zu machen.
 
Gruß, Nils

Moin,
 
versuch es mal. Ich würde den vNIC mit einem anderen vSwitch verbinden, Konfig speichern, dann den umbenannten vSwitch zuweisen, speichern. Ich finde, es sollte dann mit der LM funktionieren (wobei ich den konkreten Fall noch nicht hatte).
 
Gruß, Nils

Moin,
 
wenn in dem Fall die Logfiles vollaufen, hast du zwei Möglichkeiten
während des Vorgangs keine (bleibenden) Logfiles erzeugen während des Vorgangs aggressiv die Logfiles in kurzer Frequenz sichern In Fall 2 brauchst du den Platz dann eben woanders. Und du verzögerst den Vorgang - ob das spürbar ist, kann ich aus der Ferne nicht beurteilen.
In Fall 1 würde ich die Datenbank umkonfigurieren, ein Full Backup machen und dann loslegen. Nach Abschluss des Vorgangs die Datenbank wieder auf "Full" setzen und sofort ein Full Backup, dann die Log Backups wieder einrichten.
 
Gruß, Nils

Moin,
 
der Haken ist sogar genau für dieses Szenario gedacht. Der DC versucht dadurch, die Subdomäne aus dem Forest zu löschen.
 
Du kannst den Haken auch weglassen, dann ändert sich auf Forest-Ebene nichts. Dann musst du eben die Subdomäne nachträglich dort rauslöschen, aber das wird weniger Spaß machen.
 
Und wenn du ganz sicher gehen willst, nimmst du dir eben zwei VMs und stellst das Spielchen nach ...
 
Gruß, Nils

Moin,
 
generell sollte man den Aufbau von Multi-Domänen-Strukturen vermeiden. Die Nachteile solcher Aufbauten sind fast immer größer als der Nutzen.
 
[Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net]
http://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/
 
Um einen Multi-Domänen-Forest aus der bestehenden Umgebung zu bauen, müsstest du alle Außenstellen-Domänen auflösen und als Subdomains neu installieren. Riesiger Aufwand, wenig Nutzen. Eine Absicherung gegenüber einer Einzeldomäne hättest du damit auch nicht, denn die Sicherheitsgrenze ist der Forest, nicht die Domäne.
 
Über diese allgemeine Anmerkung hinaus solltest du dir aber einen kundigen Berater suchen und die Entscheider des Unternehmens dazuholen. So ein Design macht man nicht "mal eben".
 
Gruß, Nils

Moin,
 
von einer VM kommst du nie auf Ressourcen des Hosts. Hyper-V ist anders als VMware Workstation.
 
Du müsstest also die Host-Laufwerke freigeben und übers Netzwerk ansprechen.
 
Gruß, Nils