NilsK

Moin, meist ist DNS falsch konfiguriert, wie Dukel ja auch vermutet. [faq-o-matic.net » Was muss ich beim DNS für Active Directory beachten? (Reloaded)] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Darüber hinaus sollte man Exchange nicht auf einem DC installieren. Und natürlich ist ein einzelner DC zu wenig für eine Produktionsumgebung. Gruß, Nils

Moin, ich verstehe weder das Problem noch die Frage. Kannst du das bitte noch mal formulieren? Gruß, Nils

Moin, Aber gern. Allerdings ändert sich dadurch meine Antwort nicht. Wie ich schon sagte: Belege liegen mir nicht vor. Angesehen davon, verstehe ich deine Fragen syntaktisch nicht. Gewollt. Bei Betriebssystemen gibt es keine Lizenzmobilität. Microsoft will die Datacenter-Lizenz verkaufen. Standard ist eigentlich nur für Standalone-Hardware-Server gedacht. Hätte man die VOSE-Lizenzen aber ganz weggelassen, so hätten alle aufgeschrien. Daher hat man formell betrachtet die Standard-Lizenz sogar aufgewertet (auch als Kompensation für die wegfallende Enterprise-Lizenz). Naja, an der Stelle hat sich gegenüber 2008 eigentlich nichts geändert. Neu ist nur das Verbot des "Mischens" (wenn es denn existiert und kein Missverständnis ist). Und um ein offizielles Statement müsstest du Microsoft schon direkt bitten. Hier liest bestimmt keiner mit, der so was äußern dürfte ... Gruß, Nils

Moin, nein, aber ein hilfreicher Hinweis. Dukel kann ja nicht ahnen, dass du an besseren Vorschlägen nicht interessiert bist. Ein simples "Danke" hätte ihm sicher gereicht. Hier die Antwort auf deine Frage: Nein. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

Moin, zu den Grundlagen und Fundstellen kann ich leider nichts sagen, weil mir die auch nicht vorliegen (und selbst wenn, würde mir die "Denke" dazu abgehen). Ich habe wiedergegeben, was mir (und meinem Kunden) der Lizenzberater gesagt hat. Da es nach meinem Verständnis mit dem übereinstimmt, was Franz hier gepostet hat, habe ich es als Bestätigung verstanden und daher hier angefügt. Also wie immer nur Illustration meines Verständnisses, keine rechtlich relevanten Aussagen. Gruß, Nils

Moin, sorry, hat etwas gedauert ... mittlerweile hat die Lizenzberatung bei meinem Kunden stattgefunden. Der Berater machte einen sehr gut informierten Eindruck. Um es kurz zu machen: Ich sehe die Darstellung von Franz aus dem Post #63 als bestätigt an. In der Tat beruht das neue Lizenzmodell von Windows 2012 auf zwei (derzeit) unverrückbaren Grundsätzen: Die Lizenz wird immer der Hardware zugewiesen (das war in Wirklichkeit vorher auch schon so, ist aber oft von Kunden und Beratern ignoriert worden) Lizenzen für Windows 2012 dürfen auf derselben Hardware nicht mit älteren Lizenzen gemischt werden (das ist der eigentliche Knackpunkt) Das bedeutet: Wenn ich einen Host mit Windows 2012 installiere, um ihn mit Hyper-V zu betreiben, dann darf ich keine 2008-R2-Lizenzen (oder ältere) auf diesem Host zuweisen. Wenn ich dort also "alte" VMs mit 2008 R2 (oder älter) betreiben möchte, dann brauche ich für diese VMs auch 2012-Serverlizenzen und nutze für diese das Downgrade-Recht. Die Lizenzen, die ich vorher bereits für diese "alten" VMs hatte, sind damit überflüssig (die könnte ich verkaufen oder anderweitig nutzen - das Risiko, ob man diese Lizenzen "gebraucht" nutzen darf, liegt am Ende beim Käufer). Kritisch dabei auch: Einen Host-Cluster, in dem VMs dynamisch von einem auf einen anderen Host wechseln können, sieht Microsoft als Einheit an. Jeder einzelne Host muss so lizenziert sein, dass er alle Windows-Server-VMs betreiben darf. Habe ich drei Hosts und zehn Windows-VMs, so muss jeder Host alle zehn VMs lizenziert haben (also entweder je Host einmal Datacenter oder je Host fünfmal Standard - letzteres wäre aber nicht sinnvoll). Auch kritisch: Das ist kein Hyper-V-Thema, sondern ein Windows-2012-Thema, es betrifft also Kunden mit VMware, XenServer usw. genauso, sobald sie die erste VM mit Windows 2012 betreiben wollen (und VMotion bzw. XenMotion usw. nutzen, aber wer würde das nicht wollen). Es bleibt also auch bei meiner Einschätzung der erwartbaren Folgen 1 bis 3 aus meinem Post #64 weiter oben. Gruß, Nils ... und danke noch mal an dich, Franz - auch wenn der Inhalt niederschmetternd ist ...

Moin, du hast dich nach der Änderung der Gruppenmitgliedschaft neu angemeldet? Gruß, Nils

Moin, das hängt davon ab, wie viele Monitore die Karte verwalten kann. In deinem Fall offenbar nur zwei. Schöne Grüße, Nils

Moin, es sollte eine Gruppe "Hyper-V-Administratoren" geben. Die ist genau dafür gedacht. http://technet.microsoft.com/en-us/library/hh831410.aspx#BKMK_simpleauth Schöne Grüße, Nils

Moin, Hyper-V-VMs einer höheren Version kannst du nicht in einer niedrigeren Version importieren. Schöne Grüße, Nils

Moin, nein. Es gibt einen ganzen Markt für Provisioning-Tools, aber die liegen meist im Enterprise-Segment und können eine ganze Menge mehr, als hier gefordert ist. Öffne ein CMD-Fenster und gib ein "net user /domain". Öffne den Explorer, mach einen Rechtsklick auf eine Datei, bearbeite die Sicherheitseinstellungen. Und, und, und. Schöne Grüße, Nils

Moin, wenn der User nur die Gruppenmitgliedschaften ändern können und durch das Tool nicht "verleitet" werden soll, irgendwo zu gucken (wo er gucken kann, aber nicht gucken soll), dann ist die MMC in jeder Variation das falsche Werkzeug. In dem Fall sollte ein eigenes, kleines Tool gebaut werden, was natürlich Skript- oder Programmieraufwand erzeugt. Ich weise aber noch mal darauf hin, dass all das nur Versteckspiel ist. Wenn der User gucken will, dann kann er das, und zwar auch ohne RSAT. Schöne Grüße, Nils

Moin, prima, danke für die Rückmeldung! Schöne Grüße, Nils

Moin, aha. Wie ist denn das gesperrt? Sei dir bewusst, dass das Entfernen von Leserechten auf AD-Objekte die Funktion stören oder verhindern kann und dass du dich damit u.U. in einer nicht konfigurierten Konstellation befindest. Falls du hingegen die Leserechte gar nicht entzogen hast, ist das Browsen natürlich nicht gesperrt, sondern höchstens erschwert. Schöne Grüße, Nils

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