NilsK

Moin, könnte denn ein Virenscanner das Problem verursachen? Verhält sich der Browser ohne diesen genauso? Gruß, Nils

Moin, fast. Lud wäre richtig. Aber meinst du, dass das weiterhilft? Gruß, Niös

Moin, und, hilft der Lösungsansatz, der in dem Mozilla-KB-Artikel angegeben ist? Gruß, Nils

Moin, ja. Gruß, Nils

Moin, gibt es auf der Seite mit der Fehlermeldung einen Link zu näheren Informationen? Das kann evtl. hilfreich sein, weil die Browser da teilweise unterschiedliche Ansichten haben, was ein Sicherheitsproblem ist und was nicht. Ist das Rootzertifikat auf einer eigenen CA erzeugt? Ist diese evtl. neu eingerichtet worden? In solchen Fällen hatte ich Kompatibilitätsprobleme des Firefox mit bestimmten Algorithmen festgestellt, so mag es der FF nicht, wenn man in einer Windows-CA die Option "AlternateSignatureAlgorithm" aktiviert. Hier könnte es also evtl. helfen, die Fehlermeldung genauer zu inspizieren und ggf. die Konfiguration der CA zu prüfen. Gruß, Nils

Moin, das würdest du nur um den Preis hinbekommen, dass die interne Namensauflösung nicht mehr bzw. nicht mehr zuverlässig funktioniert. Da man das normalerweise nicht will, ist die Antwort: Geht nicht. Stell sicher, dass die internen DNS-Server ausreichend verfügbar sind. Hintergrund: Theoretisch kannst du zwar einem Client einen internen und einen externen DNS-Server eintragen, sodass vordergründig deine Anforderung erfüllt ist. Sobald aber ein (Windows-) Client einmal auf den externen DNS-Server ausweicht und von diesem eine gültige Antwort bekommt, wird er weiter immer den externen fragen, auch wenn der interne wieder erreichbar ist. Damit würde der Client ab diesem Zeitpunkt keine internen Adressen mehr auflösen können. Gruß, Nils

Moin, mit "eine ADS" meinst du eine Active-Directory-Domäne? Die hat mit Freigaben und NTFS-Berechtigungen nahezu nichts zu tun. Das sind Dinge, die es auf einem Dateiserver gibt, nicht im AD. Deine Frage ist auch darüber hinaus etwas konfus. Wenn du wissen willst, welche Berechtigungen es gibt, musst du dir die Berechtigungen ansehen und nicht einen User erzeugen. Je nachdem, wie umfangreich das Dateisystem ist, können dafür Hilfsmittel wie tenfold interessant sein. Man kriegt das aber auch manuell durch Nachgucken raus. Oder halbautomatisch durch Berechtigungs-Reports, für die man auch kostenlose Tools findet. Vielleicht ist es im konkreten Fall auch einfacher, nur die Berechtigungen der Ordner anzusehen, an die der Praktikant nicht randarf, und diese bei Bedarf zu ändern. Oder die Holzhammer Methode: Man richtet eine Deny-Gruppe ein, der man ausdrücklich den Zugriff verweigert, und nimmt dort den Praktikanten auf. Gruß, Nils

Moin, ich stimme @testperson zu. Es gibt an einigen Stellen eben Unterschiede in den Features verschiedener Systeme. Der Versuch, sowas irgendwie nachzubauen, wird erfahrungsgemäß schiefgehen - sei es, weil es Nebenwirkungen gibt, sei es, weil beim nächsten Update der Nachbau nicht mehr geht. Als vor zehn, fünfzehn Jahren bei SMB-Kunden eine größere Umstiegswelle von Tobit auf Exchange war, gab es solche Themen dort auch. In solchen Fällen ist es praktisch immer besser, die Arbeitsweise anzupassen. Prüfen, was man am Ende wirklich erreichen muss und dann einen neuen Lösungsweg finden. Wenn man den emotionalen Teil erst mal überwunden hat, kommt man damit am besten klar. Gruß, Nils

