NilsK

Moin, wenn der Server "von selbst" neu startet, dann gab es einen Bluescreen. Das wiederum heißt: entweder ein Treiberfehler oder ein Hardwareproblem. Das NAS selbst hat damit nicht zu tun, die AD-Replikation auch nicht. Was ist denn das für eine Backupsoftware? Gruß, Nils

Moin, das ist so nicht vorgesehen. "Dieses Teams" gibt es nicht, weil es keine Mailbox ist, sondern eine ganze Reihe verschiedener Daten und Dienste. Teams ist am Ende nur ein Client, der den Zugriff auf diese sehr verschiedenen Daten und Dienste ermöglicht. Ich weiß nicht, um was für eine "Regelung" es sich da handeln könnte, aber möglicherweise geht diese von einer falschen Vorstellung der Zusammenarbeit in modernen Plattformen aus. Gruß, Nils

Moin, vorweg: GUIs sind nicht die Stärke der PowerShell, eigentlich hat PowerShell einen Automatisierungsfokus. Ohne die Technik, die du da einsetzt, näher zu kennen und ohne lange analysiert zu haben, würde ich vermuten, dass du hier in eine Scope-Falle gelaufen bist. Deine Objekte $Auswahlfeld und $Auswahlfeld2 sehen mir so aus, dass sie nur im Scope des jeweiligen Blocks existieren. Der Block $Option1 kennt also nur das $Auswahlfeld2, aber nicht das $Auswahlfeld, entsprechend im anderen Block. Hab's jetzt mal geprüft, das dürfte so sein. Diese Ergänzung des Codes illustriert das: $Option1.Add_Click({ $Auswahlfeld2=New-Object System.Windows.Forms.Listbox $Auswahlfeld2.SelectionMode="One" $Auswahlfeld2.Height=150 $Auswahlfeld2.Width=150 $Auswahlfeld2.Location =New-Object System.Drawing.Point(500,50) Write-Host 'Option1' Write-Host "Auswahlfeld2: $Auswahlfeld2" Write-Host "Auswahlfeld: $Auswahlfeld" $Abfrage.Controls.Add($Auswahlfeld2) $Abfrage.Controls.Remove($Auswahlfeld) }) $Option2.Add_Click({ $Auswahlfeld=New-Object System.Windows.Forms.Listbox $Auswahlfeld.SelectionMode="One" $Auswahlfeld.Height=150 $Auswahlfeld.Width=150 $Auswahlfeld.Location =New-Object System.Drawing.Point(300,50) Write-Host 'Option2' Write-Host "Auswahlfeld2: $Auswahlfeld2" Write-Host "Auswahlfeld: $Auswahlfeld" $Abfrage.Controls.Add($Auswahlfeld) $Abfrage.Controls.Remove($Auswahlfeld2) }) Gruß, Nils

Moin, die Frage habe ich nicht verstanden. Bitte formuliere noch mal sorgfältig, was du erreichen willst. Gruß, Nils

Moin, In dem Fall wird sehr wahrscheinlich die Überbuchung nach hinten losgehen. Wo keine Ressourcen sind, kann man auch keine zuweisen. Gruß, Nils

Moin, Ich stimme zu, dass die generellen Betrachtungen aus meinem Artikel für VDI in allen seinen Geschmacksrichtungen nicht oder nur sehr begrenzt zutreffen. Daneben stimme ich aber auch der Beobachtung zu, dass man in der freien Wildbahn unglaublich viel Murks in den Konfiguratoren antrifft.. Und ich wage weiterhin zu behaupten, dass man bei "allgemeinen" Konfigurationen die CPU deutlich stärker auslasten kann, als es oft geschieht. Gruß, Nils

Moin, ich sekundiere mal Dukel und ergänze: Wenn du bei dem Intranet vermutest, dass Lesezugriffe das Problem sind, dann wird sich daran ziemlich sicher was ändern lassen. Typischerweise fehlen dann Indizes in der Datenbank. Oder die Abfragelogik der Applikation ist schlecht gebaut. Gruß, Nils

