NilsK

Moin, dann läuft da was falsch. Bei einem DC oder einem SQL Server verändert sich ja nix, was eine laufende Indizierung beschäftigen würde. Gruß, Nils

Moin, worin liegt denn das Problem, wenn die User "im Web surfen"? Kann man das im Zweifel einfach ignorieren oder gibt es einen handfesten Grund, das zu vermeiden? Gruß, Nils

Moin, ich merke noch an, dass gerade "jede Menge spezielle, über die Jahre von -zig Stellen installierte Komponenten" regelmäßig dafür sorgen, dass ein Inplace-Upgrade nicht wie gewünscht funktioniert. Aber wir wollen natürlich niemanden daran hindern, seinen Erfahrungsschatz zu vergrößern. Gruß, Nil"inplace upgrades on servers are evil"s PS. Wenn du so viel Zeit hast, das zu diskutieren ... die hätte man ja auch investieren können, um ... na, du weißt schon.

Moin, ich ergänze noch mal dazu, dass Windows-NLB eine Technik aus dem letzten Jahrtausend ist (ernsthaft, das ist Ende der Neunziger entwickelt worden), die seitdem auch nicht nennenswert weiter entwickelt wurde. Die hat noch nie gut funktioniert, wird das nie tun, und weil das so ist, wird man auch niemanden finden, der das ernsthaft supporten kann. Die Alternativen, die hier genannt wurden, sind allemal besser und amortisieren sich wahrscheinlich schon ab Woche 1. Gruß, Nils

Moin, Es kann sein, dass du in den Logs was findest, es kann auch nicht sein. Probleme dieser Art würden sich am ehesten in den Standard-Protokollen niederschlagen, also System oder Applikation. Bei einem Terminalserver kommen bei solchen unklaren Problemen aber zahlreiche Ursachen in Betracht, da kann es schon etwas dauern, bis man die Lösung findet. Wenn es nach einem Neustart wieder geht, heißt das noch lange nicht, dass keine Updates fehlen bzw. Updates das Problem nicht lösen können. Es lohnt auf jeden Fall, danach zu suchen, auch bei den relevanten Treibern. Gruß, Nils

Moin, es trägt jetzt nicht direkt zur Problemlösung bei, aber die Kombination von Windows und WordPress ist nicht Best Practice. Da höre ich immer wieder von Problemen, die in der "nativen" Linux-Umgebung nicht auftreten. Wäre es eine Option, das mal gegenzutesten? Gruß, Nils

Moin, hm ... zumindest hab ich es so gelernt und von Windows-Security-Experten eingebläut bekommen. Da ich selbst nie ernsthaft Umgebungen betreiben musste, kann ich da auch nicht wirklich auf eigene Erfahrung zurückgreifen. Bei dem speziellen Thema Windows-DHCP-und-DNS-Integration scheint mir aber insgesamt auch einiges holpriger und anders zu laufen als dokumentiert. Gruß, Nils PS. gibt es denn auch Posts von Ace, die nicht episch sind?

