NilsK

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

Moin, es müssten die hier sein: https://social.technet.microsoft.com/Forums/windows/en-US/e3daed0a-0cf0-48ff-97d1-8735155a9931/how-to-delegate-control-move-computer-objects-from-one-ou-to-another Gruß, Nils

Moin, du hast ntdsutil falsch verwendet. Am der Stelle gibst du den Ziel-DC nicht im Befehl per Namen an, sondern du musst in einem mehrschrittigen Verfahren erst eine Verbindung zu dem Objekt herstellen und kannst es dann mit dem Kommando (ohne Namen) löschen. Aber wie ist denn jetzt der Stand? Alles hinbekommen oder wie? Gruß, Nils

Moin, SYSTEM kannst du nicht berechtigen. In solchen Fällen berechtigt man das Computerkonto, das sollte funktionieren. Ohne zu wissen, was du da machst, warne ich aber davor. Es birgt hohe Risiken, Skripte als SYSTEM laufen zu lassen. Die dürfen immerhin alles. Gruß, Nils

Moin, wieso "aber"? Wenn du dringend irgendwohin musst, fährst du dann auch einfach in irgendeine Richtung? Siehst du, da geht es ja schon los. Aber muss jeder selbst wissen. Ich werde trotzdem nicht müde, darauf hinzuweisen. Gruß, Nils

Moin, ein löbliches Ansinnen - aber wenn es einen Sinn ergeben wollt, dann geht auch den nächsten Schritt und erarbeitet ein Recovery-Konzept, das zu eurem Unternehmen passt. Das ist deutlich mehr als die - entschuldige den Ausdruck - naive Ansicht, man müsse nur technisch was tun und Daten kopieren. Gruß, Nils

Moin, ob die Syntax dann so passt, kann ich jetzt nicht sagen, aber das Pipe-Zeichen steht für "oder". Du gibst also entweder den Port an, auf dem die jeweilige Instanz lauscht, oder deren Instanznamen. Gruß, Nils

Moin, im ersten Zitat (November) ist von Exchange Online die Rede, im zweiten )April) von "User". Zumindest aus der Sicht würde die Einschränkung auf Outlook ja passen. Dann würde ich aber (auch) vermuten, dass die anderen Produktbestandteile an anderer Stelle erwähnt sind. Office 365 ist ja mehr als Exchange Online. Gruß, Nils

Moin, ich ergänze mal: [Benutzerprofile an neue Benutzer übertragen | faq-o-matic.net] https://www.faq-o-matic.net/2010/02/07/benutzerprofile-an-neue-benutzer-bertragen/ Und keine Servergespeicherten Profile, da hat Jan völlig Recht. Gruß, Nils

Moin, und genau deswegen ist sie ja nicht "sinnfrei", sondern kann sehr sinnvoll sein. Sie passt nur eben längst nicht auf jedes Szenario, sondern deckt nur ganz bestimmte Risiken ab. Daher muss man immer die Anforderungen klären, was in der IT allgemein ausgesprochen unbeliebt ist. Gruß, Nils

Moin, die krumme Banane sieht mir doch verdächtig nach genau diesem Problem aus: [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Ich vermute also mal: Die AD-Domäne nutzt einen DNS-Namen, der im Internet erreichbar ist. Gruß, Nils

Moin, von welcher Anzahl sprechen wir denn? Man berücksichtige, dass der Raspi immer eine Bastellösung ist. Als Proof of Concept sicher spannend, für sehr kleine Stückzahlen mag es auch gehen. Aber schon bei 20 oder 30 Arbeitsplätzen wäre ich skeptisch, ob das kaufmännisch wirklich aufgeht. Man müsste die Dinger ja noch in Gehäuse friemeln, passende Netzteile finden (ein Handy-simpel-Netzteil wird kaum ausreichend zuverlässig sein), und am Ende ist das Software-Deployment per SD-Karte sicher keine Freude. Gruß, Nils

Moin, na gut, dann aktualisiere ich die Speicherzelle mal. Gruß, Nils

Moin, umso besser. (Wobei ich für zwei oder drei Jahre diese Größenordnung im Kopf habe - du meinst pro Jahr, oder?) Hauptsächlich meine ich auch: Das bisschen Geld, das man sparen könnte, wiegt die Umstände nicht auf. Gruß, Nils

Moin, gib 300 Euro für ein TLS-Zertifikat aus. Gruß, Nils

Moin, soweit ich weiß, hat sich an der Situation nichts geändert: Microsoft empfiehlt minimal 128 GB, das ist aber keine Supportgrenze. Bis zu welcher RAM-Untergrenze Microsoft Support leistet, scheint immer noch undefiniert zu sein. Hat Exchange 2019 weniger als 128 GB RAM zur Verfügung, dann deaktiviert es einige Optimierungen, weil diese nur mit viel RAM Sinn ergeben. Diese Optimierungen sind nach meiner Kenntnis (habe die Details nicht im Kopf) aber welche, die man ohnehin nur in sehr großen Umgebungen braucht. Nach allem, was man hört, läuft Exchange 2019 genauso gut wie Exchange 2016 mit identischer Ausstattung. Gruß, Nils

Moin, die Datacenter Edition umfasst Lizenzen für beliebig viele VMs mit Windows Server, die auf der Hardware laufen. Sofern die Hardware also korrekt lizenziert ist, müssen die VMs oder ihre Cores nicht noch mal separat lizenziert werden, CALs, egal ob Device CAL oder User CAL, braucht man nur einmalig, sie decken den Zugriff auf alle Windows-Server des Unternehmens ab (selbe Version oder ältere Version). Bei 200 Geräten also 200 CALs, unabhängig von der Serverzahl. Gruß, Nils PS. In Foren bekommst du immer nur unverbindliche "Laien"-Antworten. Wenn du es "eindeutig" haben willst, musst du den Lizenzgeber fragen, keine Dritten,

Moin, in dem Fall könnte sowas wie Bitlocker interessant sein. Wie gesagt, es kommt auf das Szenario an. Gruß. Nils