NilsK

Moin, ich widerspreche. Das Scavenging muss man an mehreren Stellen aktivieren, und das muss gezielt geschehen: In den Eigenschaften der Zone gibt man die Grundkonfiguration vor mit zwei Intervallen. Genau verstehen, was diese Intervalle bedeuten! Das macht man einmal, weil es in den Eigenschaften der Zone hinterlegt und mit ihr repliziert wird. In den Eigenschaften des DNS-Servers gibt man an, ob dieser das Scavenging auch durchführen soll. Hier gibt es ein weiteres Intervall. Es gilt die (dringende) Empfehlung, dass nur ein DNS-Server in der Umgebung den Prozess ausführt, weil man nur dann die Intervalle wirklich einschätzen kann und weil dann ausgeschlossen ist, dass sich Löschvorgänge mehrerer Server überlagern. Ganz wichtig: Sobald man das Scavenging aktiviert hat, muss man - mindestens in der Anfangszeit - die Umgebung genau beobachten. Die neu aktivierte Option neigt dazu, zunächst zu viele Einträge zu löschen, die man dann ggf. manuell wiederherstellen muss. Hier muss man also zügig reagieren können und den Hintergrund kennen. Gruß, Nils

Moin, wenn es eine Option ist, eine "normale" Windows-Server-Lizenz zu kaufen, dann nimm nicht den kostenlosen Hyper-V-Server. Weise die Lizenz dem Host zu, dann kannst du diesen mit GUI nutzen. Auf diesem Host darfst du dann zwei Windows-Server-VMs mit derselben Version betreiben. Wenn User auf diese zugreifen, brauchst du allerdings CALs. Geht auch, geht technisch sogar besser. Ist aber ein anderes Konstrukt. Ob du einen Essentials-Server in eine bestehende Domäne aufnehmen kannst, weiß ich nicht. Könnte sein, dass nicht. Gruß, Nils

Moin, Windows Server Essentials darf als VM in einem Hypervisor arbeiten. Da hier eine spezielle Lizenzierung vorliegt, kommt der "kostenlose" Hyper-V Server in Betracht. Beachte allerdings, dass du auf diesem Host dann keine anderen Windows-Server betreiben darfst, weil dazu die VM-Lizenzen fehlen würden. Weitere VMs mit Linux usw. wären möglich. Den Host ins AD aufzunehmen, wäre an der Stelle ziemlicher Aufwand und ergäbe nahezu keinen Vorteil. Da du den wesentlichen Teil der Konfig ohnehin ohne Domäne machen müsstest (die existiert ja erst, wenn die VM mit Essentials läuft), käme der Aufwand mit der "manuellen" Host-Konfiguration ohnehin auf dich zu. Vielleicht wäre ein Zusatzprodukt wie 5Nine Manager interessant, um den Host leichter verwalten zu können. Für den kostenlosen Hyper-V Server gibt es keinen Support vom Hersteller. Die Features sind gegenüber der "Vollversion" nicht eingeschränkt. Gruß, Nils

Moin, die Situationen, in denen in der Kombination irgendwas nicht geht, dürften wohl auch eher selten sein. Das Problem ist nur: Wenn es so eine Situation gibt, dann gewährt der Hersteller keinen Support - das sagen die ausdrücklich. Man kriegt das dann also im Zweifel nicht gelöst. Mir wäre das entschieden zu heikel. Gruß, Nils

Moin, vielleicht kann man mit der IT ja noch mal reden - wenn die das Zertifikat als Trusted Root hinterlegen, reicht das schon aus. Da der Kunde dich ja kennt, wäre das ausreichend sicher. Und ansonsten finde ich unter 200 Dollar jetzt auch wieder nicht so teuer, wenn man sein Geld damit verdient. Wichtig beim Einsatz des Zertifikats: Gib einen Timestamp-Server mit an, damit der Code nicht jedes Jahr neu signiert werden muss. Gruß, Nils

Moin, du könntest das umsetzen, indem du eine Gruppe von "normalen" Domänenbenutzern erzeugst (nicht die vordefinierte "Domänen-Benutzer") und denen per GPO die Anmeldung an das System verweigerst. Alternativ könntest du die Gruppe "Domänen-Benutzer" aus der lokalen Gruppe "Benutzer" entfernen. Ob das, was so rein technisch betrachtet möglich ist, auch Sinn ergibt, steht auf einem anderen Blatt. Ich würde eher noch mal über das Konzept nachdenken. Mit lokalen Usern will man nicht arbeiten, da hat Norbert (der andere) schon Recht, und NorbertFe hat ebenfalls Recht. Gruß, Nils

