NilsK

Moin, wobei das ja auch nicht besonders schwierig ist. Kriegt man zur Not sogar per Batch hin: Auslesen der Mappings - net use liefert die Informationen; in Powershell etwa Get-PSDrive -PSProvider FileSystem | where { $_.DisplayRoot -like '\\*'} UNC-Pfade isolieren (in PowerShell die DisplayRoot-Eigenschaft der obigen Objekte) Alten String durch neuen ersetzen Wenn UNC-Pfad den alten String enthält: Trennen und mit neuem Pfad neu mappen Gruß, Nils

Moin, man könnte jetzt auch noch darüber philosophieren, ob der Zwang zum regelmäßigen Kennwortwechsel überhaupt zur Sicherheit beiträgt ... Gruß, Nils

Moin, auf die Interpretation kommt es sowieso an. Eine CPU kann nur zu 100 Prozent oder gar nicht ausgelastet sein, weil sie entweder was tut oder nicht. Jeder Counter betrachtet ein Zeitintervall. Gruß, Nil"Erbsenzähler"s

Moin, wenn überhaupt Richtlinien zur Sperrung, dann mit hoher Schwelle und mit paralleler Einführung von Fine-grained Password Policies für Service- und Adminkonten. [DOS-Angriff für jedermann: AD-Konten sperren | faq-o-matic.net] http://www.faq-o-matic.net/2013/08/07/dos-angriff-fr-jedermann-ad-konten-sperren/ Gruß, Nils

Moin, mangels Glaskugel kann ich nicht sagen, was Zabbix da abfragt. Generell ist "CPU-Überlastung" nichts fest Definiertes. Manche Systeme sind völllig gesund, wenn sie mehrfach am Tag eine Vollauslastung der CPU haben. Üblich ist eher, die Auslastung in Prozent anzugeben, wobei Warnungen oft dann ausgelöst werden, wenn ein hoher Grenzwert über längere Zeit überschritten wird. Den passenden Grenzwert für ein konkretes System kann man nur herausfinden, indem man es längere Zeit beobachtet und weitere Indikatoren für mögliche Überlastung damit korreliert (z.B. Beobachtungen wie Timeouts, lange Antwortzeiten usw.). Gruß, Nils

Moin, das musst du sowieso tun, sonst gibt es ja keine HA für die VM. Den Cluster könntest du dir dann schenken. [Hyper-V: Sind meine VMs wirklich geclustert? | faq-o-matic.net] http://www.faq-o-matic.net/2015/05/04/hyper-v-sind-meine-vms-wirklich-geclustert/ Gruß, Nils

Moin, er möchte ja ins Computerobjekt schreiben ... also entweder Berechtigungen setzen oder - was ich auch andeuten wollte - die Daten in einer separaten Datenbank ablegen. Gruß, Nils

Moin, das hat mit Switches wenig zu tun. Eine Fehlkonfiguration kann kein Switch dieser Welt korrigieren. Gruß, Nils

Moin, hm ... "Büronetz", "direkt mit der Eternus verbunden", "Gigabit" ... klingt für mich jetzt nicht nach einem Best-Practice-Design. Ich sage nicht, dass du da was falsch eingerichtet hast (dafür fehlen die Details), aber aus Erfahrung weiß ich, dass bei solchen Ad-hoc-Setups oft Konfigurationsfehler vorliegen, durch die z.B. Netzwerkpakete nicht den richtigen Weg nehmen. Zumindest solltest du da also noch mal prüfen, ob alles korrekt eingerichtet ist. Gruß, Nils

Moin, Glück gehabt - vielen Dank für die Rückmeldung! Gruß, Nils

Moin, ich würde nicht ausschließen, dass es sich hier um einen Bug in Windows Server 2016 handelt. Leider sehen wir derzeit eine ganze Menge davon. Möglich wären aber auch andere Probleme. Wie sind denn die Netzwerkanbindungen der beiden Systeme? Ist da Teaming im Spiel? Verschiedene Netzwerksegmente? ... usw. Gruß, Nils

