NilsK

Moin, grundsätzlich könntest du mit ADMT Gruppen aus DOM_A nach DOM_B übertragen und dabei die Funktion SID History nutzen. Dann sollten die bestehenden Berechtigungen für die migrierten Gruppen erkannt werden. Für diese Migration brauchst du eine Vertrauensbeziehung zwischen den Domänen. Gruß, Nils

Moin, nimm doch die Bordmittel: Windows Server Backup. Gruß, Nils

Moin, wenn die Server "hängen", wäre es wichtig, den Grund herauszufinden. Dann kann man das Monitoring viel aussagefähiger gestalten. Gruß, Nils

Moin, faq-o-matic.net » Ein AD-Attribut zu einem Logon-Namen herausfinden Gruß, Nils

Moin, um sicher zu gehen, sollte man alle Daten überschreiben. Das ginge z.B. so: faq-o-matic.net » Dateien sicher löschen mit cipher.exe Gruß, Nils

Moin, die Symptomatik, die du beschreibst, deutet jedenfalls darauf hin, dass das Setup-Programm nicht richtig mit dem SQL Server kommunizieren kann, denn offenbar gelingt es ja nicht, die Konfigurationsdaten zu bestimmen. Gibt es evtl. irgendwo ein Sprachversionsproblem? Sowas hatte ich mal in der Betaphase eines anderen SC-Produkts. UAC testweise mal ganz abgeschaltet? Gruß, Nils

Moin, es löst dein Problem nicht (zu dem ich leider momentan keinen zielführenden Hinweis habe), erspart dir aber u.U. gravierende Folgeprobleme: "Domain Admins" ist die falsche Gruppe für nahezu jedes Dienstkonto. Insbesondere SQL Server braucht weder lokale Adminrechte noch Domänen-Admin-Rechte. Wozu genau sollte der SQL Server denn auch das AD vollständig manipulieren oder auf jedem einzelnen Rechner im Netzwerk administrative Rechte haben? Ja, ich denke, genau das wird der Grund sein. Gruß, Nils

Moin, leider lässt sich aus deiner Beschreibung weder die Konfiguration noch das Problem erkennen. Bitte noch mal ausführlich und in Ruhe beschreiben. Gruß, Nils

Moin, machen wir es kurz: Mit 1000 EUR und "eigentlich keiner Zeit" ist das Ziel nicht zu erreichen. Stellt sicher, dass alle wichtigen Daten und Applikationen gesichert sind und dass im Notfall zügig Ersatzhardware da ist. Mehr kann man in dem von dir gesteckten Rahmen nicht tun. Gruß, Nils

Moin, ich meine das Problem schon mal anderswo gesehen zu haben. Wenn es genauso ist, ist gar nicht die IE9 in anderer Sprachversion installiert worden, sondern es gab nur ein Problem beim Kopieren der aktualisierten ADML-Datei (Sprachdatei für die GPO-Einstellungen im GPO-Editor). Effekt ist dann, dass der GPO-Editor die (veraltete) deutsche Sprachdatei nicht lädt und daher die GPO-Einstellungen des betreffenden Zweigs in der Originalsprache (also Englisch) anzeigt. Gruß, Nils

Moin, aber er hat das Problem doch schon gelöst ... Gruß, Nils

Moin, für mich sieht das nach "Token Bloat" aus. 300 Gruppenmitgliedschaften verdoppelt macht schon 600 - und zusätzlich zur Maximalgröße des Tokens selbst kann es noch Einschränkungen bei der Übermittlung des Tokens geben (Details dazu habe ich gerade nicht mehr im Kopf, sind aber recherchierbar). Letztere könnte man übergangsweise beheben. Um das Problem tatsächlich zu lösen, kommst du um die Bereinigung der SID History nicht herum. Gruß, Nils

Moin, nein, aber das wäre notfalls auch nachträglich über das Exchange-GUI eine Sache von Minuten. Gruß, Nils

Moin, heute morgen habe ich die Version 3.2 des AD-Dokumentationstools José freigegeben. Die Betaphase dafür ist damit beendet. faq-o-matic.net » AD-Dokumentation: José 3.2 ist da Aufgrund der Übersichtlichkeit bitte ich aber darum, dass Kommentare, Fehlerbeschreibungen und Änderungswünsche trotzdem in diesem landen. Danke & Gruß, Nils

Moin, heute morgen habe ich die Version 3.2 des AD-Dokumentationstools José freigegeben. Die Betaphase dafür ist damit beendet. faq-o-matic.net » AD-Dokumentation: José 3.2 ist da Aufgrund der Übersichtlichkeit bitte ich aber darum, dass Kommentare, Fehlerbeschreibungen und Änderungswünsche trotzdem in dem Beta-Thread landen: https://www.mcseboard.de/active-directory-forum-79/jose-3-0-betaphase-160129.html Danke & Gruß, Nils

Moin, Kontakte kannst du durchaus per csvde importieren. Dafür dürfte dein Export sogar geeignet sein. Beim Import brauchst du die Option -c, um den LDAP-Pfad anzupassen. Die doppelten Schrägstriche sind normal, weil im DN der Objekte ein Komma steht, das maskiert werden muss (das Komma ist ja sonst LDAP-Trennzeichen) und der Schrägstrich im CSV-Format verdoppelt wird. Ach, und: Natürlich willst du das vorher in einer abgeschotteten (!) Testumgebung testen. Gruß, Nils

Moin, die Antwort heißt: UAC. faq-o-matic.net » Benutzerkontensteuerung (UAC) richtig einsetzen Eine Alternative zu deinem Verfahren wäre, den Share über einen Geplanten Task einzurichten, der bei der Anmeldung abläuft und zuerst ein paar Sekunden wartet (z.B. per "ping -n [Anzahl der Sekunden] 127.0.0.1 > nul"). Gruß, Nils

