Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.609
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von NilsK

  1. Moin,

     

    was heißt denn 

    vor 58 Minuten schrieb Stefan_Meier:

    etliche ACLs geerbt

    ?

     

    Ich vermute mal, dass es um Gruppen geht, die irgendwo Berechtigungen haben. Falls das so ist: nein, man kann nicht rausfinden, wo die berechtigt sind. Man muss alle Pfade, Dateien oder Objekte dazu durchsuchen. Es gibt Berechtigungsmanagement-Software, die sowas macht, aber die ist erstens sehr teuer und zweitens nicht "mal eben" eingeführt.

     

    Gruß, Nils

     

    • Like 1
  2. 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

     

  3. 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

     

    • Like 1
  4. 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

  5. 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

     

  6. Moin,

     

    ich ergänze mal, weil man das wissen sollte:

     

    vor 48 Minuten schrieb NorbertFe:

    Termine werden je nach Konfiguration im OUtlook dann als Tentative (unter Vorbehalt) im Outlook des Notars hinterlegt.

    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.

  7. Moin,

     

    vor 45 Minuten schrieb LukiHoer:

    ich liebe diese Diskusionen in IT-Foren ;) deshalb habe ich mich angemeldet.

    ja, so ist das eben. Wir neigen dazu, Fragen ernst zu nehmen und schauen deshalb auch gern mal hinter die Kulissen.

     

    vor 46 Minuten schrieb LukiHoer:

    Wenn Mitarbeiter A dem sachbearbeitenden Mitarbeiter B einen reinwürgen möchte und Druck ausüben möchte weil ihm oder ihr ein f*** quer hängt, ist das nicht nur denkbar sondern wurde in der Praxis schon durchgeführt.

     

    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

     

  8. 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

     

     

     

  9. Moin,

     

    vor 3 Minuten schrieb Squire:

    Normalerweise schneidet jede halbwegs vernünftige und für SQL Server geeignete Sicherungssoftware die Transaction Logs nach dem Backup ab, sodass ein manuelles Verkleinern nicht nötig ist. 

    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

     

  10. 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

     

×
×
  • Neu erstellen...