Moin, mal abgesehen von der Frage, ob das Gesamtvorgehen so sinnvoll ist* - du kannst das Cisco-Servicekonto in eine Gruppe stecken und dieser Gruppe gezielt Schreibrechte auf die relevanten Attribute geben. * grundsätzlicher Einwand an der Stelle: Das AD ist keine Inventardatenbank. Gruß, Nils

Moin, wenn man sich den Ärger anschaut, der beim Automapping entstehen kann, dann ist das auch gut so ... Gruß, Nils

Moin, warum? Braucht ihr, um Server lokal zu administrieren, gleichzeitig volle Adminrechte auf dem AD und auf allen Rechnern der Domäne? In aller Regel ist das schlechtes Design, das auf konzeptionelle Nachlässigkeit deutet. Ich habe ein neues GPO erzeugt und die dafür vorgesehene Einstellung aktiviert. Das wird die sein, die du oben meinst. Die Änderung wird sogar in der laufenden Session aktiv, sobald das GPO aktiviert wird. Für alle Domänen-User einschließlich der Domänen-Admins. Warum sollte sie auch nicht, solange man die Anwendungsberechtigungen des GPO nicht manipuliert? Gruß, Nils

Moin, Windows-Server fragen vor dem Shutdown ja extra noch mal nach einem Grund. Das sollte doch eigentlich ausreichen, oder? Wenn es das nicht tut, ist vermutlich auch der Shutdown per Skript schon zu riskant. Wie ich Admins so kenne, bauen sie sich dann ein Batch auf dem Desktop, das sie nur noch doppelklicken müssen, und da gibt es dann nicht mal eine Rückfrage. Organisatorische Probleme bekommt man technisch selten gelöst ... Abgesehen davon, kann ich deine Aussage gerade nicht nachvollziehen. Wenn ich in meinem Lab ein GPO mit den Einstellungen definiere, wirkt das auch für Admins. Nebenbei: Warum genau arbeiten bei euch Leute als Domänen-Admins auf Servern? Das wäre ein Punkt, den zu lösen ich relevanter fände. Gruß, Nils

Moin, der Artikel gibt sicher eine ganz nette Einführung, ist an manchen Stellen aber doch sehr naiv dargestellt. Auch unter Linux kann eine Anwendung natürlich nicht mal eben auf RAM eines anderen Prozesses zugreifen - aber dahingestellt. Wie schon gesagt - die Frage, ob ein System überlastet ist, und wenn ja, an welcher Stelle, ist nicht einfach zu beantworten. Das stellen alle nach ein paar Tagen oder Wochen fest, die anfangen, sich mit Monitoring zu beschäftigen. Spätestens, wenn man anfängt, Warnungen wegzuklicken, weil man weiß, dass in Wirklichkeit gar kein Problem vorliegt, sollte man noch mal in die Analyse gehen. ;) Gruß, Nils

Moin, was ist denn der Sinn der Übung? Willst du nur eine zweite Domäne haben, die anders heißt? Dann kann das in einer Laborumgebung OK sein - beachte aber, dass beide dieselbe ID haben, sie müssen also strikt getrennt bleiben. Außerhalb eines Labors ist das ein No-go. In der Praxis versucht man das Umbenennen von Domänen zu vermeiden. Das dokumentierte "rendom"-Verfahren funktioniert sowieso nur, wenn kein Exchange im Spiel ist, und selbst dann kann es sehr heikel sein. Man würde also, wenn es denn wirklich nötig ist, eher in eine neue Domäne migrieren. Und da das viel Aufwand ist, würde man eher schauen, ob man das denn nicht umgehen kann. Gruß, Nils