Moin, oha, ich wollte dir nicht auf den Fuß treten. Der Hinweis war hilfreich gemeint - die Logik des Beispiels hat ihre Grenzen. Da hier ja auch Leute lesen, die das nicht sofort sehen, finde ich das wichtig, weil man sonst vielleicht in eine Falle tappt. Für das Beispiel aus Sicht der Einbindung in Check MK wäre noch wichtig zu wissen, ob die Zahlenwerte am Anfang der Meldung (0, 1, ...?) eine festgelegte Bedeutung haben oder wahlfrei sind. Und ob es reicht, dass diese als Text ausgegeben werden. Gruß, Nils

Moin, und vier oder mehr User gibt es nicht? Das Skript gibt dann jedenfalls nix mehr zurück. Gruß, Nils

Moin, mein eigentlicher Punkt war, dass du für die beiden betrachteten Fälle nicht mal SSDs brauchst. Wenn du sie übrig hast, nimm sie. Aber für sowas müsste man keine kaufen. Gruß, Nils

Moin, man kann sogar noch weiter gehen. Weder der Host (die Parent Partition) noch ein DC brauchen schnelle Plattensysteme. Und ein DC braucht keine besondere Hardwareredundanz, weil die Applikation die Redundanz bereitstellt. Gruß, Nils

Moin, ich ergänze mal, weil man das wissen sollte: Ich sehe mittlerweile immer öfter, dass Outlook-Benutzer genau wegen dieser Darstellung Termine nicht mehr annehmen. Sie sehen die im Kalender und unterscheiden selbst gar nicht mehr zwischen "unter Vorbehalt" (weil ich nur eingeladen wurde) und "zugesagt" (ich habe auf "Annehmen" geklickt). Dadurch ist es für andere dann nicht mehr nachzuvollziehen, ob derjenige nun an einem Termin teilnimmt oder nicht. Ganz ohne den Benutzer wird es hier also auch nicht gehen. Gruß, Nils PS. oder wie andere sagen würden: Es gibt keine vollständigen technischen Lösungen für organisatorische Probleme.

Moin, ja, so ist das eben. Wir neigen dazu, Fragen ernst zu nehmen und schauen deshalb auch gern mal hinter die Kulissen. Ich verstehe die Dienstleisterzwänge, auf die du verweist, nach 25 Jahren als IT-Dienstleister durchaus. Trotzdem darf man auch als IT-Dienstleister mal auf Zusammenhänge hinweisen und sollte nicht den Eindruck erwecken, durch Technik lasse sich alles lösen. Das Argument, das du hier anführst, ist doch nur vordergründig eins. In dem Szenario würde es innerhalb von Minuten auffallen, dass Mitarbeiter A der Schuldige ist. Und da er bei einem Anwalt arbeitet, würde er das mit großer Sicherheit nicht wiederholen. Exchange hat seine Grenzen. Für spezielle Anforderungen gibt es andere Lösungen. Zu dieser Einsicht gehört aber, wie gesagt, aus meiner Sicht auch, die Dinge einzuordnen. Gruß, Nils

Moin, Unnötiger Aufwand. Ein restore zieht fast immer Sachen nach sich, die man nicht im Blick hatte. Und du hast oben ein paar Dinge erwähnt, die ich nur im Notfall machen würde. Der liegt hier aber nicht vor. Gruß, Nils

Moin, das könnte er natürlich tun, aber warum sollte er? Diese Befürchtung ist doch nicht praxisgerecht. Gruß, Nils

Moin, Norbert hat Recht. Keine Experimente mit einem DC, wenn es noch einen anderen gibt. Gruß, Nils

Moin, Ja, sehe ich auch so. Trotzdem ist es wichtig zu wissen, dass man sich um die Logs kümmern muss, sobald man auf Full stellt. Wenn die Backup-Software das tut, prima, aber man sollte nicht einfach davon ausgehen. Gruß, Nils

