cj_berlin

Also ein wenig PowerShell lernen solltest Du schon selber. Was sagt denn die Suchmaschine Deines Vertrauens zu "PowerShell sortieren" ?

Hier funktioniert der exakte Code (natürlich mit $ am Anfang)

In meiner ERSTEN Antwort in diesem Thread steht ein Codeblock. Den habe ich um die CSV-Ausgabe ergänzt. Das ist auch der einzige Codeblock, den ich in diesem Thread gepostet habe.

Nein, ich habe den Code doch für Dich fertig ergänzt

Moin, Export/Import oder Live Migration, wenn Shared Storage vorhanden ist. Ob zwischen 12 und 22 Export/Import funktionieren wird, habe ich noch nicht ausprobiert. Neue VM mit alter VHDX ist die letzte (aber durchaus legitime) Maßnahme.

Moin, in beiden Varianten machst Du am Ende | Export-CSV -Path <Pfad> -Delimiter ',' -NoTypeInformation Aber ich ergänze mal den obigen Code um eine Sammlung. EDIT: Code inklusive CSV-Ausgabe ist drin. Wenn Du möchtest, dass die CSV in Excel mit Doppelklick aufgeht, musst Du den Delimiter auf ';' setzen.

So isses. Auch die angezeigte Geschwindigkeit auf einem LBFO-Team-vSwitch hatte nur entfernt etwas damit zu tun, wie schnelle die physischen NICs waren.

Funktional schon Und es erschließt sich aus Deinem Code für den Laien vermutlich auch besser, was der Code wo tut. Aber: ich habe hier eine Datei mit 100k Zeilen für insgesamt 1000 Hostnames, also quasi real-world data aus einem mittelständischen Unternehmen. Mein obiger Code war damit in unter zwei Sekunden fertig. Dahingegen hat auf demselben Rechner allein der Part mit Select -Unique 30-40 Sekunden in Anspruch genommen. Hier mit Hard Facts:

@testperson Das würde funktionieren, wenn Import-CSV das Timestamp-Feld als [datetime] importieren würde. Da es aber ein String bleibt, ist '01.01.2021 12:30' < '12.12.1999 13:45' Mein Vorschlag wäre $data = Import-CSV C:\temp\machines.csv $lastTS = @{} $output = @{} for ($i=0; $i -lt $data.Count; $i++) { $curHostname = $data[$i].Hostname $curTS = $data[$i].Timestamp -as [datetime] if ($lastTS.ContainsKey($curHostname)) { if ($lastTS[$curHostname] -lt $curTS) { $lastTS[$curHostname] = $curTS $output[$curHostname] = $i } } else { $lastTS.Add($curHostname, $curTS) $output.Add($curHostname, $i) } } $outputSorted = New-Object System.Collections.Generic.List[PSObject] foreach($i in $output.Values) { $outputSorted.Add($data[$i]) } $outputSorted | Export-CSV -Path c:\temp\machines-sorted.csv -Delimiter ',' -NoTypeInformation Vermutlich ließe er sich bei sehr großen Datenmengen nochmal optimieren, aber er dürfte schneller sein als alles, was mit der Pipe und Sort-Object arbeitet.

Moin, brauchst Du die Einträge hinterher zwingend in der gleichen Reihenfolge oder ist es egal?

Moin, das ist ein altes Problem. Lege die DB an, ohne sie zu mounten, hol Dir einen Kaffee und dann mounte sie.

Moin, ja, indem die Kollegin den Termin regulär in ihrem eigenen Kalender erstellt und den Vorgesetzten sowie die geplanten Teilnehmer dazu einlädt Und dann kann sie ihre Rechte im Kalender des Vorgesetzten dafür verwenden, die Einladung in seinem Namen anzunehmen. Zu Deiner Referenz: Outlook-Stellvertretung: Full Access mit keinen Send* Rechten: Full Access mit Send As: Keine Postfachrechte, nur Vollzugriff auf Kalender:

Moin, nein, Du musst nicht alle physischen Cores lizenzieren. Du musst die vCPUs lizenzieren und, sofern Du SA abgeschlossen hast, bist Du durch. Wenn Du keine SA abschließt, musst Du mit technischen Mitteln verhindert, dass die VM häufiger als alle 90 Tage den Host wechseln kann. Der von Dir zitierte Passus ist quasi die Umkehrung von Multithreading - ich wüßte nicht auf Anhieb, welcher Hypervisor das macht, und Hyper-V macht es bestimmt nicht.