Moin, ohne nähere Details zu kennen, klingt das für mich nach einem Konstrukt, von dem ich dringendst abrate. Skripte, die irgendwer automatisch ausführt, müssen auf streng abgesicherten Pfaden liegen. Umso mehr, wenn es Startup-Skripte sind, denn die führt ein Rechner als "System" aus, was die höchste mögliche Berechtigungsstufe ist. Ein Skript, das an einem unsicheren Ort liegt, kann einfach mal so manipuliert werden, und schwupps ist das Netzwerk im Eimer. Und das ist dann auch schon der einzige sinnvolle Weg zur Lösung: Verfrachte die Skripte auf einen Windows-Dateiserver, der Mitglied derselben Domäne ist. Lege die Freigabe dort so an, dass die gewünschten Rechner Und/oder User Leserechte haben. Entferne Schreibrechte für alle, die die Skripte nicht ändern dürfen. Gruß, Nils

Moin, woran man mal wieder sehr schön sieht, dass man lieber sein Problem beschreiben sollte als seinen Lösungsweg ... Gruß, Nils

Moin, hm, warum drehen wir uns hier so lang im Kreis? Anscheinend ist einfach eure Art der Auswertung unpassend. Gruß, Nils

Moin, ich rate mal: Das ist keine Windows-Freigabe. Gruß, Nils

Moin, ich bin kein RDS-Spezi, aber Igel kann seit ca. 2010 mit RemoteApps umgehen. Wenn ich nicht falsch liege, ist dazu ein Modus auf dem Thin Client umzustellen, wo man dann die Daten der gewünschten RemoteApps einträgt. Gruß, Nils

Moin, stell dem User nicht den Desktop zur Verfügung, sondern nur das eine Programm als RemoteApp. Und sichere alle Dateibereiche, an die der User nicht ransoll, ausdrücklich mit Berechtigungen ab. Gruß, Nils

Moin, ja, aber 200 Standard Editions habt ihr in eurer Lizenzübersicht ja sicher auch nicht stehen. Gruß, Nils PS. ich meine mich zu erinnern, dass die VMs in so einem Szenario sogar mit Datacenter installiert werden müssen und man nur einzelne VMs stattdessen mit Standard installieren darf. Finde ich aber gerade keinen Beleg - ist auch schwierig, das zu suchen. Kann also auch ein Irrtum oder schlicht überholt sein. Falsch ist die Auswahl von Datacenter jedenfalls definitiv nicht.

Moin, ja, aber ... Diese GPMC-Beispielskripte fallen schnell auf die Nase, wenn man Sonderzeichen irgendwo verwendet. (Und bevor jemand sagt "das tut man ja auch nicht" - nützt nix, denn in Kundenumgebungen hat man das nicht in der Hand. Und: Es reicht schon ein Komma im Objektnamen, was in Deutschland als "Kaczenski, Nils" sehr üblich ist.) [Active-Directory-Double als Testumgebung | faq-o-matic.net] https://www.faq-o-matic.net/2006/12/17/active-directory-double-als-testumgebung/ Daher habe ich selbst mal eine Alternative gebaut: [Domänen-Double für Testzwecke | faq-o-matic.net] https://www.faq-o-matic.net/2016/05/02/domnen-double-fr-testzwecke/ Gruß, Nils

Moin, schau dir mal BETWEEN ... AND an. Gruß, Nils

Moin, man kann "in Azure" praktisch beliebige virtuelle Maschinen betreiben, also auch einen DC. Ob das Sinn ergibt, steht auf einem anderen Blatt. Und die Frage nach den Optionen richtet sich nach den Anforderungen - da fangen wir gerade an, uns im Kreis zu bewegen. Gruß, Nils

Moin, das glaube ich eigentlich nicht, aber wenn es erst mal läuft, ist ja okay. Man übertrage diesen Ansatz aber nicht auf andere Umgebungen. Gruß, Nils

