NilsK

Moin,
 
das dürfte lizenzrechtlich nicht gehen. In dem Fall müsste, wenn ich nicht irre, Firma A mit SPLA-Lizenzierung arbeiten. Das wäre aber ein völlig anderes Konstrukt.
 
Aber auch technisch dürfte das nicht allzu sinnvoll sein. Die Firmen sollten sich in Ruhe beraten lassen, damit der Bedarf geklärt und Lösungsmöglichkeiten entwickelt werden.
 
Gruß, Nils
 

Moin,
 
die Methode PromptForChoice() gibt immer nur die Indexnummer der Auswahl zurück. Dein Code müsste diese also noch auswerten. Ein Beispiel dafür findest du hier, sehr simpel mit "switch":
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ff730939(v=technet.10)
 
Je nachdem, was ihr vorhabt, könnte man die Werte in ein Array schreiben und damit dann die gewählte Option leichter zuordnen als per "switch".
 
Gruß, Nils
 

Moin,
 
du solltest immer das eigentliche Ziel im Auge behalten. Wenn du nicht willst, dass das VPN für andere Zwecke als Remote-Administration genutzt wird, dann setze etwas um, das dies auch erreicht. Die Domänen-Anmeldung einzuschränken, hilft dann nicht. Mit Cached Credentials könnte man von einem "Leih-Notebook" trotzdem Ressourcen aus der Zentrale verwenden, die das WAN weit mehr auslasten als ein paar GPOs. Denk etwa an Gigabyte-Dateien von einem Fileshare.
 
Für die Anforderung scheint mir Norberts Vorschlag besser zu passen. Ergänzen könnte man das noch um eine Begrenzung der zugelassenen IP-Adressen.
 
Gruß, Nils
 

Moin,
 
Ist supported. Eine Quelle kann ich dir aber nicht nennen.
 
Gruß, Nils

Moin,
 
 
 
das scheint mir ein Missverständnis zu sein. Es gibt eine CMD-Fehlermeldung, die sowas in der Art sagt - aber die bedeutet, dass das aktuelle Arbeitsverzeichnis in einem CMD-Fenster kein UNC-Pfad sein kann (es muss ein Laufwerk mit Buchstabe sein). Zugreifen kann man aus einem CMD-Fenster natürlich auf UNC-Pfade.
 
Gruß, Nils
 

Moin,
 
nein, das lässt sich so nicht konfigurieren. Die (empfehlenswerte) Standardeinstellung ist, dass die Logs nach Größe rotiert werden. Wenn also die Maximalgröße erreicht ist, löscht Windows die ältesten Einträge, um neue speichern zu können.
 
In kritischen Situationen kann das Log sehr schnell sehr stark anwachsen. Es ist also empfehlenswert, mindestens für wichtige Systeme einen regelmäßigen Export der Logs in ein separates System vorzunehmen, damit man die Dinge noch nachverfolgen kann. Wenn es etwa Sicherheitsvorfälle gibt, kommt es oft vor, dass das Log nur wenige Stunden in die Vergangenheit reicht, weil so viel geschrieben wird.
 
Ich hab dafür mal ein Beispiel gebaut:
[Eventlog-Backup mit Log Parser | faq-o-matic.net]
https://www.faq-o-matic.net/2011/03/21/eventlog-backup-mit-log-parser/
 
Das erfüllt aber keine erhöhten Ansprüche und ist eher als Illustration der Grundidee gedacht.
 
Gruß, Nils
 

Moin,
 
OK. Also, die Subnets in der AD-Konfiguration sind symbolische Einträge, die mit dem "realen" Netzwerk nichts zu tun haben. Solange die vier /24-Subnets also der Konfiguration des "echten" /22-Netzwerks nicht widersprechen, brauchst du nichts zu ändern. Wichtig ist nur, dass ein Client (damit sind auch Mitgliedsserver gemeint) eindeutig feststellen kann, zu welchem AD-Standort ("Site") er gehört.
 
Dass ein /22-Subnet heute eher nicht mehr als empfehlenswert gilt, steht auf einem anderen Blatt.
 
Gruß, Nils
 

Moin,
 
