NilsK

Moin, die Infrastruktur dafür ist seit Windows 2000 im Betriebssystem eingebaut. Du musst dem User (besser: einer Gruppe) das Recht geben, die Mitglieder der betreffenden Gruppe zu bearbeiten. Ein dediziertes Tool dafür gibt es nicht, das wäre aber keine ernsthafte Hürde. Spannender ist die Frage, was du damit meinst: Standardmäßig kann jeder User fast alles im AD lesen und also auch "browsen". Was ist da also die genaue Anforderung? Schöne Grüße, Nils

Moin, warum so umständlich? Seit Windows 2000 gibt es dafür csvde.exe. [faq-o-matic.net » csvde zum Import und Export von AD-Daten nutzen] http://www.faq-o-matic.net/2003/10/25/csvde-zum-import-und-export-von-ad-daten-nutzen/ [faq-o-matic.net » Carlos: Konfigurationsmaske für csvde.exe] http://www.faq-o-matic.net/2003/07/25/carlos-konfigurationsmaske-fuer-csvde-exe/ Und zur Weiterbearbeitung in Excel eignet sich auch Carmen sehr gut, da kann man die Abfragen in SQL formulieren. [faq-o-matic.net » Carmen: Mit SQL das AD abfragen] http://www.faq-o-matic.net/2004/10/20/carmen-mit-sql-das-ad-abfragen/ Gute Exports kann man auch mit ADFind erzeugen, da wiederum mit sehr leistungsfähigen Abfragen. [faq-o-matic.net » Active-Directory-Massenoperationen mit AdMod und AdFind] http://www.faq-o-matic.net/2006/11/29/active-directory-massenoperationen-mit-admod-und-adfind/ Schöne Grüße, Nils

Moin, die Anzahl der Gruppenmitgliedschaften ist nicht willkürlich beschränkt worden, sondern die Folge technischer Design-Entscheidungen. Das entsprechende Feld im Token nimmt einfach nicht mehr Werte auf. Anpassungen sind grundsätzlich möglich und wurden auch vorgenommen (z.B. in Windows Server 2012), aber gehen immer zu Lasten der Kompatibilität. Da gerade in einer Umgebung mit vielen differenzierten Berechtigungen durchaus schnell sehr viele Gruppen zusammenkommen, kann nur ein grundsätzlicher Design-Entwuf zur Problemlösung beitragen. Dazu kann gehören, die Berechtigungs- und Gruppensysteme zentral neu zu entwerfen, um die Zahl der Variationen einzugrenzen. Ein anderer Ansatz ist, mit verschiedenen Ressourcen-Domänen zu arbeiten, da die Domänenlokalen Gruppen ja nur innerhalb der jeweiligen Domäne existieren. [faq-o-matic.net » Windows-Gruppen richtig nutzen] http://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Ebenfalls zu prüfen wäre, ob die neue "Dynamic Access Control" in Windows Server 2012 das Problem einzudämmen hilft. Das wäre dann das Prinzip "Es wäre hilfreich wenn man beim Zugriff auf ein Verzeichnis einfach eine Abfrage am DC machen könnte." [faq-o-matic.net » WINone: Folien und Nachträge zu Windows Server 8] http://www.faq-o-matic.net/2012/02/06/winone-folien-und-nachtrge-zu-windows-server-8/ (dort ist noch der Ausdruck "Flexible Access") Auf jeden Fall wird man das ohne hohen Design-Aufwand nicht lösen können. Schöne Grüße, Nils

Moin, die einzige "immer taugliche" Lösung ist eine Softwareverteilung. Was eine Applikation bei einem Update tut, kann sehr unterschiedlich sein. Vieles davon läuft darauf hinaus, ausführbare Dateien an geschützten Pfaden auszutauschen, und dafür sind Adminrechte nötig. Vielleicht kann man im Einzelfall dem Anwender Ändern-Rechte auf bestimmte Programmdateien geben, aber das sind dann letztlich Basteleien im Einzelfall, das Risiko liegt zwischen beträchtlich und sehr hoch. Eine eigene Update-Infrastruktur, die ohne Benutzer- bzw. Admin-Eingriff arbeitet, haben nur wenige Applikationen. Schöne Grüße, Nils

Moin, das haben die noch nie gemacht! Schöne Grüße, Nils PS. :P

Moin, hm, okay, dann ist es wohl recht pfiffig implementiert. OK, dann verdient es doch einen näheren Blick. Ich hatte hier Erfahrungen mit sehr einfachen Implementierungen auf diesen Fall übertragen. Schöne Grüße, Nils

Moin, auch hübsch gedacht, aber unter "harten" Sicherheitsbedingungen untauglich. Wenn ein Prozess mit administrativen Rechten arbeitet, dann kann er diese an Kindprozesse weitergeben. Der User braucht also meist nur z.B. einen "Speichern"- oder "Öffnen"-Dialog, startet von dort einen anderen Prozess und kann sich selbst Adminrechte geben. Schöne Grüße, Nils

Moin, netter Ansatz, aber prinzipiell zum Scheitern verurteilt, sobald wir über lokale Administratoren reden. Schöne Grüße, Nils