Moin, nein, das heißt, dass du deine vorhandenen Zertifikate weiterhin hast, so wie früher auch. Sie sind nur halt veraltet. Du kannst neue nach dem jeweils gültigen Stand des Programms machen. Für manche "großen" Zertifizierungen gibt es "Abkürzungen", wenn man ein Vorgängerzertifikat hat, für andere nicht. Das war aber vor 15 Jahren auch nicht anders. Zwischendurch gab es z.B. den MCSE nicht mehr, dann wurde die Abkürzung mit neuer Bedeutung wieder eingeführt. Dafür gibt es heute den MCITP nicht mehr, den es zwischendurch gab. Und "der MCP" hat eigentlich auch schon irgendwann in den Nullerjahren seine frühere Relevanz verloren, weil es daneben immer auch andere Programme gab. Gruß, Nils

Moin, man darf das so verstehen, dass Microsoft den Namen "MCP" nach über 20 Jahren abschafft und die Zertifizierungen näher an den Erfordernissen des Marktes und der aktuellen Technik ausrichtet. Eine 1:1-Aktualisierung bestehender Zertifikate hat es immer nur punktuell gegeben. Wer über längere Zeit zertififziert bleiben wollte, musste auch bisher schon ein paar Wechsel der Ausrichtung mitmachen. Gruß, Nils

Moin, das kann man auf unterschiedliche Arten machen - eine Frage des Konzepts. In einem Forum kaum sinnvoll zu beleuchten. Die Frage, ob man lokal eine Domäne braucht, hängt natürlich von den detaillierten Anforderungen ab. Die wirst du wohl kaum hier posten, wenn es um einen Kunden geht. (Hoffe ich.) "Cloud" heißt hier gar nicht Cloud, sondern RZ, richtig? Option 1 wäre denkbar, Option 2 klingt unsinnig, Option 3 erschließt sich mir nicht (welchen Vorteil soll ein RODC bringen, wenn du dafür sowieso netzwerkseitig alles einrichten musst, was das AD braucht?) und bei Option 4 ist mir unklar, was das "Stichwort" soll. Gruß, Nils

Moin, ein nicht ganz fernliegender Gedanke wäre, dass die Leiste defekt ist. Auch wenn du das verbal ausgeschlossen hast. Gruß, Nils

Moin, das AD hat eine eingebaute Priorisierung über das Standort-Konzept. Wenn die Standorte korrekt definiert und die jeweiligen Subnets korrekt zugeordnet sind, funktioniert das ganz wunderbar. Von irgendwelchen sonstigen Basteleien ist dringend abzuraten. Im gegebenen Szenario mit zwei Domains, die einander vertrauen (nehme ich an) müssen die Standorte in beiden Domänen dieselben Namen tragen. Gruß, Nils

Moin, es liegt doch überhaupt kein Problem vor. Und das Verhalten ist völlig normal und so, wie es sein soll. Der "1. DC" ist FSMO-Rolleninhaber. Und er weiß, dass es noch einen zweiten DC gibt. Natürlich versucht er beim Neustart, diesen zweiten DC zu erreichen - er weiß ja nicht, wie lange er offline war. Antwortet der andere DC nicht, dann gibt der "1. DC" eine Warnung aus - nota bene, die 2092 ist eine Warnung, kein Fehler. Diese Warnung besagt, dass kein Kontakt zu den Replikationspartnern besteht, sodass der DC nicht prüfen kann, ob ihm vielleicht Daten fehlen. Abhilfe ist im Normalfall einfach: Den Kontakt zu dem anderen DC herstellen - hier, indem man ihn startet. Es könnte ja aber auch sein, dass die Netzwerkverbindung fehlt, dann müsste man diese herstellen. Das kann der "1. DC" in dieser Situation nicht feststellen, daher die Warnung. Gruß, Nils