Moin, "aus Kulanz zumindest ein Gespräch möglich" ... ich bin erstaunt. Was habt ihr denn in eurer Gegend für Dienstleister? Wollen die keine Leistungen verkaufen? Wegen Wohlstand geschlossen? Was du vorhast, ist kein Hexenwerk. Nur wenn man sich alle Kenntnisse selbst aufbauen muss, ist das eben neben der "eigentlichen" Geschäftsgründung deutlich zu viel. Mehr als Empfehlen kann ich an der Stelle aber nicht. Gruß, Nils

Moin, nimm es mir nicht übel, aber für mich klingt das nach Anforderungen, die man "allein" und "nebenbei" nicht gewuppt bekommt, wenn das Geschäftsmodell davon abhängt. Als Gründer und damit wohl Geschäftsführer wirst du dich um diese Themen ja kaum in Vollzeit kümmern können. An deiner Stelle würde ich als den Use Case und die Anforderungen möglichst genau skizzieren und damit auf die Suche nach einem Unterstützungspartner gehen. Gruß, Nils

Moin, um Code zu signieren, benötigt der jeweilige Entwickler ein Zertifikat mit dem Einsatzzweck "Code Signing". Das bekommt man bei allen wichtigen kommerziellen CAs, bei Digicert etwa ab ca. 180 US-$ pro Jahr Laufzeit. Wenn du den Umgang damit einschätzen und die Eignung prüfen willst, tut es zunächst auch ein selbstsigniertes Zertifikat. Was ist denn eigentlich der konkrete Bedarf? Gruß, Nils

Moin, bau das Design in Ruhe auf und teste es, bevor du es produktiv nimmst. Nimm dir genügend Zeit und passende Lektüre. Es kann durchaus auch sinnvoll sein, für diesen Planungsschritt jemanden ins Haus zu holen, der die Materie kennt. Es gibt zu viele Besonderheiten, als dass man dies auf der Ebene in einem Forum sinnvoll diskutieren könnte. Gruß, Nils

Moin, was genau heißt hier "im Internet stehen"? Ansonsten lässt sich deine Frage nicht vollständig beantworten. "Ausfallsicherheit" und "Hochverfügbarkeit" sind aus Systemsicht identisch. Dafür stehen verschiedene Techniken zur Verfügung, die häufigsten sind ein "herkömmlicher" Failovercluster und Always-on-Verfügbarkeitsgruppen. Was die Updatefähigkeit angeht, wird man u.U. viel tiefer in die Applikationslogik einsteigen müssen. Die Updates des Betriebssystems und des SQL Servers lassen sich in aller Regel über das Clusterkonstrukt ohne Downtime für die Anwender durchführen. Die Datenbank-Updates haben aber mit der zugreifenden Applikation zu tun. Ob und ggf. wie man da mit Replikationsmechanismen arbeiten könnte, lässt sich ohne Einbindung der Applikationsentwickler nicht beantworten - das kann ein dickeres Brett sein. Spätestens hier ist es also relevant, die Anforderungen genau zu definieren. Und, da du selbst angibst, von der Materie wenig Kenntnis zu haben: Holt euch Unterstützung. Gruß, Nils

Moin, wenn Neuinstallation eine Option ist, könnte es eine zeitsparende Variante sein. Alles andere wäre in einem Forum schwer zu handhaben, weil es schnell -zig zu prüfende Stellen beinhalten kann. Gruß, Nils

Moin, schmeiß den Datenbanksupport raus. Man installiert nicht mal eben irgendwelche VPN-Komponenten auf einem Server. Was auch immer da geschehen ist, scheint den Netzwerkstack im Betriebssystem durcheinander gebracht zu haben. Das Problem liegt mit hoher Sicherheit nicht auf Ebene von Hyper-V. Was man jetzt tun kann, lässt sich aus der Ferne kaum sagen. Sofern sich durc strukturiertes Vorgehen das Gast-OS nicht reparieren lässt, wäre evtl. ein Recovery des Servers oder eine Migration auf einen neuen Server nötig. Gruß, Nils