Moin, mach was du willst - aber geh nicht davon aus, dass du korrekt lizenziert bist. Im Zweifel hast du keine Lizenz, dann kannst du auch gleich direkt raubkopieren. Nur meine 0,02 EUR, Nils

Moin, das lese ich aber anders: Von produktiver Nutzung steht da nichts. Für mich sieht es so aus, als würdest du da gegen Lizenzbestimmungen verstoßen. Gruß, Nils

Moin, was mir bekannt ist, lautet bislang völlig einstimmig: Die "internal-use"-Lizenzen für Partner sind für den produktiven Einsatz beim Partner selbst bestimmt und stellen eine Gegenleistung für die Partnergebühr und den vertrieblichen Einsatz dar. Man darf sie aber nicht auf Rechnern einsetzen, die Kunden nutzen (z.B. für Training) und natürlich auch nicht verkaufen. Ebenso darf man darauf kein Hosting für Kunden machen. Auf dieser Seite unter "Leistungen FAQ" ist das näher erläutert, und daraus geht m.E. deutlich hervor, dass man die Lizenzen sehr wohl intern produktiv einsetzen darf. https://partner.microsoft.com/40091047 Näheres dürfte aus dem Partnervertrag hervorgehen, den ich allerdings nicht zur Hand habe und von dem ich mir nicht sicher bin, ob man ihn ohne Weiteres posten darf. Gruß, Nils

Moin, aha. Und das baust du dann wie? Gruß, Nils

Moin, die Lizenzen aus den "Studentenprogrammen" von Microsoft berechtigen üblicherweise nicht zum produktiven Einsatz (auch nicht für Privat-Netzwerke)! In den Programmen, die mir bekannt sind, sind sie nur für die Softwareentwicklung vorgesehen. Du solltest das also noch mal prüfen. Die Hyper-V-Rolle kombiniert man mit nichts anderem. Und 8 GB RAM sind unsinnig wenig. Da die Parent Partition auch 2-4 GB braucht, bliebe dir kaum was für die VMs. SSD kann man machen, halte ich aber in deinem Szenario für völlig unnötig. Gruß, Nils

Moin, besonders nach einer ADMT-Migration kann es zu Anmelde- und Zugriffsproblemen kommen, wenn die migrierten Objekte schon vor der Migration in vielen Gruppen Mitglied waren. Die ADMT-Migration beruht üblicherweise auf der SID History, d.h. die alten SIDs werden mit den Objekten migriert, und zusätzlich erhalten sie in der neuen Domäne neue SIDs. Überträgt man Gruppen mit, so erhalten diese natürlich auch neue SIDs, sodass für jede Gruppenmitgliedschaft nicht mehr eine, sondern zwei SIDs im Access Token eines Users stehen, der sich anmeldet. Das führt dann schnell zum "Token Bloat", d.h. das Token ist zu groß und enthält nicht mehr alle Gruppenmitgliedschaften. Schon im Normalfall kann ein Objekt nur in ca. 1015 Gruppen gleichzeitig Mitglied sein. Durch das Dual-SID-Prinzip verringert sich das je nach Zusammensetzung der Gruppenstruktur auf etwa 500 Gruppen. Abhilfe: Bereinigung der Gruppen. Dafür ist es notwendig, in den Berechtigungslisten der Ressourcen die Berechtigungen, die auf die "alten" Gruppen lauten, durch solche für die (identischen) "neuen" Gruppen zu ersetzen. Das kann aufwändig sein. Je nachdem, wie die Migration insgesamt abgelaufen ist, gibt es aber vielleicht bereits "Dual-ACL" in den Listen - ADMT umfasst für die Migration etwa von Dateiservern die Option, die ACLs in den Berechtigungslisten um Einträge für die migrierten Gruppen zu ergänzen (es stehen also sowohl die alte als auch die neue Gruppe drin). In so einem Fall braucht man SID History dann eigentlich nicht für den Zugriff. Nach dem Anpassen der ACLs kann man dann die SID History von den Gruppen (und ggf. auch den Usern) entfernen, dafür gibt es Beispielskripte bei Microsoft. Eine weitergehende (und bessere) Option ist, die Gruppen- und Berechftigungsstruktur neu aufzubauen und die Altobjekte und Alteinträge zu entfernen, aber das erzeugt üblicherweise Aufwand, der eher in Wochen zu rechnen ist. Gruß, Nils

Moin, das DSCT hat ein Tombstone Recovery integriert. Mit Snapshots bzw. der darauf aufsetzenden Read-only-Kopie des AD hat das an der Stelle nichts zu tun, die kommen erst später ins Spiel. Lies mal diesen Artikel, dort vor allem den Abschnitt ganz unten ab "AD DS Daten aus einer Datensicherung wiederherstellen". Dort siehst du, wie du das Ganze ohne Snapshots auf Basis einer regulären Datensicherung hinbekommst. faq-o-matic.net » Windows Server 2008: Snapshots des Active Directory Und tu dir einen Gefallen und lies dir mein Tutorial durch, das ich oben verlinkt habe. Gruß, Nils

Moin, die Snapshots haben mit gelöschten Benutzern nichts zu tun! Um das zu erreichen, brauchst du ein Tombstone Recovery oder den Papierkorb, aber keine Snapshots. Snapshots sind interessant, um Attributwerte zurückzusetzen. Für diesen Zweck reichen aber auch Kopien der AD-Datenbank, z.B. aus einem regulären Backup. Snapshots automatisch zu erzeugen, ist dafür nicht nötig. Siehe auch: faq-o-matic.net » Video-Tutorial: Active Directory Object Recovery Gruß, Nils