Microsoft Teams hat mir eine sicher hilfreich gemeinte Information geschickt:

Überbreite Monitore sind gerade sehr angesagt. Sie können auch sehr praktisch sein – aber man stellt schnell fest, dass die Fenster, mit denen man viel arbeitet, am besten nur einen Teil der großen Fläche einnehmen sollten und dass man sie auch immer an derselben Stelle braucht.

Hier hilft „Fancy Zones“, ein kostenloses Windows-Tool von Microsoft. Es ist Teil der so genannten „Power Toys“ (an die sich die Älteren unter uns noch von Windows 95 erinnern).

Mit Fancy Zones kann man auf dem Bildschirm ein Layout-Raster vorgeben und Fenster dort schnell anordnen.

Angepasstes Layout mit drei Spalten, das mittlere Fenster ist breiter

Das Tool bringt fertige Layout-Vorschläge mit und lässt auch eigene Anpassungen zu. Das geht schnell und intuitiv und hilft wirklich dabei, die ganzen Fenster zu bändigen.

Download bei Github (das .msi-Paket nehmen), Installation erfordert lokale Admin-Rechte.

https://github.com/microsoft/PowerToys/releases/

Vor einiger Zeit haben wir einen Tipp veröffentlicht, wie man die Gruppenrichtlinienobjekte (GPOs) einer Domäne in einzelnen Reports dokumentieren lassen kann:

[Berichte über Gruppenrichtlinien erzeugen | faq-o-matic.net]
https://www.faq-o-matic.net/2018/04/10/berichte-ber-gruppenrichtlinien-erzeugen/

Es gibt allerdings auch Situationen, in denen man nicht alle GPOs der gesamten Domäne braucht, sondern nur diejenigen in einem bestimmten OU-Zweig. Auch hier hilft die PowerShell.

Das folgende Skript gibt die Namen aller GPOs aus, die sich unterhalb einer bestimmten OU in der Domäne befinden. In der ersten Zeile gibt man diese OU in LDAP-Syntax an.

$SearchBase = 'OU=MyOU,DC=domain,DC=tld'
$GPOs = @()
$GPOsUnique = @()
$OUs = Get-ADOrganizationalUnit -SearchBase $SearchBase -Filter * 
foreach ($OU in $OUs) {
  $GPOs += $OU.LinkedGroupPolicyObjects
}
'GPOs linked in tree: ' + $GPOs.Count
$GPOsUnique = ($GPOs | Sort-Object -Unique)
'Unique GPOs linked in tree: ' + $GPOsUnique.Count 
$GPOsUnique

Und das zweite Skript geht noch einen Schritt weiter: Es erzeugt einen Report für jedes GPO und speichert diese Reports als einzelne HTML-Dateien ab. (Voraussetzung: Die RSAT-Tools müssen auf dem ausführenden Rechner installiert sein.)

$SearchBase = 'OU=MyOU,DC=domain,DC=tld'
$GPOs = @()
$GPOsUnique = @()
$OUs = Get-ADOrganizationalUnit -SearchBase $SearchBase -Filter * 
foreach ($OU in $OUs) {
  $GPOs += $OU.LinkedGroupPolicyObjects
}
'GPOs linked in tree: ' + $GPOs.Count
$GPOsUnique = ($GPOs | Sort-Object -Unique)
'Unique GPOs linked in tree: ' + $GPOsUnique.Count 

foreach ($GPO in $GPOsUnique) {
  $GPOName = ''
  $GPOName = (Get-ADObject -Identity $GPO).Name
  if ($GPOName) {
    $GPODisplayName = ''
    $GPODisplayName = (Get-GPO -Guid $GPOName -ErrorAction SilentlyContinue).DisplayName
    "Creating report for $GPODisplayName"
    Get-GPOReport -Guid $GPOName -ReportType Html -Path "$env:userprofile\Documents\$GPODisplayName.html"
  }
}

Hier ist der Download für beide Skripte:

  Get-GPOsInOUTree.ps1 (861 bytes, 239-mal heruntergeladen, letzte Änderung am 21. Februar 2020)

Am 1. Februar 2005 ist unser Blog gestartet. Die ursprüngliche Idee verfolgen wir auch weiterhin: Wir verstehen uns als nichtkommerzielle Community-Seite für technische IT-Themen und als Plattform für Autor*innen und Leser*innen. Über die Jahre haben 110 Autorinnen und Autoren weit über 1.500 Artikel beigetragen und unser Projekt zu einer wichtigen Ressource für die (deutschsprachige) IT-Community gemacht.

Vielen Dank an unser Publikum und an alle, die an unserem Projekt mitwirken!