Moin, sorry, aber das ist nicht zu verstehen. Beschreibst du das bitte noch mal ordentlich? Gruß, Nils

Moin, nee, das ist es nicht. Diese Einstellung steuert, ob man den Lockscreen mit irgendeiner Taste zur Anmeldeseite öffnet (Standard z.B. in Windows 10) oder ob man "wie früher" Strg-Alt-Entf drücken muss. Gruß, Nils

Moin, das mag sein, aber ohne getrennte Konten am PC wirst du das Problem nicht lösen können. Gruß, Nils

Moin, in der aktuellen c't sind ein paar Artikel, die sich mit solchen Themen befassen. Die großen Namen scheinen aktuell am weitesten vorn zu sein. Zu Norberts Liste würde ich noch Digicert erwähnen, die haben einerseits das Zertifikatsgeschäft von Symantec übernommen und haben andererseits einen guten Service (Letzteres trifft auf einige andere auch zu, etwa Comodo). Gruß, Nils

Moin, "Sizing"? Damit meinst du was? Wenn du einen zusätzlichen DC zur Domäne hinzufügst, dann repliziert der das AD. Mehr nicht. Um die anderen Dienste und Daten musst du dich schon einzeln kümmern. Was ist denn eigentlich das Ziel der Aktion? Den SBS ablösen? Wenn ja: Erstens darfst du hier gern erwähnen, was du vorhast - das hebt die Chance, dass du passende Antworten bekommst. Zweitens: Sowas macht man nicht mal eben so nebenbei und auch nicht im laufenden Produktionsbetrieb. Gruß, Nils

Moin, das ist nicht so ohne Weiteres möglich. Spätestens beim Import wird es schwierig, weil die Berechtigungen intern mit SIDs gespeichert sind, nicht mit den Namen der Konten. Da die Objekte in der Zieldomäne andere SIDs haben, lassen sich die Quellberechtigungen so nur mit höherem Aufwand übertragen. Du findest im Web eine ganze Reihe von Skripten, die die ACLs von AD-Containern ausgeben. Basierend darauf könnte man eine CSV-Logik bauen, die die Namen (nicht die SIDs) der berechtigten User oder Gruppen pro Container ausgibt. Damit könnte man dann ein Importskript bauen. Aber: Die Berechtigungen im AD können sehr komplex sein, es kann durchaus -zig Einträge für einen Container geben. Erschwerend kommt hinzu, dass die meisten ACL-Einträge vererbt sind. Noch dazu kann die Vererbung ihrerseits sehr komplex sein. Und damit nicht genug: Berechtigungen können auch für einzelne Objektklassen oder sogar für Attribute gelten. Damit müsste eine Lösung passend umgehen - das macht die Sache beliebig aufwändig. Hier wäre also zu prüfen, ob ein Import/Export wirklich eine passende Lösung ist. Gruß, Nils

Moin, den Einwand höre ich immer mal wieder, aber wie Norbert schon sagt: Das ist eine prinzipielle Frage, die auf das Funktionsprinzip einer Festplattenverschlüsselung abzielt. Die Festplattenverschlüsselung - speziell Bitlocker, aber im Prinzip auch die anderen - soll "Data at rest" schützen, also die Offline-Daten auf der Festplatte. Es soll nicht möglich sein, die Platte in einen anderen Rechner einzubauen und dort zu lesen. Ebenso soll es nicht möglich sein, den Rechner mit einem anderen Betriebssystem zu starten und die Daten damit zu lesen. Sobald der Rechner gestartet ist und das zugelassene Betriebssystem läuft, ist dieses für den Schutz der Daten verantwortlich. Die reine Verschlüsselung nützt also wenig, wenn das Betriebssystem nicht ausreichend sicher konfiguriert ist. Im Energiesparmodus läuft aus dieser Perspektive das Betriebssystem weiter. Der Zustand unterscheidet sich aus Sicht der Festplattenverschlüsselung also nicht von einem laufenden Betriebssystem - Windows muss dafür sorgen, dass nur autorisierte Zugriffe stattfinden. Oder anders gesagt; Jede (marktübliche) Festplattenverschlüsselung zielt nur auf bestimmte Szenarien, typischerweise auf Offline-Angriffe. Für alle anderen Szenarien müssen andere Schutzmechanismen ergänzt werden. Oder noch anders gesagt: Der Energeisparmodus umgeht Bitlocker nicht, und er ist auch nicht per se ein Sicherheitsproblem. Gruß, Nils

