NilsK

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, in so einer Situation würde ich nur die notwendigen Daten bereitstellen, also hier nur die Dokumente. Keine VM und sowas. Und wenn die Leute eine USB-Platte akzeptieren, ist doch super. Dann kann man sich allen weiteren Aufwand (und die Risiken) einfach sparen. Robocopy und fertig. Daher verstehe ich jetzt das Problem nicht ganz. Gruß, Nils

Moin, und die PST-Dateien. Gruß, Nils

Moin, es wird das eigentliche Problem nicht lösen, aber nimm die PST-Dateien von dem Netzlaufwerk und lege sie auf den Clients ab. Netzwerkzugriff auf PST-Dateien ist aua gutem Grund nicht supported und führt schnell zu Problemen. Gerade wenn das Netzwerk instabil ist, provozierst du sonst Datenverlust. Der Rest klingt nach Treiber- oder Hardwareproblemen. Ist die SSD im Server ein Servermodell oder ein Consumergerät? Gruß, Nils

Moin, und, was soll das aussagen? AD ist nicht abgekündigt. Neue Funktionen gibt es schon seit über zehn Jahren nur sehr selten. Und selbstverständlich wird Microsoft noch jahrelang in AD investieren - oder wie sollen die den Support gewährleisten? Oder kann er dir erklären, wie du die Funktionen, die Azure AD Domain Services nicht hat, ohne ein AD bereitstellen sollst, wenn du sie brauchst? Wenn ja, würde mich das auch interessieren - wird er aber nicht können. Rauch den Typ in der Pfeife. Der will sich großtun (und wird, wie alle bei MS, nur provisioniert, wenn er für Cloud Consumption sorgt). 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, hm, das Arbeiten mit Makros wird schwierig, wenn du von Office-Makros keine Ahnung hast. Früher oder später wirst du dich dort einarbeiten müssen. Als erste Näherung: Mit Alt-F11 öffnest du den Makro-Editor. Dann siehst du den Code und kannst ihn dir ansehen. Von dort aus kannst du ihn auch exportieren und in einem anderen Dokument importieren. Alles Weitere wird man in einem Forum nicht sinnvoll vermitteln können, aber etwas Recherche im Web gibt dir sicher sinnvolle Einstiegspunkte, um dich dem Thema zu nähern. Gruß, Nils

Moin, https://www.faq-o-matic.net/?s=batch+Domäne&submit=Suchen Gruß, Nils

Moin, ich stimme Norbert zu - das klingt noch nicht so richtig valide. Trotzdem bleibt aber die Frage offen, was du denn bezüglich der Hardware eigentlich abliefern sollst. 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, möglich ist das, aber bevor wir Tipps geben, die gar nicht passen ... Gruß, Nils

Moin, gut, wenn du alles schon konzipiert hast, kannst du uns ja ein paar Rahmendaten nennen. Ein Virtualisierungs-Host richtet sich im Sizing immer nach den VMs, die darauf laufen sollen. Wie viele VMs planst du? Wie viel RAM sollen diese VMs zusammengerechnet haben? Wie viel Plattenplatz sollen die VMs zusammengerechnet haben? Wie viele (virtuelle) CPUs sollen die VMs zusammengerechnet haben? Sind weitere Applikationen vorgesehen, die hinterher auf dieser Plattform laufen sollen? Was ist über diese bekannt? Wie planst du die Datensicherung umzusetzen? Sind erhöhte Anforderungen an die Verfügbarkeit zu erfüllen? Sind weitere Anforderungen an die Hardwareplattform zu berücksichtigen? Mit diesen Fragen solltest du den größten Teil des Sizings dann auch schon selbst bewältigen können. Was musst du denn genau im Rahmen der Aufgabe abliefern? Gruß, Nils

Moin, wer oder was ist ADSS? Meinst du vielleicht ADDS, also Active Directory? Gruß, Nils

Moin, dann ist es sicher wenig sinnvoll, wenn wir dir hier alles vorkauen, du sollst ja selbst was lernen. Zu konkreten Fragen können wir dir dann ggf. Hilfestellung geben, Wie weit bist du denn schon? Gruß, Nils

Moin, das klingt nach einer Aufgabe im Rahmen einer Ausbildung, richtig? Gruß, Nils

