NilsK

Moin, meines Wissens gibt es dafür keinen lizenzrechtlich sauberen Weg. Daher wäre die korrekteste Variante, wenn ihr eine Art Installationsanleitung oder automatische Installation erzeugt, mit der eure Partner sich mit eigenen Lizenzen oder Eval-Lizenzen die Umgebung selbst bauen. Sogar Microsoft selbst hatte vor einigen Jahren erhebliche Probleme, seine Contoso-VMs für Partner intern richtig lizenziert zu bekommen - und dabei sind die ja der Lizenzgeber ... Gruß, Nils

Moin, brauch ich nicht, gibt's schon, wenn auch nicht von mir: [LAPS – lokales Admin-Passwort endlich sicher | faq-o-matic.net] http://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/ Gruß, Nils

Moin, das ist genau das, was ich mit einem organisatorischen Problem meine. Das kann man vielleicht technisch ein wenig eingrenzen, aber nicht lösen. Wenn der genannte Admin die Kennwörter mitnehmen will, kann er das tun, sobald er einmal Kenntnis von ihnen erhält. Egal, welche technischen Finessen die Datenbank als ganze schützen. Gruß, Nils

Moin, nslookup ist nicht geeignet, die Namensauflösung durch den Client zu überprüfen. Es arbeitet anders als der normale Resolver. [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] http://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Dass der Abbruch der Anmeldung mit DNS zusammenhängt, ist ausgesprochen unwahrscheinlich. In dem Moment, wo die Anmeldung beginnt, ist die Namensauflösung ja schon abgeschlossen. Gruß, Nils

Moin, ich verstehe die Frage nicht. Entweder gibt es keine technische Lösung, weil man organisatorische Probleme nur organisatorisch lösen kann. Oder die Antwort lautet "Zugriffsberechtigungen auf die Datei". Oder meinst du was anderes? Gruß, Nils

Moin, das hängt vom Einsatzgebiet und den Anforderungen ab. In dem hier diskutierten Szenario könnte es ausreichen, eine Vorgabe zum manuellen Setzen eines komplexen Kennworts zu machen. LAPS kann durchaus eine Lösung sein, aber sie passt nur, wenn es sehr strikte Prozesse gibt. Aufgrund der Architektur ist LAPS für typische mittelständische Unternehmen i.d.R. nicht geeignet. Man könnte auch etwas LAPS-Ähnliches selbst bauen, z.B. einen Task, der lokal ein Kennwort generiert, es setzt und an einen geschützten Ort schreibt. Eine einzelne Datei auf einem Server oder eine einzelne Datenbank kann man meist leichter absichern als Attribute in einem AD. Gruß, Nils

Moin, das ist ja schon beantwortet worden: Ja, sie kann Probleme bereiten. Das ist im Grundsatz zwar richtig, aber genauso bekannt ist der SID der Gruppe Administratoren. Ein engagierter Angreifer wird von dort aus weiterkommen. Abgesehen davon, wird der SID (genauer: der RID) nicht zufällig generiert, sondern einfach weitergezählt. Da es auf den meisten Servern nur sehr wenige lokale Accounts gibt, ist der neu definierte Admin also schnell gefunden. Hier und da wirst du den Account also vermutlich abschalten können (ist ja bei Clients auch so), an anderen Stellen wirst du es wegen des Funktionsrisikos aber nicht tun wollen. Und gewonnen ist damit wenig. Komplexe Kennwörter sind ziemlich eindeutig besser. LAPS halte ich allerdings nicht für eine schöne Lösung. Man muss dabei sehr viel zusätzlich gewährleisten, damit es funktioniert. Kleine Sorgfaltslücken können dann ein großes Sicherheitsproblem erzeugen. Gruß, Nils

Moin, wenn du das professionell machen willst, solltest du dir 8MAN anschauen. Der kann Mehrfachberechtigungen pro Ressource direkt anzeigen, auch Verschachtelungen werden dabei berücksichtigt. Wenn es "zu Fuß" sein soll, wirst du selbst eine Logik zum Vergleichen finden müssen. Wenn die Gruppennamen einheitlich auf -R oder -RW lauten, könntest du beim Auftreten von "-R" prüfen, ob derselbe String mit "-RW" auch in der Menge der Gruppenmitgliedschaften auftritt. Das hängt dann vor allem von der Namenslogik ab und wird immer auf der Ebene der Gruppen bleiben - die tatsächlichen Berechtigungen berührst du damit nicht. Das wäre dann eben was für 8MAN ... Gruß, Nils