Moin, das habe ich auch jahrelang gedacht und behauptet. Das ist aber nicht so. Mindestens das eingebaute Backupsystem lässt bei einem Full Backup die Logs in Ruhe. Man muss sich separat drum kümmern. https://www.sqlservercentral.com/forums/topic/does-a-full-backup-truncate-the-log Gruß, Nils

Moin, Welcher Unterschied der Dateien? Robocopy wird für Migrationen sehr oft eingesetzt. Die Downtime kann man nahe Null halten, indem man vorsynchronisiert und dann am Ende nur noch ein kleines Delta abgleichen muss. Von Stunts mit Spiegeln würde ich Abstand nehmen. Gruß, Nils

Moin, also, wenn du den Aufwand reduzieren willst, dann an sinnvoller Stelle. Da käme für mich nur etwas weiter vorne im Ablauf in Frage. Wenn du bei der CSV-Verarbeitung bleiben willst, dann nimm die Datei, die möglicherweise kaputt ist, entferne die möglicherweise kaputten fünf Zeilen und speichere sie wieder ab. Wenn du nur so sichergehen kannst, dass der CSV-Import über das Cmdlet funktioniert (das nun mal eine ordentliche Datei erwartet, dafür aber auch Vorteile bietet), dann würde ich an der Stelle nicht weiter rummachen. Dein Skript kann dann ja am Ende auch noch aufräumen. Du schreibst hier ja schließlich ein Skript und keine ERP-Anwendung. Gruß, Nils

Moin, was uns zum Anfang zurückführt ... lässt sich der Umweg über CSV, vielleicht sogar der über Excel vermeiden? Falls nicht, dann ist es vielleicht wirklich am einfachsten, die Importdatei erst zu korrigieren und dann zu verarbeiten. Gruß, Nils

Moin, der Grund ist, dass mit Anführungsstrichen der Inhalt eines einzelnen Feldes begonnen wird, falls sich innerhalb des Feldes Trennzeichen befinden. Das Import-Cmdlet sieht nun also das "öffnende" Anführungszeichen, sucht das schließende und behandelt alles dazwischen als ein einziges Feld. Wenn es kein schließendes Zeichen gibt, läuft das Cmdlet vermutlich auf einen Fehler. In beiden Fällen importiert das Cmdlet aber die Datei nicht so, wie es gewünscht ist. Wie Evgenij richtig zusammenfasst, erfüllt deine CSV-Datei damit nicht zuverlässig die Bedingungen für einen erfolgreichen Import. Und nun siehst du, warum wir nach dem Hintergrund fragen ... Gruß, Nils

Moin, gut, zu deinem akuten Punkt hat Olaf dir ja schon Hinweise gegeben. Aber deine Schilderung illustriert schön, was ich meine: Ja, das ist eine typische Anforderung. Als Berater denke ich mir: Wie kommen denn die Daten in das Excel hinein? Wäre es evtl. sinnvoller, diesen Umweg einzusparen und dort, wo bislang das Excel erzeugt wird, gleich direkt das LDAP zu ändern? Vielleicht ist das auch noch nicht der richtige Ansatz, aber du siehst evtl., was ich meine. Gruß, Nils

Moin, aha, es handelt sich also um eine wiederkehrende Aufgabe mit wechselnden Daten? Was geschieht damit, d.h. in welcher Art verarbeitest du das weiter? Bekommst du die CSVs direkt oder erzeugst du die selbst? Falls du die CSVs bekommst, könntest du auch die Excels direkt erhalten? Hintergrund der Fragen: Wenn wir wissen, welche Aufgabe du eigentlich lösen musst, können wir dir vielleicht besser helfen. Wir erleben immer wieder, dass wir ein Detailproblem mit jemandem lösen und hinterher feststellen, dass es viel leichter wäre, die tatsächliche Aufgabe ganz anders anzugehen. Gruß, Nils

Moin, stellen wir das Ganze doch mal auf die Füße: Was hast du denn insgesamt vor? Gruß, Nils