Hier eine Auswahl von Artikel, die einen Rückblick auf unsere Historie geben:

[5 Jahre faq-o-matic.net: Ein technischer Rückblick | faq-o-matic.net]
https://www.faq-o-matic.net/2010/01/04/5-jahre-faq-o-matic-net-ein-technischer-rckblick/

[FAQ für faq-o-matic.net | faq-o-matic.net]
https://www.faq-o-matic.net/faq/

[Umfrage zum 1000. Artikel: Die Ergebnisse | faq-o-matic.net]
https://www.faq-o-matic.net/2014/01/20/umfrage-zum-1000-artikel-die-ergebnisse/

[Dank an unser Publikum für die warme Dusche! | faq-o-matic.net]
https://www.faq-o-matic.net/2011/12/28/dank-an-unser-publikum-fr-die-warme-dusche/

[Blog-Statistik | faq-o-matic.net]
https://www.faq-o-matic.net/kategorien/faq-o-matic-net/blog-statistik/

Nun ist der neue Edge da, Microsofts jüngster Versuch, einen eigenen Browser auszuliefern. Anders als geplant, zunächst ohne automatisches Update, aber manuell installierbar.

Hat man den neuen Edge nun installiert, möchte man (wie ich) vielleicht, dass neue Browser-Tabs nicht mit irgendwelchen “Nachrichten” nerven. Der Weg dahin ist etwas versteckt, obwohl er sogar direkt von der Startseite aus erreichbar ist.

Auf der Startseite nämlich klickt man auf das Zahnrad oben rechts, wählt dann “Benutzerdefiniert” und dann unten “Inhalt aus”. Das war’s. Geht mit oder ohne Hintergrundbild.

Mit “Inhalt” meint Microsoft wirre Nachrichten, die der Edge einfach so anzeigt.

Wenn man eine Virtuelle Maschine (VM) im Hyper-V-Manager oder per PowerShell löscht, dann entfernt Hyper-V diese aus seiner Konfiguration, lässt die zugehörigen virtuellen Festplatten aber im Dateisystem. Das ist praktisch, falls man eine solche VM später noch einmal verwenden möchte, denn ihre Daten und der wichtigste Teil ihrer Konfiguration (nämlich das VM-Betriebssystem) bleiben so erhalten.

In manchen Situationen ist es aber hinderlich, dass die “äußere” Konfiguration der VM beim Löschen verschwindet. Dazu gehören die virtuellen CPUs, die RAM-Konfiguration und die virtuellen Netzwerkkarten, aber auch die eindeutige ID der VM. Zwar kann man diese “VM-Hülle” meist recht schnell neu erzeugen, aber auch das hat Nachteile. So entstehen dabei etwa neue virtuelle Netzwerkkarten, die das vorhandene VM-Betriebssystem neu einrichtet, wodurch die vorhandene IP-Konfiguration unwirksam wird.

Eine Abhilfe bestünde darin, eine solche VM vor dem Löschen zu exportieren. Den so erzeugten Export kann man später wieder importieren oder schlicht registrieren. Dadurch arbeitet die betreffende VM wieder wie vorher. Der Nachteil: Das ist ein wenig umständlich, außerdem ändern sich dadurch evtl. Speicherpfade.

Während man also eine vorhandene VM (die z.B. einfach komplett im Host-Dateisystem kopiert wurde) einfach registrieren kann, fehlt das Gegenstück, das “Ent-Registrieren”. Hier hilft ein kleines PowerShell-Skript, das die Konfigurationsdaten der VM vor dem Löschen sichert und sie danach wieder in den vorgesehenen Ordner zurück kopiert.

$VMName = Read-Host 'Enter VM name'
# get VM data
$VMData = Get-VM $VMName -ErrorAction SilentlyContinue
if (!$VMData) {
  "VM $VMName not found."
  Return
}
# get config folder
$VMConfLoc = $VMData.ConfigurationLocation

# save VM metadata
$VMBackupLoc = $VMConfLoc + '\_VMConf\'
Copy-Item -Path ($VMConfLoc + '\Virtual Machines') -Destination $VMBackupLoc -Recurse

# remove the VM
Remove-VM -Name $VMName -Force

# restore VM metadata
Copy-Item -Path ($VMBackupLoc + '*') -Destination ($VMConfLoc + '\Virtual Machines') -Recurse

# remove the backup folder
Remove-Item $VMBackupLoc -Recurse

"$VMName successfully unregistered." 
"Find its configuration data at $VMConfLoc"

Hier der Download:

  Unregister-VM.ps1 (480 bytes, 560-mal heruntergeladen, letzte Änderung am 20. Dezember 2019)