Moin, wo es mir gerade auffällt: nein, eben nicht. Die Gruppe DNSUpdateProxy sollte man gar nicht mehr verwenden, die war ein Notbehelf in Windows 2000. Um deren Nachteilen abzuhelfen, wurde ja eben erst der Service-Account eingeführt (der eigentlich keiner ist). Nur diesen eintragen, die Gruppe nicht anfassen. (Hier wird das recht ausführlich diskutiert: https://learn.microsoft.com/en-us/answers/questions/574554/changing-built-in-group-scope-dnsupdateproxy.html) Nein, wie Evgenij dargestellt hat, müsste es mit den richtigen Einstellungen sogar in deinem Szenario mit langen Namen funktionieren. Gruß, Nils

Moin, typischerweise auch erheblich mehr. Siehe meine genannten Artikel ... typischerweise auch erheblich mehr. Siehe meine genannten Artikel ... In dem Fall sind 64 GB zu wenig, denn dann hat der Host nichts mehr. Es gibt keine RAM-Überbuchung in Hyper-V, und das aus gutem Grund. Gruß, Nils

Moin, dann prüfe, ob sich das RAM nachträglich in der Form erweitern lässt. Da geht es nicht nur um freie Steckplätze, sondern auch um die Module insgesamt, das kann eine Wissenschaft für sich sein. Bezüglich der Cores: Mach, was du willst, aber wenn du 8 dedizierte Cores pro VM vorsehen willst, hast du meine Artikel gründlich missverstanden. Gruß, Nils

Moin, die Hinweise zu den Kernen sind gut, da kann es durch die Windows-Lizenzen unangemessen teuer werden. Zum RAM: Wieviel RAM haben denn die physischen Server derzeit? Wenn das ausreicht, ohne dass es auf Engpässe hinweist, ist das ein Indikator dafür, wieviel RAM die VMs bekommen sollten. Die 64 GB hören sich erst mal viel an und können für SQL und TS auch dicke ausreichen. Wenn dann aber künftig die drei anderen VMs noch dazu sollen, könnte es wieder knapp werden. 2-4 GB solltest du "in Gedanken" für den Host abziehen, unter 2 GB wirst du auch einer "kleinen" VM (dem DC) nicht geben wollen. Ein Mailserver würde wohl eher 4 GB brauchen, und damit das Veeam ordentlich arbeitet, können 8 GB schon sinnvoll sein. Kann in 64 GB passen, kann aber auch eng werden. Am RAM würde ich nicht sparen. RAID-10 würde ich bei SSDs nicht machen, der theoretische Geschwindigkeitsvorteil wiegt den Overhead eher nicht auf. RAID-1 sollte reichen. Ob du das Host-OS wirklich separat legst in so einer Umgebung - ich würde mir auch hier den Overhead sparen und alles auf dasselbe SSD-Set legen, alles ein großes Volume und Ordner pro VM. Da bei sowas schnell ein Cluster für die Ausfallsicherheit ins Spiel kommt, plane mindestens Dualport 10-Gb ein. Mehr als 10-Gb dürfte in dem Szenario unnötig sein und auch die CPUs unnötig belasten. Falls du bei dem TS auf 2012 R2 bleiben musst, prüfe, ob das unter einem aktuellen Hyper-V noch läuft. Da bin ich grad nicht informiert. Gruß, Nils PS. ein einziger DC ist bei 12 Usern schon Unterkante. Ich würde über einen zweiten DC nachdenken, der separat auf günstiger Hardware läuft.

Moin, Bei 10 Clients könnte man auch darüber nachdenken, einfach neu anzulegen. Gruß, Nils

Moin, und die Clients? Die Frage ist ja, wie kann es zu lange Hostnamen geben. Gruß, Nils

Moin, in welchen Situationen treten denn die Meldungen auf? Ich habe das hier grad mal nachvollzogen und finde ähnliche Meldungen. Die treten z.B. dann auf, wenn der Client die Netzwerkverbindung zum internen DNS verloren hat, also etwa nach dem Trennen des VPN oder im Zug des Shutdown. Ich kann zwar jetzt nicht sagen, woher Windows dann die DNS-Serveradressen nimmt, aber es sieht mir eher "normal" und plausibel aus. Es könnte eine Art Fallback sein - der Client erreicht den vorgesehenen DNS-Server nicht und richtet seine Anfrage dann an andere, zu denen er schon mal verwiesen wurde. Windows macht sowas schon mal, vielleicht auch hier. Und dieser Server verweigert dann logischerweise das Update des Eintrags. (Nur spekuliert, ich habe das jetzt nicht näher recherchiert.) Einen Angriff vermute ich dahinter jedenfalls nicht. Gruß, Nils

Moin, vermutlich solltest du dir die Grundlagen von DHCP noch mal in Ruhe ansehen. Da scheint es mir grundlegende Missverständnisse zu geben. DHCP hat mit Domänen nichts zu tun. Dass man einen Windows-DHCP-Server im AD autorisieren muss, ist eine reine Vorsichtsmaßnahme, um es weniger wahrscheinlich zu machen, dass jemand versehentlich einen DHCP-Server im Netzwerk installiert, der dann unbeabsichtigte Adressen verteilt. Mehr nicht. Dafür ist die Autorisierung auch nicht gut geeignet, aber das steht auf einem anderen Blatt. DHCP funktioniert auf Basis von Netzwerk-Broadcasts und hat von logischen Konstrukten wie Domänen usw. keine Ahnung. Mehr als einen DHCP-Server in einem physischen Subnet zu haben, ist nur für die Ausfallsicherung interessant, aber nicht für die Strukturierung. Gruß, Nils

Moin, hast du mal die Event-ID dazu? Und Norbert hatte um Informationen zu eurer IP-Konfig gebeten. Die könnten uns helfen, das Problem einzugrenzen. EDIT: Die Adresse gehört zu ARIN, der US-amerikanischen Internet-Registry. Das spricht gegen einen Angriff. Sind auf eurem DNS-Server die Root Hints aktiviert? Gruß, Nils

Moin, ist der Domänenname evtl. ein "echter" Domänenname, der euch aber nicht gehört? siehe hier - das ist ein anderes Phänomen, könnte aber evtl. damit zusammenhängen: [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/ Gruß, Nils

Moin Smothy, du solltest nicht aufs Geratewohl irgendwas irgendwo ins AD eintragen. Du hast das auch grundlegend falsch verstanden. Norbert hatte dir exakt gesagt, wo du nachsehen kannst, um herauszufinden, ob der "problematische" DHCP-Server tatsächlich schon im AD autorisiert ist. Es ging jetzt noch gar nicht um die Lösung, wir sind noch bei der Diagnose. Also sei doch bitte so nett und schau exakt an der angegebenen Stelle nach, was dort eingetragen ist und teile uns das mit. Dann sehen wir weiter. Ach, und den manuell hinzugefügten Eintrag entferne besser wieder. So funktioniert das nicht. Gruß, Nils

Moin, aber vielleicht ist der Server tatsächlich schon autorisiert und das "Rot" liegt gar nicht daran. Was sagt denn das Ereignisprotokoll? Gruß, Nils

Moin, ah, die Meldung hatte ich noch nicht gesehen. Dann liegt das Problem woanders. Hat es früher schon mal einen Server desselben Namens gegeben? Du kannst die autorisierten Server auch irgendwo nachsehen, aber mangels Testumgebung kann ich dir grad nicht sagen, wo. Gruß, Nils

Moin, hast du dich neu angemeldet, nachdem du den Account in die Org-Admins aufgenommen hast? Gruß, Nils

Moin, Warum sind denn die Hostnamen länger als 15 Zeichen? Das ist ja eher ungewöhnlich, daher löst man das Problem eher nicht, sondern hat es gar nicht erst. Gruß, Nils

Moin, man berücksichtige dabei, dass für den Zugriff auf einen Standard-Server auch CALs für die Anwender nötig sind. Das sollte man bei dem geringen Mehrpreis mit einkalkulieren. Gruß, Nils

Moin, aha, dann kommen wir der Sache schon näher. Bitte beschreibe noch einmal genau, was dir vorschwebt, was du also erreichen möchtest. Es klingt so, als sei OneDrive für den Einsatzzweck nicht das richtige Werkzeug. Wenn wir verstehen, was die Anforderung ist, können wir dir vielleicht einen besseren Ansatz vorschlagen. Was du mit "Sicherheiten" meinst, nennt man übrigens "Berechtigungen". Es ist einfacher für die anderen, wenn du diesen Ausdruck dafür verwendest. Gruß, Nils

Moin, sorry, aber da verstehe ich das ganze Szenario nicht. Kannst du das mal anhand eines Beispiels konkretisieren, welche Daten von wo nach wo wandern und was du genau mit "die Sicherheit" meinst? Gruß, Nils