Ja, clientseitig auf einem Stand zu bleiben, den diese Serverversion noch unterstützt, wie Du auch selber festgestellt hast. Und wenn dann auch die Outlook-Version N+2 aus dem Support ist, weißt Du, dass die Stunde geschlagen hat und Du auch nicht mehr wirst migrieren können, weil es keinen unterstützten Migrationspfad mehr gibt, außer Cross Forest mit Third Party-Tools.

Ja, aber es ist nicht gottgegeben. Und der Lösungsansatz kann nicht sein, dass der Endkunde die ganze Maschine tauschen muss, sondern der Hersteller ist in der Pflicht, seinen Shit sicherer zu machen. Wenn deren Laser den Strahlenschutzanforderungen nicht mehr entsprechen, bessern sie ja auch nach. Warum die IT-Sicherheitsanforderungen hier anders behandelt werden sollen, ist mir unklar. So eine Industrie-Maschine läuft 15 Jahre und wird auf maximal 11 Jahre abgeschrieben. Vor 11 Jahren war das SMB1-Thema schon ein alter Hut. Und wenn euch vor 15 Jahren jemand Windows NT verkauft hat, ist es nicht mehr nur grob fahrlässig. Und ja, ich weiß, dass es in der Praxis überall so ist. Aber wie Mark Minasi in "the software conspiracy" schrieb, nur die Kunden können das ändern, denn die Hersteller haben kein Incentive dazu.

Ja, aber sie ist eher langfristig ausgelegt. Dem Hersteller der Anwendung, die SMB1 verwendet, so lange in den A**** treten, bis das endlich gefixt wird. Ansonsten, wenn es "sicher" sein soll: SMB1-Zugriffe auf ein VLAN begrenzen, und alle Systeme, die diesen Zugriff wirklich brauchen, sollen ein Bein in diesem VLAN haben, und möglichst nur dort. Jetzt wirst Du sagen: Das sind aber alle Clients Dann hast Du verloren. Eine VM, außerhalb der Domain, möglichst als SAMBA - je mehr Halbmaßnahmen man übereinander häuft, desto schwieriger wird es zu debuggen, wenn etwas schief läuft.

Moin, die "händische Variante" lässt sich durchaus skripten: Du gehst alle Unterschlüssel von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList durch und setzt in jedem den Wert "State" auf 0. Aber in meiner Erfahrung ist die Ausschussquote hier minimal.

Teams ist ein schwieriger Fall. Der Service entwickelt sich feature-mäßig so rasant, dass selbst der Gedanke einer "LTSR-Edition" des Clients, die nicht alle Features hätte, dafür aber fix installierbar wäre, vermutlich häufigere Updates bedeuten würde als einem lieb ist. Ist halt "perpetual beta"-Software, auch bekannt als "agiles Development". Andererseits, nur so haben Office Apps & Services MVPs genug zum Bloggen Warum allerdings jeder andere Mist unbedingt über den Store und somit im User-Kontext verteilt werden muss, obwohl er alle Jubeljahre mal Updates erfährt, frage ich mich auch jedes mal. Windows Terminal, zum Beispiel.

Hatte ich vor zwei Wochen, Landesbehörde. Und selbst da hat es einer geschafft, sich innerhalb von 20 Minuten nicht einwählen zu können.

Moin, welche Rollen sind denn bereits auf dem Server installiert? Wenn da Routing & RAS drauf ist, bindet es in manchen Konstellationen auch an den DNS-Port.

Moin, mit der richtigen Konfiguration ist es aber auch nicht nötig, viele Systeme ins AD aufzunehmen. Kommt immer darauf an, ob man Gott-Accounts haben möchte oder nicht. "Geht alles" beinhaltet in letzter Konsequenz immer SIEM und jemanden, der die Ereignisse dort 24x7 nahezu in Echtzeit auswertet, denn nur so kannst Du ein Gott-Account aufhalten. Viele einzelne systemspezifische Admins (ohne password reuse eingerichtet ) zu knacken dauert schon deutlich länger und hinterlässt auch mehr Spuren. Leider sind genau die Organisationen, die kein Geld für SIEM und SOC haben, diejenigen, welche auch kein Geld für ordentliches Configuration Management haben und deshalb das AD dafür missbrauchen, mit den bekannten Folgen.

Alternativ natürlich, falls @yoda123 keine Lust hat, PowerShell zu lernen, gäbe es auch https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/forfiles

Nur, dass es die Domain-Maschine ist, die den AV-Manager fährt

Was Norbert sagt. Das Stichwort für die on-prem-Variante ist "centralized Mailflow".

Moin, das (oder so ähnlich) sollte per "Library Sharing" möglich sein. Die DPM-Instanzen teilen sich dann aber nicht eine DB, sondern greifen auf die Datenbank des jeweils anderen DPM-Server zu. https://robertanddpm.blogspot.com/2013/11/tape-library-sharing.html