Azure AD ist kein Ersatz für ein lokales Active Directory. Auch die Azure AD Domain Services sind das nicht. Das erste hat nahezu nichts mit einem AD zu tun, das andere bietet nur rudimentäre Dienste.
 
Der Rest hängt von den Anforderungen ab. Aber ziemlich sicher werden die meisten Firmen, die größer als ein neues Start-up sind, auf mittlere Sicht auch weiterhin ein "herkömmliches" AD brauchen.
 
Gruß, Nils
 

Moin,
 
sieht so aus, als sei im DNS deiner Fritzbox die IP-Adresse mit der .14 für den Namen "nas5" eingetragen. 
 
Gruß, Nils
 

Moin,
 
die Meldung kommt eigentlich nur, wenn das dort genannte Phänomen auftritt: Es gibt bereits eine Session zu dem Server von dem Client aus unter anderem Benutzernamen. Daher mutmaße ich mal: Der Share liegt auf einem Server, auf dem ihr auch "normale" Daten ablegt, und von jedem Client aus hat der dortige "Hauptnutzer" bereits eine Session offen.
 
Gruß, Nils
 

Moin,
 
korrekt. Die Programmdateien werden im Wesentlichen nur einmal angefasst, um sie zu starten. Vielleicht hier und da noch mal eine DLL, aber das ist irrelevant. 
 
In einer Datenbank, die mit vielen Änderungen unter Dampf ist, sollte vor allem das Transaktionsprotokoll auf schnellem Speicher liegen. Das kann sogar noch wichtiger sein als die Datenbankdateien selbst - aber das hängt sehr stark von der Art der Nutzung ab. Datenbanken sind sehr unterschiedlich; was bei der einen gut ist, kann bei der anderen völlig falsch sein.
 
Gruß, Nils
 

Moin,
 
ja, dafür kann ein internes Zertifikat interessant sein. Wenn es nur solche einfachen Zwecke (einzelne interne TLS-Zertifikate) in einer kleinen Umgebung sind, dann reicht eine einstufige PKI meist aus. Die würde ich dann direkt als Enterprise-CA in die Domäne installieren.
 
Sollte sich später Bedarf an anderen Zwecken auftun (insbesondere Verschlüsselung zur Datenablage), dann kann man eine zweistufige PKI auch nachträglich neu einrichten. 
 
Gruß, Nils
 

Moin,
 
soll der SBS als Server bestehen bleiben? Oder soll der sowieso weg? Falls er weg soll, kannst du ihn auch einfach abschalten und aus dem AD entfernen, ohne vorher dcpromo zu machen. Die Informationen im AD zur Zertifizierungsstelle könntest du danach aus dem AD löschen, wenn du sie nicht per Backup auf einen neuen Server übertragen willst (was man in SBS-Umgebungen so gut wie nie braucht).
 
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
 

Moin,
 
zu dem Thema findest du hier im Board zahlreiche Diskussionen. Eine Suche wird dir einiges aufzeigen.
 
Generell und kurz: Der AD-Funktionsmodus betrifft nur die Domänencontroller und in manchen Situationen die Exchange-Server. Clients und andere Serverdienste sind davon nicht betroffen. Sofern die eingesetzte Exchange-Version keine Einschränkungen erfordert, kannst du den Level also problemlos auf die höchste verfügbare Einstellung anheben.
 
Die Voraussetzungen für bestimmte Exchange-Versionen findest du mit einer Websuche nach "exchange server prerequisites".
 
Gruß, Nils
 

Moin,
 
das Problem dürfte sein, dass die Fritzbox IPv6-Adressen nach "innen" verteilt. Dadurch zeigt der IPv6-DNS-Eintrag (vermutlich) auf die Fritzbox. Und die kennt natürlich deine Domäne nicht.
 
Ich habe selbst kein solches Setup, kann also keine konkreten Tipps dazu geben. Hier im Board bzw. im Web solltest du aber was dazu finden.
 
Gruß, Nils
 

Moin,
 
aber warum würde man das machen wollen? Wenn ihr SSO habt, ist das ja sicher über ADFS gesteuert. Dann kann man da doch einfach festlegen, wer sich anmelden kann und wer nicht. Irgendwelches Gebastel braucht man dann nicht und es funktioniert sowohl im LAN als auch von außerhalb.
 