Moin, meines Wissens lassen sich die RRAS-Funktionen nur auf einem Server-Windows einrichten. Jedenfalls sagt die MMC das, wenn man sich auf einen Client verbindet, wo man den Dienst aktiviert hat. Schöne Grüße, Nils

Moin, hat niemand bezweifelt. Ich wies ja auch darauf hin, dass ich das Skript halt fertig habe. Das "Argument" wird oft gebracht, zieht aber nicht. Der längere Code macht schließlich auch was anderes. (Genau betrachtet ist der VBS-Code sogar ziemlich umständlich, aber es gibt gerade keinen Anlass, ihn neu zu machen.) Immer gern. Schöne Grüße, Nils

Moin, Windows 8 hat keine Routing-Dienste. Schöne Grüße, Nils

Moin, eine inkrementelle Sicherung läuft in vielen Fällen viel schneller ab als eine differenzielle, denn es müssen ja nur die Änderungen zum letzten Inkrement gesichert werden und nicht die Änderungen zur letzten Vollsicherung. Schöne Grüße, Nils

Moin, korrigiert mich, wenn ich falsch liege, aber ich meine mich zu erinnern, dass Freigaben nur von lokalen Administratoren oder Server-Operatoren geändert werden können. Zudem könnte es erforderlich sein, dem User, der den Task ausführt, ausdrückliche Rechte auf die cmd.exe zu geben. Schöne Grüße, Nils

Moin, man beachte, dass wir auf die Koexistenz mit Exchange 2013 dann trotzdem warten müssen, weil es dafür noch ein 2013-Update braucht. Und danach fällt Microsoft sicher ein, dass man erst noch ein SP3.1 veröffentlichen muss ... Schöne Grüße, Nils

Moin, vor allem sollte man das Pferd von vorn aufzäumen, nicht von hinten. Du musst also als erstes die Anforderungen klären: Welche Schadensszenarien sind zu betrachten, und welche Wiederherstellung muss dann möglich sein? Wenn du beispielsweise sagst "Vollsicherung am Monatsanfang ist klar", mag das für euer Unternehmen zutreffen - die meisten Unternehmen, die ich betreue, führen für einen Großteil ihrer Applikationen aber tägliche Vollsicherungen aus. So "klar" ist das dann eben nicht. Schöne Grüße, Nils

Moin, die einzige sinnvolle Lösung dafür ist eine automatisierte Softwareverteilung. Schöne Grüße, Nils

Moin, nein, kann bei dem Code auch nicht. Der Code hinterlegt die Daten in der Variablen strLDAP und macht dann nichts weiter damit. Füge mal folgende zweite Zeile ein: WScript.Echo strLDAP Oder ersetze, wie im Artikel angegeben, die erste Zeile durch den unteren Codeblock. Kann auch nicht, siehe oben. VBS löst zudem die CMD-Variablen nicht auf. Klar, es gibt im AD auch keine Felder, die so heißen. dsget nutzt eigene Feldbezeichnungen, warum auch immer dessen Programmierer das für eine gute Idee hielt. Ich werde das Skript gleich mal als Download auf die Seite setzen. Schöne Grüße, Nils

Moin, dann findet heraus, wie man diese Tools ohne Adminrechte verwendet oder welche Alternativen es gibt, die keine Adminrechte brauchen. Schöne Grüße, Nils

Moin, ich würde das mit einem kleinen VBScript machen (allerdings hauptsächlich deshalb, weil ich es ohnehin dahabe), sonst wäre auch PowerShell ein Kandidat. [faq-o-matic.net » Ein AD-Attribut zu einem Logon-Namen herausfinden] http://www.faq-o-matic.net/2004/07/28/ein-ad-attribut-zu-einem-logon-namen-herausfinden/ Schöne Grüße, Nils

Moin, damit meinst du jetzt: VM herunterfahren, um die Option "CPU-Kompatibilität" einzuschalten, oder? Schöne Grüße, Nils

Moin, konfigurieren kannst du da auch nichts. Windows Backup und Windows Server Backup machen prinzipbedingt immer inkrementelle Backups, weil sie auf Blockbasis arbeiten und ab der zweiten Sicherung nur die geänderten Blöcke sichern. Das gilt allerdings nicht, wenn das Sicherungsziel eine Freigabe ist, dann wird immer voll gesichert. Schöne Grüße, Nils

Moin, wo hast du was angefragt? Snapshots sind für keine Exchange-Version supportet. Und für Exchange 2003 ist der Support in Virtualisierung ohnehin stark eingeschränkt. Für mich klingt das nicht nach einer professionellen Lösung. Schöne Grüße, Nils

Moin, gut. Und, hast du mit Astaro schon gesprochen? Ja, prinzipiell geht das, wenn wir von einer physischen NIC (also einem vSwitch) sprechen. Schöne Grüße, Nils

Moin, was meinst du mit "untergeordneten Domänencontroller"? Ist der nun in derselben Domäne oder nicht? Schöne Grüße, Nils

Moin, kann gut sein, dass es geht, evtl. mit eingeschalteter CPU-Kompatibilität. [Prozessoren und deren Herausforderungen mit Hyper-V | Server TalkServer Talk] http://www.server-talk.eu/2010/08/17/prozessoren-und-deren-herausforderungen-mit-hyper-v/ Von Intel nach AMD oder andersrum geht nicht. Schöne Grüße, Nils