Moin, abgesehen davon, würdest du das innerhalb der VM überwachen. So eine Überwachung ist durchaus anspruchsvoll, weil man bei den meisten Indikatoren für jedes System separat erst mal festlegen muss, was denn "normal" ist (wie magheinz schon richtig andeutet). Es gibt nur sehr wenige Zähler, die simpel und eindeutig sind - eine Festplatte mit nur noch 1 GB freiem Platz ist ein Problem, aber schon eine Festplatte mit 10 Prozent freiem Platz kann völlig OK sein, wenn diese 10 Prozent etwa 500 GB sind und die Daten nicht schnell anwachsen. Gruß, Nils

Moin, näherungsweise kannst du es dir so vorstellen, technisch ist es was anderes. Gruß, Nils

Moin, um es noch mal zu sagen: iSCSI ist Storage. Storage ist nicht für Latenzen und Unterbrechungen gebaut. Unterbrechungen der iSCSI-Verbindungen können zu Datenverlusten führen. Und ja, das passiert auch wirklich und ist nichts, was nur theoretisch wäre. Und nochmal ja, das kann auch nach einem Stromausfall ganz böse ins Auge gehen. Und ein drittes Ja: Das "Einpendeln" des Netzwerks nach einer Störung ist auch etwas, was ein Storage-System gar nicht mag. Also, wäre es mein Netzwerk (und mein Exchange), nähme ich es nicht auf die leichte Schulter, ließe das nicht einfach so geschehen. Gruß, Nils

Moin, warum hängen die Server am internen Switch einer Fritzbox? Der ist nur für Heimumgebungen gedacht, ganz bestimmt nicht für Server. Eine höhere Geschwindigkeit erzielt ein NIC-Team nur, wenn mehrere parallele Datenströme vorliegen. iSCSI bindet man nicht über ein Team an. iSCSI ist Storage-Anbindung, die ist empfindlich. Wenn du daran was änderst, stell zuerst sicher, dass keine Daten zwischen Storage und Server laufen (Server herunterfahren), sonst riskierst du Datenverluste. Und auch wenn es ein kleines Netzwerk ist: Da sollte man mal die Struktur überarbeiten. Gruß, Nils

Moin, dazu kann man nichts Seriöses sagen, ohne die Infrastruktur zu kennen. "iSCSI" etwa taucht bei dir nur in einem Nebensatz auf. Generell: Wenn du Änderungen dieser Art vornehmen willst, solltest du das in einer Downtime und mit Planung machen, gerade wenn Spezialitäten wie iSCSI im Spiel sind. Einen DC bindet man eher nicht über ein Team an, sondern sorgt für Redundanz auf der Applikationsebene (= mehrere DCs) Exchange würde man sich auch noch mal separat ansehen Zu klären wäre, was mit dem Teaming denn überhaupt erreicht werden soll. Gruß, Nils

Moin, eine einfache Installation von OTRS dürfte das leisten. Wenn man will, kann man das auch unter Windows einsetzen. Linux wäre hier aber vorzuziehen. Falls die Anforderungen dann mal steigen, ist man mit OTRS immer noch richtig bedient. Gruß, Nils

Moin, macht ja nix. Ich weise vor allem deshalb darauf hin, damit der TO nach den richtigen Begriffen suchen kann bzw. weiß, welche Begriffe evtl. unpassende Ergebnisse bringen. Gruß, Nils

Moin, äh ... ich verstehe noch nicht so ganz, wo das hinsoll. Ein Standard-Gateway hat ein Rechner normalerweise nur einmal, denn es gibt ja an, wohin Traffic geroutet werden soll, der keine dedizierte Route hat. Warum gibt es in der aktuellen Konfiguration überhaupt zwei Standard-Gateways? Normalerweise warnt Windows bei sowas doch. Wenn es dedizierte Routen geben soll, ist das gerade kein Fall für ein Standard-Gateway, sondern für die Routingtabelle. Also am besten noch mal beschreiben, was genau das Ziel ist. Und am besten auch, wieso der Rechner so konfiguriert ist wie oben beschrieben. Gruß, Nils