Moin, das möchtest du künftig ändern. Jetzt ist eine prima Gelegenheit. Gruß, Nils

Moin, welche Version hat der Host? VMs würde ich nur mit WS 2019 betreiben, wenn der Host auch mit 2019 läuft. Ansonsten gilt eigentlich immer: Keine OS-Upgrades bei Servern. Einen DC hat man viel schneller neu erzeugt als einen bestehenden anzupassen. Und einen Terminalserver will man auch lieber neu machen und die Benutzer umstellen. Gruß, Nils

Moin, OK. Danke für die Rückmeldung. Gruß, Nils

Moin, der Rest sind jetzt ausschließlich organisatorische Fragen. Auch dein VPN erzwingt keine tagelangen Wartezeiten - heute richtet man üblicherweise zwischen Standorten ein Replikationsintervall von 15 Minuten ein (das ist das Minimum), mit ein bisschen Kontrolle usw. reichen also 30 Minuten oder so zwischen den Vorgängen. Wenn du Skripte usw. hast, die einen DC-Namen enthalten, dann gibt es eigentlich nur zwei Möglichkeiten: Die Skripte machen Dinge, die nicht auf einen DC gehören. Dann umstellen auf ein anderes System. Die Skripte sprechen das AD an. Dann sollten die den Namen der Domäne nutzen,* nicht den eines DCs. Dahinter steckt ein simples Round Robin, das in aller Regel ausreicht und von konkreten Servernamen unabhängig ist. Und FSMO-Rollen sind in Wirklichkeit praktisch unkritisch für nahezu alle Situationen. Sie erfordern so gut wie nie andere Vorgehensweisen. Übertragen und gut. Da gibt es viele mythische Vorstellungen. [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] https://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Gruß, Nils PS. * noch schlauer ist es, Skripte so zu bauen, dass sie nicht mal den Domänennamen enthalten, sondern diesen auslesen bzw. aus Umgebungsdaten ableiten.

Moin, da sich deine DCs ja alle am selben Standort befinden, brauchst du nicht so lange Wartezeiten. Man kann das alles in einem Rutsch machen und zwischendurch halt Kaffeepausen einplanen (wenn überhaupt). Ein Tag für alles würde dicke ausreichen. Was den Namen anbelangt: Wenn du das wirklich willst (ich halte nichts davon, weil es ungünstige Abhängigkeiten festschreibt), dann kannst du zum Ende deiner Liste den Namen des DCs ändern, wenn du vorher den alten entfernt (oder ebenfalls umbenannt) hast. Wann du das wiederum tust, ist praktisch ausschließlich eine organisatorische Frage. Ich lese jetzt aber nur noch von einem DC, wolltest du nicht zwei tauschen? 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, und nur mal der Vollständigkeit halber: TLS ist immer "mit Zertifikaten". Die technische Sicherheit unterscheidet sich auch nicht zwischen selbstsignierten, internen CA-Zertifikaten und kommerziellen Zertifikaten, da ist keins "sicherer" als das andere. Unterschiedlich ist nur, wie den Zertifikaten vertraut wird. Gruß, Nils PS. wenn wir schon dabei sind: Eine Root-CA sollte natürlich einem Server kein Zertifikat ausstellen, das ist Aufgabe einer Issuing CA.

Moin, "bitte im ganzen Satz" (Loriot) ... Hinter meinem Link befanden sich drei Möglichkeiten, die Rechte zuzuweisen. Um hier weiterzukommen, müsstest du also bitte angeben, was du genau gemacht hast: Welche Berechtigungen hast du wo gesetzt? Wie bist du vorgegangen, um das zu testen? Gruß, Nils

Moin, und heißt genau was? Gruß, Nils

Moin, man braucht keinen Unternehmensnachweis, wenn du das meinst. Als Firmennamen kannst du z.B. deinen eigenen Namen setzen, so würde es etwa ein Freibrufler auch tun, der hat ja auch kein Unternehmen im rechtlichen Sinne, darf aber u.U. die "Home"-Versionen nicht nutzen, weil es kommerziell geschieht (da bin ich grad nicht so in den Details). Wobei Teams als Einzelperson ausgesprochen wenig spannend ist - ich würde da also noch mal prüfen, was tatsächlich die Anforderung ist. Gruß, Nils