Moin, ein gespiegeltes Storage bedeutet noch lange kein unterbrechungsfreies Umschalten. Das erwarten zwar viele Kunden, aber nur wenige Storage-Systeme können das wirklich leisten. Der Nutzen der Spiegelung besteht zunächst meist darin, dass keine Daten verloren gehen. Beim Ausfall des Primärsystems fällt dann aber das Gesamtsystem aus. Man kann es dann manuell auf das Sekundärsystem umstellen und neu starten. Die Daten sind alle da, aber eben nicht unterbrechungsfrei. Selbst bei höherwertigen Mimiken, die ein "transparentes Failover" unterstützen, kann es zu längeren Umschaltzeiten kommen, die die Applikationen zunächst zum Absturz bringen. Und auch bei solchen Speichersystemen gibt es Situationen, in denen das Failover gar nicht funktioniert - das ist sogar nicht einmal unwahrscheinlich. Das Stichwort ist hier "Split Brain", was i.d.R. eine dritte Instanz erfordert. Ist diese nicht vorhanden oder nicht erreichbar, dann gibt es kein Failover. Gruß, Nils

Moin, ich spüre eine gewisse Einigkeit. :D Gruß, Nils

Moin, doch, hattest du. Jetzt wird hier aber iSCSI diskutiert, das ist ja kein NAS. iSCSI halte ich in dem Szenario auch für eine schlechte Idee. Blockstorage wird das nicht mögen. Ein dateibasiertes Protokoll ist da sinnvoller. Gruß, Nils

Moin, das hat auch alles hier und da seine Berechtigung. Aber da es nun mal auf das Recovery ankommt, muss man schon genau hinsehen - 15 TB sind ja kein Pappenstiel. Und wer holt die Daten dann im Notfall mit einem Satz USB-Platten beim Dienstleister wieder ab? Wie lang dauert das? Wie lang dauert es dann, bis man die wieder eingespielt hat? Daher bin ich bei sowas immer sehr skeptisch. Gruß, Nils

Moin, das meine ich nicht mit "aus einer Hand" - das Betriebssystem und die Storage-Funktionen supportet dir ein Server-Hersteller nicht. Ein (ernst zu nehmender) NAS-Hersteller sehr wohl. 15 TB übers WAN? Na, herzlichen Glückwunsch. Gruß, Nils

Moin, naja, 15 TB netto sind ja auch groß. Der Vorteil einer (professionellen) Appliance: Support aus einer Hand. Bei einem BTO-Server ist man für das Gesamtkonstrukt selbst verantwortlich. Gruß, Nils

Moin, beim Ablauf werden die Konten auch nicht deaktiviert. Sie können sich nur nicht mehr anmelden. Hat der Rechner, von dem aus du die Anmeldung versuchst, Kontakt zum DC? Bei Cached Credentials würde der Ablauf, glaube ich, nicht greifen. Gruß, Nils

Moin, technisch betrachtet, kannst du auch ein Domänenkonto mit deinem Microsoft-Konto verbinden. Das muss natürlich im Unternehmen zulässig sein, also bitte nicht einfach so. Wenn du zwei getrennte Konten dafür willst, ist die Reihenfolge der Einrichtung egal. Bedenke aber, dass der Rechner auch bei Anmeldung mit einem lokalen Konto selbst Domänenmitglied ist und durch GPOs gesteuert wird. Und bedenke, dass eine solche Parallelnutzung von dienstlicher und privater Sphäre meist nicht erwünscht oder sogar untersagt ist. Gruß, Nils

Moin, hart Ausschalten als Standardmethode ist keine gute Idee, besonders wenn es um servergespeicherte Profile geht. Leider sind Probleme dieser Art immer schwer zu lokalisieren, weil es tausende mögliche Ursachen gibt. Wenn es aber so dramatisch ist, wie du beschreibst, sollte man da noch weitere Ressourcen investieren. Das Risiko, kritische Daten durch beschädigte Profile zu verlieren, ist in den meisten Unternehmen durchaus hoch. Aber: Braucht ihr denn servergespeicherte Profile tatsächlich? Die Technik ist derart fehlerhaft, dass ich sie vermeiden würde, wo es nur geht. Und: Tritt das Phänomen auch bei rein lokalen Profilen auf? Gruß, Nils

Moin, klingt nach einem Timeout. Nur wo der herkommt - keine Idee. Sind andere Netzwerkzugriffe ebenfalls verzögert, wenn das Phänomen auftritt? Gruß, Nils