Moin, grundsätzlich ist ein RODC nicht primär für den Betrieb in einem "weniger sicheren" Netz gedacht. Man kann ihn dafür zweckentfremden, aber dann muss das Gesamtdesign dazu passen. So wäre es hier mindestens erforderlich, den Verkehr aus dem Fertigungsnetz so einzuschränken, dass kein Rechner eine Kommunikation mit den DCs im "sicheren" Netz herstellen kann, denn sonst könnte man den RODC ja auch einfach umgehen. Man kriegt so etwas hin, aber das ist nicht trivial und lässt sich nicht innerhalb eines Forums klären. Ob das Ganze dann ein sinnvolles Konstrukt ergibt, ist eine Frage des Gesamtdesigns und der Anforderungen, wie Norbert schon richtig sagt. Gruß, Nils PS. Da Norbert und ich uns zufällig gerade mit sowas befassen: Für so ein Design kann es durchaus erforderlich sein, ein umfangreiches Projekt mit Laufzeiten von mehreren Monaten und entsprechendem Aufwand aufzusetzen.

Moin, die Computerrichtlinien gelten immer nur für die lokalen Konten des jeweiligen Rechners. Möchte man die Einstellungen für die Konten des AD vornehmen, dann geht das nur in einem GPO, das auf der Domänenebene definiert ist - und nur dort. GPOs auf OU-Ebene wirken nicht auf die Kennworteinstellungen von AD-Konten, sondern würden sich nur auf die lokalen Konten der Computer auswirken, deren Konten in der betreffenden OU gespeichert sind. Aufgrund diverser Effekte sollten die Kennworteinstellungen für das AD ausschließlich in der Default Domain Policy definiert werden, nicht in einem eigenen GPO auf Domänenebene. Die Einstellung "Kennwort läuft nie ab" bei einem Useraccount übersteuert für diesen einen Account das maximale Kennwortalter, das per Policy gesetzt ist. Gedacht ist das vor allem für Dienstkonten, damit nicht urplötzlich der SQL Server wegen eines Anmeldefehlers stehenbleibt. Alle anderen Einstellungen der Policy gelten dann aber weiter. Dies betrifft sowohl lokale als auch AD-Konten. Gruß, Nils

Moin, zunächst einmal würde in dem Status, in dem sich die Anfrage befindet, zunächst eine Beratung erfolgen. Das geht zwar grundsätzlich auch telefonisch, aber erfahrungsgemäß ist man da sehr eingeschränkt. Dann kann es durchaus sein, dass man im Zuge dieser Beratung feststellt, dass es auf mehr als ein wenig Detailkonfiguration hinausläuft. In sofern wäre es natürlich schon relevant, ob wir von Flensburg oder Oberammergau reden, denn wenn der eine oder andere Termin vor Ort sinnvoll ist, entscheidet die Entfernung über die Kosten mit. Auch wenn es nicht der Sinn dieses Forums ist, Dienstleistungsangebote zu unterbreiten: Das Unternehmen, bei dem ich arbeite, ist in Hannover. Wenn das von Interesse ist, schreib mir gern eine PM. Gruß, Nils

Moin, was hast du da vor? Ist das eine Testumgebung? Zu welchem Zweck? Was meinst du mit ? Gruß, Nils

Moin, auf keinen Fall mit dem Delegations-Assistenten arbeiten! Das Ding ist unbrauchbar. Man kann fast nichts damit festlegen - und vor allem: Man sieht nur das, was man jetzt gerade neu einrichtet, aber nicht den vorhandenen Zustand. Damit kann man sich z.B. dann auch nicht korrigieren. Auch wenn es zunächst aufwändiger ist: AD-Berechtigungen nur per dsacls mit einem Skript setzen und immer in einem Testlab detailliert durchspielen. Das so entwickelte Skript kann man dann auf die Produktion anwenden, gleichzeitig bildet es die Dokumentation. Siehe Schritte 1 und 2 aus: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Zur Kontrolle vorhandener AD-Berechtigungen eignet sich LIZA: [Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net] https://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/ Abgesehen davon, klingt die beschriebene OU- und Berechtigungsstruktur, als sollte man da dringend das Design überarbeiten. Gruß, Nils