Gruß, Nils
 

Moin,
 
Auf einem DC dürfen sich nur Administratoren anmelden. Du musst der Gruppe also noch die interaktive Anmerkung auf den DCs gestatten.
 
Gruß, Nils
 

Moin,
 
ja, das trifft zu.
 
Gruß, Nils
 

Moin
 
du erzeugst zwei Gruppen. In eine (A) kommt der Rechner der Ober-OU, in die andere (B) die Rechner der Unter-OU.
Dann erzeugst du zwei GPOs. Die eine (alpha) regelt, was für den/die Rechner der Gruppe A gelten soll. Die andere (beta) regelt, was für die Rechner der Gruppe B gelten soll.
 
GPO alpha koppelst du an die Ober-OU und stellst in den Sicherheitseinstellungen der GPO alpha ein, dass sie nur für die Gruppe A übernommen werden soll.
GPO beta koppelst du an die Unter-OU und stellst in den Sicherheitseinstellungen der GPO beta ein, dass sie nur für die Gruppe B übernommen werden soll.
 
Das testest du zunächst in einer separaten Laborumgebung. Wenn es da fertig entwickelt und getestet ist, überträgst du es in die Produktion.
 
Gruß, Nils
 
 

Moin,
 
vielleicht liegt dasselbe Missverständnis vor wie in dem Thread, auf den du dich beziehst.
 
DFS Namespace funktioniert so, dass du mehrere Shares unter einem gemeinsamen Überordner bereitstellen kannst. Diese bilden dann aber weiter zwei getrennte Ordner.
 
\\domain.tld\dfs-root\Daten\Buchhaltung (das ist der Share Buchhaltung auf Server A)
\\domain.tld\dfs-root\Daten\Vertrieb (das ist der Share Vertrieb auf Server B)
 
DFS ist nicht dafür gedacht, aus mehreren Shares einen einzigen Ordner zu machen. Man kann da zwar etwas tricksen, wenn es nötig ist, aber dazu muss man genau wissen, was man tut - und gemeint ist es so eben nicht. Es geht um einen gemeinsamen Baum zur Navigation, nicht um das Zusammenführen getrennter Ordner.
 
Wenn du für denselben DFS-Ordner mehrere Quellen (Ordnerziele) angibst, dann ist das als eine Art Redundanz gedacht. In dem Fall müssen die Inhalte von ShareA und ShareB identisch sein, was man über DFS-R oder andere Mechanismen erreichen kann. Der Client verbindet sich immer nur mit einem der Ordnerziele - was meist dafür genutzt wird, dass Clients an Standort A sich mit dem Share/Server an Standort A verbinden und Clients an Standort B eben mit dem am Standort B. Da das eine ganze Menge von Folgeproblemen aufwirft, ist das nur für wenige Szenarien geeignet.
 
Gruß, Nils
 

Moin,
 
dazu gibt es zwei Wege:
die CA-Zertifikate einer Enterprise-CA holt sich ein Client selbst, wenn er über das AD die CA entdeckt für alle CA-Typen können die Zertifikate auch per GPO verteilt werden Oft macht man beides parallel, um sicherzugehen, dass die Zertifikate ankommen. Die Clients brauchen diese, damit sie den CAs vertrauen und von diesen ausgestellte Zertifikate akzeptieren.
 
Gruß, Nils
 

Moin,
 
dies hier hilft nicht?
https://docs.microsoft.com/de-de/azure/backup/backup-azure-arm-restore-vms
 
Gruß, Nils
 

Moin,
 
naja, ich denke, ab Server 2012 wird der Registry-Key einfach nicht mehr verwendet. Es hat sich bei MS aber niemand die Mühe gemacht, ihn zu entfernen - vermutlich weil man dadurch Skripte, Funktionen usw. kaputt machen würde.
 
Gruß, Nils
 

Moin,
 
ich tippe mal: du hast das beim ersten Mal falsch eingetippt und die CA verwendet immer noch das Zertifikat mit dieser Angabe. Es im Dialogfeld zu ändern, reicht nicht aus. Du musst dann das Zertifikat neu ausstellen, wo dieser Pfad drinsteht.
 
Gruß, Nils