Wer dieser Tage versucht, den beliebten Texteditor Notepad++ über seine Update-Funktion zu aktualisieren, wird wahrscheinlich auf Probleme stoßen. Der Download funktioniert auf diesem Wege nicht.

Der Entwickler der Software gibt auf seiner News-Seite einen Hinweis auf die wahrscheinliche Ursache. Die letzten beiden Versionen hat er mit einem Namen versehen, der sich auf den Uiguren-Konflikt in China bezieht. Das habe zu DDOS-Attacken geführt. Hier wird der Grund für die Update-Probleme zu suchen sein.

Ein manueller Download über die Webseite funktioniert. Die herunterzuladende Datei scheint aktuell nicht manipuliert zu sein.

Um in einem klassischen Windows-Batch ein Kommando für alle Domänencontroller der aktuellen Domäne auszuführen, eignet sich folgender Code:

for /f "skip=2" %%a in ('netdom query dc^|find /V "."') do @echo %%a

Dieser Code bereinigt die Ausgabe von “netdom query dc” um alles, was kein Domänencontroller-Name ist. Versucht man das direkt in der Kommandozeile, gibt man nur jeweils ein Prozentzeichen an:

for /f "skip=2" %a in ('netdom query dc^|find /V "."') do @echo %a

Statt @echo %%a füge man das Kommando ein, das man für jeden DC-Namen ausführen möchte. Ein Ping ginge dann in einem Batch z.B. so:

for /f "skip=2" %%a in ('netdom query dc^|find /V "."') do (@ping -n 1 %%a)

Nir Sofer, Autor zahlreicher wichtiger Admintools für Windows, hat auf unseren Hinweis hin einen Fehler in seinem Eventlog-Manager FullEventLogView behoben. Der Bug verhinderte es, per Kommandozeile die Ereignisprotokolle eines anderen Rechners zu exportieren.

In der neuen Fassung v1.38 ist der Fehler behoben. Damit ist es jetzt (wieder) möglich, Ereignisse aus den Windows-Eventlogs von einem Remote-Rechner über die Kommandozeile in eine CSV-Datei zu exportieren. Dies klappt mit einem Kommando nach folgender Art:

FullEventLogView.exe /scomma "c:\some\path\file.csv" /datasource 2 /computername SERVER007

Hier geht es zum Download:

[FullEventLogView – Event Log Viewer for Windows 10 / 8 / 7 / Vista]
http://www.nirsoft.net/utils/full_event_log_view.html

Komischerweise nehmen die Missverständnisse über die CPU-Belastung durch Virtualisierung deutlich zu, seit die CPUs mit Kernen nur noch so um sich werfen. Daher hier noch mal ausdrücklich:

• Es ist generell überhaupt kein Problem, die CPU eines Virtualisierungs-Hosts zu überbuchen. Ganz im Gegenteil: Genau dafür ist Virtualisierung da.
• Eine CPU kümmert sich auch ohne Virtualisierung nie nur um eine Aufgabe, sondern schaltet ständig zwischen Aufgaben hin und her. Ob es sich dabei um verschiedene Programme innerhalb eines Betriebssystems handelt oder um verschiedene Programme innerhalb mehrerer Betriebssysteme, ist der CPU am Ende egal.
• „Gängige“ Anwendungen lasten eine CPU (oder auch einen Kern) niemals auch nur ansatzweise aus. Dadurch ist die CPU statistisch gesehen fast immer im Leerlauf. 
• In der Praxis ist eine CPU-Überbuchung von 10:1 fast nie ein Problem. Auch eine Überbuchung von 20:1 kann durchaus funktionieren. Heißt: Ein Beispiel-Host habe 8 Cores, dort laufen 40 „gemischte“ VMs, die jeweils 2 Cores haben (Verhältnis 10:1). Mit großer Wahrscheinlichkeit wird die CPU nicht der Engpass sein. (Wahrscheinlich wird man vorher feststellen, dass das RAM nicht reicht.)
• Ein Verhältnis von 5:1 (also: fünf vCPUs zu einem physischen Core) ist als generelle Richtlinie üblich, dabei bleiben für “allgemeine” Anforderungen noch genügend Reserven.
• Wenn die VMs (einzelne oder alle) wirklich höhere Anforderungen stellen (Terminalserver, stark belastete Datenbankserver usw.), kann mehr Designaufwand erforderlich sein. Selbst dann ist in den meisten Fällen aber noch eine CPU-Überbuchung möglich.
• Ein 1:1-Verhältnis zwischen physischem Core und VM-CPU ist technisch praktisch nie erforderlich.