Moin, ich werfe mal kurz in die Runde, dass im Active Directory erheblich weniger schiefgehen kann als bei Exchange. Daher reicht für einen Health Check in aller Regel turnusmäßig dcdiag aus; häufiger als wöchentlich ist es selten nötig. Daneben kann man die Dienste auf den DCs überwachen, aber auch da läuft selten etwas schief. Interessant könnte vielleicht noch die Überwachung der Eventlogs sein. In der Praxis erweist sich das AD als ausgesprochen robust. Wo es Fehler gibt, sind diese meist auf das Design zurückzuführen, dann ist ein laufender Health Check allerdings auch nicht besonders aussagekräftig. Gruß, Nils

Moin, was genau tust du, was genau passiert, was genau wird gemeldet? Abgesehen davon, musst du die Kontorichtlinien in der Default Domain Policy bearbeiten. Gruß, Nils

Moin, schön, dass es geklärt ist. Trotzdem aber bitte beim nächsten Mal einen neuen Thread aufmachen. Das hebt die Übersichtlichkeit - zumal es immer so ist, dass die scheinbare Fortsetzung des alten Threads sich in Wirklichkeit doch um neue Details dreht. Gruß, Nils

Moin, aus meiner Sicht ist es ziemlich eindeutig, dass dein Vorhaben lizenzrechtlich nicht gedeckt ist. Für Testzwecke der Art, wie du sie beschreibst, sind die Testversionen da. Da du nicht der Lizenzgeber bist, kannst du auch nicht eine Nicht-Testversion nachträglich zu einer solchen umfunktionieren. Das Entfernen der Lizenz macht aus Windows ein unlizenziertes Windows, keine Testversion. Es ist auch ein Irrtum, dass ein "normales" Windows vor der Aktivierung als Testversion laufe - es ist dann eine nicht aktivierte, aber lizenzpflichtige Installation. Leider sehe ich immer wieder, dass Kunden (und auch Dienstleister) die Karenzzeit vor der Aktivierung als eine Art Shareware-Phase missdeuten. Windows ist aber nun mal keine Shareware. Die Testversionen laufen fast alle für 180 Tage. Das sollte zum Testen nun wirklich ausreichen. Gruß, Nils

Moin, wie Norbert schon richtig sagt, reichen deine Lizenzen im vorhandenen Konstrukt auch nicht: Wenn der physische Host noch was anderes als Hyper-V macht, "belegt" er eine der beiden Lizenzen. In einer 10-User-Umgebung ist es durchaus machbar, dass einer der Anwendungsserver auch Domänencontroller ist. Ist zwar kein richtig schönes Design, aber in solchen Umgebungen muss man immer Abstriche machen. Wichtig ist dann, dass es für das AD eine passende Recovery-Möglichkeit gibt. Dann kommst du vielleicht mit zwei VMs hin. Gruß, Nils

Moin, du kannst die beiden VMs exportieren und nach der Neuinstallation wieder importieren. Was du aber ändern solltest, ist die Konfiguration des Host-Betriebssystems. Neben Hyper-V sollten dort auf keinen Fall weitere Dienste laufen (AD, DNS, IIS oder was auch immer). Die gehören in eine VM. Beachte auch, dass deine zweite VM evtl. unlizenziert läuft: Ein Client-OS darfst du nicht einfach so als VM laufen lassen, dazu braucht es spezielle Lizenzen. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Gruß, Nils

Moin, naja, dann habt ihr ja jetzt auch ein ganz anderes Sicherheitskonzept. Aus Windows-Sicht war euer bisheriges Vorgehen nicht sicher, denn offenbar konnte derselbe lokale User zu ganz unterschiedlichen Identitäten gehören. Das sind typische Umstellungsschmerzen, wie sie immer auftreten, wenn man von den Novell-Konzepten des letzten Jahrtausends umsteigt. Manche wollen auch ihre alte, durchgelegene Matratze zurück, wenn sie ein neues Bett bekommen. :D Oder weniger flapsig: So riesig lang können die Zeiten ja nun auch nicht sein, die das Anlegen des neuen Profils dauert. In einer üblichen Umgebung passiert das ja auch nur einmalig pro Rechner. Bei euch fällt es nur durch das Zurücksetzen auf. Möglicherweise könntet ihr vor dem Erstellen des Images einmal alle User, die in Betracht kommen, dort anmelden, damit das Profil schon erzeugt ist. Bei kleinen Zahlen wäre das u.U. praktikabel, bei größeren natürlich nicht. Gruß, Nils