ConsoleHost_history.txt von PSReadLine mit sinnvollen Metadaten erweitern

PSReadline von Powershell speichert alle Kommandozeileneingaben von der Powershell in der Datei ConsoleHost_history.txt. Mittels

notepad (Get-PSReadLineOption).HistorySavePath

kann man ganz einfach in die gesammelten Eingaben Einblick erhalten. Dies ist manchmal sinnvoll um bestimmte Dinge nachvollziehen zu können.

Wenn man viel Zeit in der Powershell verbringt sammeln sich da viele Daten über die Zeit an. Da nie klar ist, wann eine Sitzung begann oder in welchem Kontext man sich bewegte, hier eine kleine Funktion die man aufrufen kann um den nötigen Kontext herstellen zu können:

Function HistoryDirDateTimeSyncPoint {Add-Content -path (Get-PSReadlineOption).HistorySavePath "`r`n# $env:COMPUTERNAME `"$pwd`" $(Get-Date)"}

Nun muss man nur

PS> HistoryDirDateTimeSyncPoint

aufrufen und bekommt diesen Eintrag

HistoryDirDateTimeSyncPoint

# COMPUTERNAME "C:\Users\Benutzer" 05/05/2024 18:13:30

Es wird also eine Leerzeile angefügt um optisch zu den vorhergehenden Eingaben einen Abstand zu bekommen und danach werden der Computername, der aktuelle Pfad und Datum mit Uhrzeit als Kommentarzeile eingetragen.

Obige Funktion ist in Windows Powershell 5 genauso wie in Powershell 7 verwendbar. Bei Powershell 7 funktioniert es auch unter MacOS und Linux.

Evtl. macht aber ein weiterer Parameter noch mehr Freude und zwar ob zum Zeitpunkt des Aufrufs Admin- oder Rootrechte aktiv waren. Dazu bauen wir uns diese Funktion:

Function Test-AdminOrRoot {

$root = $false

If ($PSVersionTable.Platform) {
  # Information verfügbar
  If ($PSVersionTable.Platform -eq ‚Win32NT‘) {
   # Windows
   $root = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
  } else {
   # Linux oder Mac
   $id = id -u
   If ($id -eq 0) {
    $root = $true
   } # else 501
  }
} else {
  # Information nicht verfügbar, kann nur Windows sein
  $root = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
}
 
return $root
}

Diese bauen wir nun in die andere Funktion mit ein:

Function HistoryDirDateTimeSyncPoint {

        Function Test-AdminOrRoot {

        $root = $false

        If ($PSVersionTable.Platform) {
            # Information verfügbar
            If ($PSVersionTable.Platform -eq ‚Win32NT‘) {
                # Windows
                $root = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
            } else {
                 # Linux oder Mac
                $id = id -u
                 If ($id -eq 0) {
                    $root = $true
                 } # else 501
            }
        } else {
             # Information nicht verfügbar, kann nur Windows sein
             $root = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
        }
 
         return $root
    }

    Add-Content -path (Get-PSReadlineOption).HistorySavePath "`r`n# Admin/Root:$(Test-AdminOrRoot)  $env:COMPUTERNAME  `"$pwd`"  $(Get-Date)"

}

Im MacOS Terminal kann man dann das Ergebnis mittels

open (Get-PSReadLineOption).HistorySavePath

bewundern und stellt sich ungefähr so dar:

HistoryDirDateTimeSyncPoint

# Admin/Root:True    "/private/var/root"  05/05/2024 20:19:27

bzw. mit normalen Rechten:

HistoryDirDateTimeSyncPoint

# Admin/Root:False    "/Users/Benutzername"  05/05/2024 20:18:11

Probleme mit Internetverbindung mit mehreren Netzwerkkarten und falschen Prioritäten, Ping meldet: “Die Gültigkeitsdauer wurde bei der Übertragung überschritten.” bzw. “Time to live exceeded”– kurz, wenn sich alles im Kreis dreht

Ausgangslage war eine Hyper-V-Installation auf Basis von Windows 10. Hyper-V richtet einen “Default Switch” ein. Dieser virtuelle Switch wurde schon mehrfach ohne Probleme für verschiedene VMs benutzt. Nun wurde ein neuer Hyper-V-Switch für ein Testnetz eingerichtet. Im Testnetz kamen nur zwei VMs zum Einsatz. VM1 war OpnSense mit Version 23.7. VM2 war Windows Server 2022. Die VM1 hatte zwei Netzwerkkarten zugeordnet einmal als WAN und einmal als LAN. Die VM2 hatte nur eine Netzwerkkarte die an LAN von VM1 verbunden war. Waren beide VMs aus konnte mit dem Hostsystem problemlos im Internet gesurft werden. Waren beide VMs gestartet war  nach kurzer Zeit der Zugang ins Internet auf dem Hostsystem nicht mehr gegeben. Ebenso war auf den VMs nur ganz kurz eine Verbindung ins Internet möglich.

Beim Versuch eine Internetseite aufzurufen kam von Edge diese Meldung:

Hmmm…diese Seite ist leider nicht erreichbar

Die IP-Adresse des Servers von github.com konnte nicht gefunden werden.

Versuchen Sie Folgendes:

• Proxy-, Firewall- und DNS-Einstellungen überprüfen.
• Windows-Netzwerkdiagnose ausführen

DNS_PROBE_FINISHED_BAD_CONFIG

Also irgendein Problem mit dem DNS.

Ein einfacher Test mit einem Ping brachte dieser Fehlermeldung, dabei ist 172.17.224.1 die IP-Adresse welche dem “Default Switch” auf dem Host-System zugewiesen war:

PS C:\Users\Administrator> ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.

Auch ein hochschrauben des Timeouts mittels

PS C:\Users\Administrator> ping 8.8.8.8 -i 60

brachte keine Änderung. Nun der Versuch mittels nslookup eine Antwort zu bekommen:

PS C:\Users\Administrator> nslookup
Standardserver:  OPNsense.localdomain
Address:  192.168.1.1

> google.de
Server:  OPNsense.localdomain
Address:  192.168.1.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an OPNsense.localdomain.

Obwohl der Ping an 8.8.8.8 schon nicht funktionierte wurde trotzdem mal ein tracert abgesetzt, was zu diesem interessanten Ergebnis führte:

PS C:\Users\Administrator> tracert 8.8.8.8

Routenverfolgung zu 8.8.8.8 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  OPNsense.localdomain [192.168.1.1]
  2     5 ms     6 ms     3 ms  172.17.224.1
  3     1 ms     1 ms     1 ms  OPNsense.localdomain [192.168.1.1]
  4     2 ms     1 ms     1 ms  172.17.224.1
  5     2 ms     1 ms     1 ms  OPNsense.localdomain [192.168.1.1]
  6     2 ms     7 ms     2 ms  172.17.224.1
  7     2 ms     2 ms     2 ms  OPNsense.localdomain [192.168.1.1]
  8     3 ms     2 ms     2 ms  172.17.224.1
  9     3 ms     2 ms     2 ms  OPNsense.localdomain [192.168.1.1]
10     3 ms     3 ms     3 ms  172.17.224.1
11     4 ms     3 ms     2 ms  OPNsense.localdomain [192.168.1.1]
12     4 ms     2 ms     3 ms  172.17.224.1
13     4 ms     3 ms     3 ms  OPNsense.localdomain [192.168.1.1]

D.h. die Verbindung dreht sich im Kreis!

Nach einigen Neustarts und überprüfen der Netzwerkeinstellungen wurde am Host-System geschaut, ob da alles klappt. Und siehe da, es war auch kein Aufruf mehr von Internetseiten möglich. Das auffällige am Host-System war die DNS-Suffixreihenfolge:

C:\Users\Administrator>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : HyperVHost
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : localdomain
                                       fritz.box

Ethernet-Adapter vEthernet (Default Switch):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physische Adresse . . . . . . . . : 00-15-5D-96-A6-6B
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::b711:9aff:aa98:4d94%32(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.17.224.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.240.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 536876381
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (OpnSenseNetzwerk):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-5C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::ad:802c:9657:2eaf%13(Bevorzugt)
   IPv4-Adresse (Auto. Konfiguration): 169.254.252.98(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 805311837
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (KundeTestNetz):

   Verbindungsspezifisches DNS-Suffix: localdomain
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-74
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::fb91:31ae:c923:8c31%22(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.102(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 11:19:47
   Lease läuft ab. . . . . . . . . . : Montag, 4. September 2023 02:19:48
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 620762461
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (Controller der Familie Realtek PCIe GBE Virtual Switch):

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Hyper-V-Adapter – virtuelles Ethernet #2
   Physische Adresse . . . . . . . . : C8-60-00-8E-47-11
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4f87:2147:db21:39c5%23(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.56(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 04:33:58
   Lease läuft ab. . . . . . . . . . : Donnerstag, 14. September 2023 00:21:54
   Standardgateway . . . . . . . . . : 192.168.20.2
   DHCP-Server . . . . . . . . . . . : 192.168.20.2
   DHCPv6-IAID . . . . . . . . . . . : 331898880
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Fritz.box war vom lokalen Netz und localdomain war von der VM-OpnSense-Maschine. Warum hat diese eine höhere Priorität wie das lokale Netz?!?!?

Zuerst dachte ich das Problem über direkte Manipulation der DNS-Suchreihenfolge wie hier beschrieben https://learn.microsoft.com/de-de/troubleshoot/windows-client/networking/configure-domain-suffix-search-list-domain-name-system-clients zu lösen. Allerdings, nachdem es sich um keine einfache Lösung sondern um eine Registry-Manipulation handelte, wurde nach einer anderen Lösung gesucht.

Früher ließ sich so ein Problem bei den Netzwerkverbindungen mittels des versteckten Menüs Erweitert (vorher ALT-Taste einmal drücken) und dann Auswahl von “Erweiterte Einstellungen” lösen. Dort gab es das Register “Adapter und Bindungen”:

 

Doch unter Windows 10 gibt es nun nur noch das Register Anbieterreihenfolge (Provider Order):

Mal wieder eine tolle Sache. Wer kommt auf die Idee hier Menüs verschwinden zu lassen? Dieser Artikel brachte dann die Lösung https://learn.microsoft.com/de-de/windows-server/networking/technologies/network-subsystem/net-sub-interface-metric. Es gibt ein Powershell Kommando um die Schnittstellenmetrik definieren zu können, es nennt sich Set-NetIPInterface. https://learn.microsoft.com/en-us/powershell/module/nettcpip/set-netipinterface?view=windowsserver2022-ps.

So sah die Sache auf dem Host aus:

PS C:\WINDOWS\system32> Get-NetIPInterface -AddressFamily IPv4|select interfacemetric, interfacealias

interfacemetric interfacealias
————— ————–
             15 vEthernet (KundeTestNetz)
             15 vEthernet (OpnSenseNetzwerk)
             25 vEthernet (Controller…ek PCIe GBE Virtual Switch)
             15 vEthernet (Default Switch)
             75 Loopback Pseudo-Interface 1

D. h. die Netzwerkkarte im Host-System hatte eine niedrigere Priorität als der “Default Switch”. Die Metric-Wert war auf 25 und die virtuellen Switche hatten 15. Es konnte also nie ein Paket nach außen gelangen.

Nachdem dann mittels

Set-NetIPInterface -InterfaceIndex 23 -InterfaceMetric 5

der Metric-Wert geändert wurde, wie hier zu sehen:

PS C:\WINDOWS\system32> Get-NetIPInterface -AddressFamily IPv4|select interfacemetric, interfacealias

interfacemetric interfacealias
————— ————–
             15 vEthernet (KundeTestNetz)
             15 vEthernet (OpnSenseNetzwerk)
              5 vEthernet (Controller…ek PCIe GBE Virtual Switch)
             15 vEthernet (Default Switch)
             75 Loopback Pseudo-Interface 1

waren auf einmal alle Probleme behoben! Nachdem nun alles richtig gestellt war, war auch die Darstellung von ipconfig /all wieder in Ordnung:

C:\Users\Administrator>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : HyperVHost
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : fritz.box
                                       localdomain

Ethernet-Adapter vEthernet (Controller der Familie Realtek PCIe GBE Virtual Switch):

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Hyper-V-Adapter – virtuelles Ethernet #2
   Physische Adresse . . . . . . . . : C8-60-00-8E-47-11
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4f87:2147:db21:39c5%23(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.56(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 04:33:58
   Lease läuft ab. . . . . . . . . . : Donnerstag, 14. September 2023 00:21:54
   Standardgateway . . . . . . . . . : 192.168.20.2
   DHCP-Server . . . . . . . . . . . : 192.168.20.2
   DHCPv6-IAID . . . . . . . . . . . : 331898880
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (Default Switch):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physische Adresse . . . . . . . . : 00-15-5D-96-A6-6B
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::b711:9aff:aa98:4d94%32(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.17.224.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.240.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 536876381
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (OpnSenseNetzwerk):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-5C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::ad:802c:9657:2eaf%13(Bevorzugt)
   IPv4-Adresse (Auto. Konfiguration): 169.254.252.98(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 805311837
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (KundeTestNetz):

   Verbindungsspezifisches DNS-Suffix: localdomain
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-74
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::fb91:31ae:c923:8c31%22(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.102(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 11:19:48
   Lease läuft ab. . . . . . . . . . : Montag, 4. September 2023 15:19:49
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 620762461
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Der Vollständigkeithalber sind hier noch die Reaktionen eines Debian 12 Linux dokumentiert, wenn obiges Problem vorhanden ist.

Zunächst der Ping:

user@debian:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 172.17.224.1 icmp_seq=1 Time to live exceeded
From 172.17.224.1 icmp_seq=2 Time to live exceeded
From 172.17.224.1 icmp_seq=3 Time to live exceeded
From 172.17.224.1 icmp_seq=4 Time to live exceeded
^C
— 8.8.8.8 ping statistics —
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3004ms

Dann dig die nslookup-Variante von Linux:

user@debian:~$ dig google.de
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> google.de
;; global options: +cmd
;; no servers could be reached

und noch zum Abschluss die Reaktion bei traceroute:

user@debian:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  OPNsense.localdomain (192.168.1.1)  1.356 ms  1.333 ms  1.318 ms
2  172.17.224.1 (172.17.224.1)  1.791 ms  1.776 ms  1.762 ms
3  OPNsense.localdomain (192.168.1.1)  3.665 ms  3.650 ms  3.636 ms
4  172.17.224.1 (172.17.224.1)  4.003 ms  3.989 ms  3.976 ms
5  OPNsense.localdomain (192.168.1.1)  4.206 ms  4.192 ms  4.178 ms
6  172.17.224.1 (172.17.224.1)  4.604 ms  3.034 ms  3.013 ms
7  OPNsense.localdomain (192.168.1.1)  3.135 ms  6.627 ms  6.607 ms
8  172.17.224.1 (172.17.224.1)  7.442 ms  7.427 ms  7.412 ms
9  OPNsense.localdomain (192.168.1.1)  8.946 ms  7.167 ms  7.150 ms
10  172.17.224.1 (172.17.224.1)  7.566 ms  7.553 ms  7.540 ms
11  OPNsense.localdomain (192.168.1.1)  8.883 ms  8.870 ms  8.859 ms
12  172.17.224.1 (172.17.224.1)  9.025 ms  9.013 ms  9.498 ms
13  OPNsense.localdomain (192.168.1.1)  11.299 ms  11.466 ms  11.447 ms
14  172.17.224.1 (172.17.224.1)  11.797 ms  11.774 ms  9.114 ms
15  OPNsense.localdomain (192.168.1.1)  9.677 ms  10.444 ms  10.428 ms
16  172.17.224.1 (172.17.224.1)  11.654 ms  12.299 ms  12.277 ms
17  OPNsense.localdomain (192.168.1.1)  13.547 ms  13.534 ms  13.396 ms
18  172.17.224.1 (172.17.224.1)  13.081 ms  13.063 ms  13.050 ms
19  OPNsense.localdomain (192.168.1.1)  14.555 ms  14.542 ms  14.530 ms
20  172.17.224.1 (172.17.224.1)  12.825 ms  12.802 ms  12.754 ms
21  OPNsense.localdomain (192.168.1.1)  12.848 ms  12.830 ms  12.716 ms
22  172.17.224.1 (172.17.224.1)  13.123 ms  12.464 ms  12.447 ms
23  OPNsense.localdomain (192.168.1.1)  13.101 ms  15.354 ms  15.335 ms
24  172.17.224.1 (172.17.224.1)  15.706 ms  17.928 ms  18.225 ms
25  OPNsense.localdomain (192.168.1.1)  18.211 ms  18.198 ms  18.186 ms
26  172.17.224.1 (172.17.224.1)  20.433 ms  20.424 ms  20.407 ms
27  OPNsense.localdomain (192.168.1.1)  20.586 ms  20.570 ms  19.709 ms
28  172.17.224.1 (172.17.224.1)  19.961 ms  19.948 ms  17.236 ms
29  OPNsense.localdomain (192.168.1.1)  17.514 ms  15.482 ms  14.287 ms
30  172.17.224.1 (172.17.224.1)  12.110 ms  12.086 ms  12.070 ms

In früheren Zeiten verwendete man anstatt Set-NetIPInterface “route CHANGE” unter Windows. Die aktuellen Einstellungen Einstellungen unter Linux gibts mittels “ip route list” und Änderungen nimmt man mittels “ip route change” vor.

Nachdem nun klar war, wo das Problem lag, findet man natürlich auch Blog-Artikel die sich in ähnlicher Form dem Problem annehmen, wie hier z.B.: https://blog.pauby.com/post/hyper-v-default-switch-issues/.

SUDO Probleme bei Linux beheben

Bei einer Minimalinstallation von z. B. Debian kann es passieren, dass kein sudo-Kommando enthalten ist. Alle möglichen Beispiele oder Skripte verwenden sudo, also macht es Sinn es zur Verfügung zu stellen.

Ein einfacher Test sieht so aus:

user@debian12Test:~$ sudo fdisk –l
-bash: /usr/bin/sudo: Datei oder Verzeichnis nicht gefunden

Es muss also zuerst sudo installiert werden, was ganz einfach geht, man wechselt mittels su:

user@debian12Test:~$ su –
Passwort:
root@debian12Test:~#

Der Bindestrich, bestimmt ob man beim Benutzer oder beim root im Verzeichnis landet.

Nun kann man ganz normal mittels apt sudo installieren:

root@debian12Test:~# apt install sudo
root@debian12Test:~# exit

Nun kann man erneut sudo probieren:

user@debian12Test:~$ sudo fdisk –l
[sudo] Passwort für user:
»user« ist nicht in der sudoers-Datei.

Ok, nun ist sudo verfügbar aber es fehlt noch eine Kleinigkeit und zwar die betreffenden Rechte für den aktuellen Benutzer, dass dieser auch Adminrechte bekommen darf.

Dies erreicht man mittels diesem Aufruf

user@debian12Test:~$ su –
Passwort:
root@debian12Test:~# usermod -aG sudo user

Prüfen, ob der Benutzer in der richtigen Gruppe auftaucht

user@debian12Test:~$ id user
uid=1000(user) gid=1000(user) Gruppen=1000(user),24(cdrom),25(floppy),27(sudo),29(audio),
30(dip),44(video),46(plugdev),100(users),106(netdev)

Nun hat man alles richtig gemacht, aber es wird wohl immer noch nicht klappen. Entweder wird wieder der Eintrag in der sudoers-Datei angeprangert, oder es kann auch diese Meldung auftauchen:

user@debian12Test:~$ sudo fdisk –l
[sudo] Passwort für user:
Leider darf der Benutzer user sudo für debian12Test nicht verwenden.

Was fehlt jetzt noch? Man muss einmal die Sitzung verlassen und sich neu anmelden, dann werden die Einstellungen neu geladen, man benötigt also noch ein:

exit

Also Kurzusammenfassung geht so:

su –
apt install sudo
usermod -aG sudo user
exit  # vom su
exit  # vom user

Da wir gerade dabei sind, was ist der Unterschied zwischen “su root” und “su –“? Bei “su root” wird die aktuelle Umgebung beibehalten, bei “su –“ wird die root-Umgebung explizit gesetzt. Das ganze hat z. B. auf die Pfade Auswirkung:

user@debian12Test:~$ su –
Passwort:
root@debian12Test:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@debian12Test:~# exit
user@debian12Test:~$ su root
Passwort:
root@debian12Test:/home/user# whoami
root
root@debian12Test:/home/user# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Dieser kleine Unterschied hat Auswirkungen darauf, ob

usermod -aG sudo user

funktioniert oder wenn man nicht per “su –“ aufgerufen hat

/sbin/usermod -aG sudo user

verwendet werden muss, falls usermod nicht gefunden wird!

Windows “Abgesicherten Modus” loswerden

Bei einer Teamviewersitzung war ein Neustart in den abgesicherten Modus notwendig. Leider gab es dabei Probleme und der Rechner bootete von nun an immer im abgesicherten Modus.

Wie man den abgesicherten Modus losbekommt wird hier umfassend dargestellt.

https://www.tenforums.com/tutorials/2304-boot-into-safe-mode-windows-10-a.html#option3

Wer das Problem schnell gelöst haben will nimmt die GUI-Anleitung her, wer es aber klassisch einfacher gelöst haben will nimmt natürlich die Eingabeaufforderung. Da aber heutzutage, vor allem durch die Terminal-App sich Powershell immer mehr in den Vordergrund rückt, kann es dabei zu einer etwas komischen Reaktion kommen.

Um den Abgesicherten Modus loszubekommen verwendet man meistens

bcdedit /deletevalue {current} safeboot

Allerdings wird dieser Aufruf in der Powershell mit dieser Meldung quitiert:

Der angegebene Löschbefehl ist nicht gültig.
Führen Sie "bcdedit /?" aus, um die Befehlszeilenunterstützung aufzurufen.
Falscher Parameter.

Nun kann man ewig daran rumbasteln, es wird nicht funktionieren, es sei denn man weiß, dass die geschweiften Klammern {} eine besondere Bedeutung als Skriptblöcke in Powershell haben: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_script_blocks?view=powershell-7.3.

Wenn man dies weiß, dann kann man das Problem einfach umschiffen, indem man z. B.

bcdedit /deletevalue "{current}" safeboot

verwendet. Problem gelöst.

Was macht Microsoft AI.EXE? Hat es was mit Copilot zu tun?

Bei einer kürzlichen Durchsicht der Prozesse auf einem Rechner ist mir das Programm AI.EXE aufgefallen. Es war ein Windows 10 Rechner. Auf der Suche um was es sich handelt und was für eine Bedeutung die AI.EXE haben könnte, schaute ich mir die Eigenschaften an. Da war dann die Rede von

Artificial Intelligence (AI) Host for the Microsoft® Windows® Operating System and Platform x64.

In Hype-Zeiten von ChatGPT war das natürlich gleich näher zu untersuchen! Als Pfad war das virtuelle Dateisystem von Office angegeben.

C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16

Neugierig was es damit genauer auf sich hat stellte ich mit Powershell tiefergehende Forschungen an, zunächst wollte ich alle Instanzen von ai.exe finden:

Set-Location C:\
$ai=dir -Recurse ai.exe -ErrorAction SilentlyContinue

$ai enthielt Pfade von drei Orten:

    Verzeichnis: C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16

Mode                 LastWriteTime         Length Name
—-                 ————-         —— —-
-a—-        15.03.2023     01:49         731048 ai.exe

    Verzeichnis: C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16

Mode                 LastWriteTime         Length Name
—-                 ————-         —— —-
-a—-        15.03.2023     01:49         580976 ai.exe

    Verzeichnis: C:\Program Files (x86)\Microsoft
    Office\Updates\Download\PackageFiles\C82C3FE5-DED0-4EC5-B96C-9004F324B31E\root\vfs\ProgramFilesCommonX64\Microsoft
    Shared\Office16

Mode                 LastWriteTime         Length Name
—-                 ————-         —— —-
-a—-        15.03.2023     01:49         731048 ai.exe

Vergleicht man die Dateigröße mit der Instanz welche als Prozess am Laufen war, wurde die 64-Bit Variante ausgeführt. Warum aber wird der Prozess als 64-Bit Prozess ausgeführt, obwohl Office nur als 32-Bit Version installiert ist?

Hier die zugehörige Info aus Word:

“Microsoft® Word 2016 MSO (Version 2302 Build 16.0.16130.20298) 32 Bit “

Scheinbar findet die Kommunikation nicht direkt sondern zwischen den Prozessen statt.

Wechselt man mittels

Set-Location ‚C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16‘

in das Verzeichnis wo die AI.EXE liegt, findet man weitere Dateien wo dazu gehören:

dir ai*|select name,@{N=’Description‘;E={$_.VersionInfo.filedescription}}

Name      Description
—-      ———–
ai.dll    Artificial Intelligence (AI) for the Microsoft® Windows® Operating System and Platform x64.
ai.exe    Artificial Intelligence (AI) Host for the Microsoft® Windows® Operating System and Platform x64.
aimgr.exe Artificial Intelligence (AI) Manager for the Microsoft® Windows® Operating System and Platform x64.
aitrx.dll Artificial Intelligence (AI) Transceiver (TRX) for the Microsoft® Windows® Operating System and Platform x64.

Ein direkter Start per Commandline ist nicht möglich. Auch wird keine Hilfe oder eine andere Info ausgegeben.

Schaut man sich aber die laufende Instanz an, sieht man, dass diese mit Parametern gestartet wurde:

Get-WmiObject Win32_Process -Filter "name = ‚ai.exe’" | Select-Object CommandLine |fl –Force

CommandLine : "C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft
              Shared\OFFICE16\ai.exe" "A4234858-5568-4CE0-A1D9-30DE20119E21" "76BD008A-3D23-42AC-91D5-629726FD7929"
              "26696" "C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"

Hier wird man nun also fündig, welches Programm für den Aufruf verantwortlich ist. Ruft man ein weiteres Programm auf, wie in diesem Fall Powerpoint, gesellt sich eine zweite AI.EXE hinzu:

CommandLine : "C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft
              Shared\OFFICE16\ai.exe" "A4234858-5568-4CE0-A1D9-30DE20119E21" "76BD008A-3D23-42AC-91D5-629726FD7929"
              "26696" "C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE"

CommandLine : "C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft
              Shared\OFFICE16\ai.exe" "2FAD19E9-02C3-4621-BF68-237713E86D62" "93583A96-47F5-411C-86CB-2D1D1863983A"
              "31004" "C:\Program Files (x86)\Microsoft Office\root\Office16\POWERPNT.EXE"

Also kann man sagen, jede Software bekommt ihre eigene AI-Prozessinstanz. Startet man allerdings Word mehrfach, wird immer nur auf die bestehende AI-Instanz zurückgegriffen. Also gibt es nur mehrere AI-Instanzen, wenn unterschiedliche Programme aus dem Office-Paket gestartet werden. Die GUIDs bei den obigen Parametern ändern sich jedesmal, muss also eine interne Geschichte sein. die kleine Zahl, im obigen Beispiel stellt immer die ProzessID dar, also 26696 und 31004 waren die IDs der Prozesse, dies konnte mittels

Get-Process –PID 26696, 31004

überprüft werden.

Wird das jeweilige Office-Programm beendet, dann wird auch die zugehörige AI.EXE aus dem Speicher entladen. Wird der AI.EXE-Prozess manuell beendet, dann bleibt er auch beendet und wird von Word nicht neu gestartet.

Wenden wir uns nun den Innereien von AI.EXE zu. Schaut man sich die AI.DLL inhaltlich mittels Notepad an, dann tauchen da ganz viele Eintragungen mit ONNXRuntime auf. Weitere Infos gibt es hier: https://onnxruntime.ai/ bzw. https://github.com/microsoft/onnxruntime. ONNX gesprochen Onyx steht für Open Neural Network Exchange. Ein guter Artikel wo den Unterschied zwischen ONNX und ONNXRuntime darstellt: https://becominghuman.ai/a-deep-dive-into-onnx-onnx-runtime-part-1-874517c66ffc.

Für uns ist zunächst interessant zu wissen, dass ONNX-Dateien die Endung .onnx haben. Demzufolge ging ich auf die Suche und wurde fündig:

PS C:\> $onnx=dir -Recurse *.onnx -ErrorAction SilentlyContinue
PS C:\> $onnx

    Verzeichnis: C:\Program Files (x86)\Microsoft Office\root\Office16\AI

Mode                 LastWriteTime         Length Name
—-                 ————-         —— —-
-a—-        14.01.2022     20:11         644792 PowerPointCombinedFloatieLreOfflineExplorationV3.onnx
-a—-        25.05.2021     00:33        1666416 PowerPointCombinedFloatieLreOnline.onnx
-a—-        14.01.2022     20:11         566751 PowerPointCombinedFloatieLreOnlineV3.onnx
-a—-        12.07.2022     16:57         422463 PowerPointCombinedFloatieV4.onnx
-a—-        08.09.2022     11:49         514273 PowerPointFloatieAllV5.onnx
-a—-        08.09.2022     11:49        1451193 PowerPointFloatieTerminalV5.onnx
-a—-        05.02.2021     18:14         183257 PowerPointOpenLifeguardDesktop.onnx
-a—-        09.11.2021     11:36         456359 PowerPointOpenLifeguardDesktop20210922.onnx
-a—-        14.01.2022     20:11        2157505 WordCombinedFloatieLreOfflineExplorationV3.onnx
-a—-        25.05.2021     00:33         293471 WordCombinedFloatieLreOnline.onnx
-a—-        14.01.2022     20:11        1253743 WordCombinedFloatieLreOnlineV3.onnx
-a—-        12.07.2022     16:57         441160 WordCombinedFloatieV4.onnx
-a—-        08.09.2022     11:49         520100 WordFloatieAllV5.onnx
-a—-        08.09.2022     11:49        1016953 WordFloatieTerminalV5.onnx
-a—-        12.07.2022     16:57       10546096 WordFluencyV1.onnx
-a—-        13.12.2022     14:59       14196557 word_fluency_v2.onnx

ONNX-Dateien sind binäre Dateien. ONNX-Dateien werden im “Protocol Buffers format” oder kurz ProtoBuf beschrieben. Dafür gibt es dann sogenannte Decoder bzw. Deserializer: https://docs.servicestack.net/protobuf-format.

Kommen wir noch zu mlg.dll welches zu dem AI-Komplex gehört, lässt man sich die Dateibeschreibung dazu anzeigen, erscheint:

Machine Learning Group (MLG) for the Microsoft® Windows® Operating System and Platform x64.

Die Beispiele sind alle mit einem aktuellen Office 2016 durchgeführt worden, ich gehe aber davon aus, dass Office 2019, Office 2021 und Office365 sowieso mit der AI.EXE arbeiten.

Bei der weiteren Recherche nach verschiedenen Punkte bin ich dann noch über dieses Video gestolpert: https://www.youtube.com/watch?v=ebls5x-gb0s. Hier wird Office365 Copilot beschrieben, welcher nun anscheinend ganz groß ausgerollt wird. AI.EXE hat da sicher seinen Anteil dran. Dieser Link bestätigt auch nochmal vieles von obigen Erfahrungen, wobei ich alle Prozessverhalten so nicht nachvollziehen kann: OFFICE16 ai.exe – Microsoft Community. Hier wird beschrieben, wie man AI.EXE abschalten kann: How do I disable the "Artificial Intelligence (AI) Host – Microsoft Community. Zu guter Letzt noch ein Hinweis zu Reddit und Warnungen bzw. falsche Zuordnungen der AI.EXE: Unknown ai.exe deep inside program files directory : techsupport (reddit.com).

Treiberversion von Windowsdruckertreibern ermitteln

Lange Zeit gab es unter Windows nur die Druckertreiberversion 3. Als Windows Vista auf die Bühne kam brachte dies XPS-Druckertreiber-Unterstützung mit und damit Version 4.

Da Version 4 Druckertreiber selbst heute noch teilweise Probleme machen, z. B. beim Schachtwechsel bei bestimmten Druckjobs, ist man auf die Version 3 Druckertreiber angewiesen.

Wie kann man nun feststellen, ob man es mit einem V3 oder V4-Druckertreiber zu tun hat?

Eigentlich wäre die Sache recht simpel, man ruft z. B.

PS > Get-Printer -name ‚OneNote for Windows 10’|Get-PrinterDriver
Get-PrinterDriver : Es wurden keine MSFT_PrinterDriver-Objekte gefunden, bei denen die Name-Eigenschaft gleich
"OneNote for Windows 10" ist. Überprüfen Sie den Wert der Eigenschaft, und versuchen Sie es erneut.
In Zeile:1 Zeichen:44
+ Get-Printer -name ‚OneNote for Windows 10’|Get-PrinterDriver
+                                            ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (OneNote for Windows 10:String) [Get-PrinterDriver], CimJobException
    + FullyQualifiedErrorId : CmdletizationQuery_NotFound_Name,Get-PrinterDriver

Wie immer, könnte so einfach sein. Aber leider schafft es Powershell nicht die Verknüpfung zwischen Druckerwarteschlange und Druckertreiber aufzulösen.

In diesem Beispiel wird aber beschrieben, wie mittels WMI die fehlende Verbindung zwischen beiden hergestellt werden kann, nämlich mittels der Win32_DriverForDevice-Klasse.

https://devblogs.microsoft.com/scripting/how-can-i-retrieve-information-about-the-printer-driver-used-by-a-printer/

In Powershell gegossen, sieht das dann so aus:

PS> $printerName=’OneNote for Windows 10′
PS> $printer=gwmi win32_printer -Filter "Name=’$printerName’"
PS> $printerDriver=gwmi -Query "Associators Of {Win32_Printer.DeviceID=’$($printer.DeviceID)‘} WHERE AssocClass = Win32_DriverForDevice Role=Antecedent"
PS> $printerDriver.Version
4

Oder nun als einfache Funktion:

Function Get-PrinterDriverFromPrinter {
[CmdletBinding()]
Param(
  [String]$Name
)

$printer=gwmi win32_printer -Filter "Name=’$Name’" 
If ($printer) {
  $printerDriver=gwmi -Query "Associators Of {Win32_Printer.DeviceID=’$($printer.DeviceID)‘} WHERE AssocClass = Win32_DriverForDevice Role=Antecedent"
  If ($printerDriver) {
   $printerDriver
  }
}
}

Somit kann man diesen Aufruf zur Ermittlung der Druckertreiberversion verwenden:

PS> (Get-PrinterDriverFromPrinter -Name ‚OneNote for Windows 10‘).Version
4

Trankskripte aus Youtube Videos in Form bringen

In Youtube Videos gibt es meistens Transkriptionen zum gesprochenen Text. Dazu gibt es (meist) unterhalb des Videos ein Symbol mit dem Text Transkript. Falls Transkript nicht direkt zu sehen ist, findet der Punkt sich im Menü, welches angezeigt wird, wenn man die drei Punkte anklickt.

Danach öffnet sich oben rechts ein Fenster welches den Text des Videos darstellt. In der Regel werden hier Zeitstempel mit dargestellt. Mittlerweile kann man die Zeitstempel mittels eines weiteren Menüs ausblenden. Für unsere Zwecke verwenden wir aber das Transkript mit Zeitstempel. Man kann nun mit der Maus und gedrückter linker Maustaste den Text markieren und in die Windowszwischenablage kopieren.

Fügt man nun einen solchen Text ein, erhält man bei dem Video https://www.youtube.com/watch?v=9VnbPf3noi0 diesen Text:

0:00

warum ich mir keine gebrauchte sst kaufe ganz egal ob 2,5 zoll sata ssd oder

0:06

irgendwo eine m 2 das zeige ich mal in diesem video hier in diesem video habe ich den rechner aufgebaut und da sind

0:13

vier ssds angeschlossenen nummer 1 nummer 2 nummer drei und die nummer vier die ist hier hinten im gehäuse drin und

0:21

so ne ssd die ist immer eine wundertüte also man glaubt gar nicht was man da alles sieht und findet wenn man die

Besser wäre es, wenn der Zeitstempel rechts vom Text stehen würde, bzw. wenn der Text direkt hintereinander stehen würde.

Mittels diesem Powershell-Skript wird beides möglich:

Function ConvertFrom-YtTranscript {
    [CmdletBinding()]
    Param(
         #[Parameter(ValueFromPipeline,ValueFromPipelineByPropertyName)]
        [Parameter(ValueFromPipeline)]
        $Transcript,
         [switch]
        [bool]$PreserveTime
    )

    Begin {
         $Time = “
    }

    Process {
       
        ForEach ($line in $Transcript) {
          $m= [regex]::matches($line, ‚(\d+:)?[\d]{1,2}:\d\d‘)
          If ($m.Count -gt 0) {
            If ($PreserveTime) {
                $Time = $m.groups[0].Value
            } else {
                # ignoiere Zeitstempel
             }
          } else {
            If ($PreserveTime) {
                 "[$Time] $line"
            } else {
                 $line
            }
          }
        }
    }
}

Damit erhält mittels Aufruf von

Get-Clipboard|ConvertFrom-YtTranscript |Set-Clipboard

diesen Text in der Windowszwischenablage:

warum ich mir keine gebrauchte sst kaufe ganz egal ob 2,5 zoll sata ssd oder
irgendwo eine m 2 das zeige ich mal in diesem video hier in diesem video habe ich den rechner aufgebaut und da sind
vier ssds angeschlossenen nummer 1 nummer 2 nummer drei und die nummer vier die ist hier hinten im gehäuse drin und
so ne ssd die ist immer eine wundertüte also man glaubt gar nicht was man da alles sieht und findet wenn man die

Oder mit dem Parameter zum Erhalt der Zeitstempel:

Get-Clipboard|ConvertFrom-YtTranscript -PreserveTime|Set-Clipboard

diesen Text:

[0:00] warum ich mir keine gebrauchte sst kaufe ganz egal ob 2,5 zoll sata ssd oder
[0:06] irgendwo eine m 2 das zeige ich mal in diesem video hier in diesem video habe ich den rechner aufgebaut und da sind
[0:13] vier ssds angeschlossenen nummer 1 nummer 2 nummer drei und die nummer vier die ist hier hinten im gehäuse drin und
[0:21] so ne ssd die ist immer eine wundertüte also man glaubt gar nicht was man da alles sieht und findet wenn man die

Natürlich lässt sich aus dieser Funktion noch mehr machen, wie z. B. wieder Links direkt ins Video auf Youtube oder eben auch Links zum Video auf Odysee. Aber das vielleicht ein anderes Mal…

Excel und Makros im Trustcenter freischalten

Üblicherweise kann man Makros im Trustcenter bei Excel freischalten: https://support.microsoft.com/de-de/office/%C3%A4ndern-der-makrosicherheitseinstellungen-in-excel-a97c09d2-c082-46b8-b19f-e8621e8fe373. Wenn man allerdings eigene Makros von einer leeren Vorlage schreibt und dann über diese Meldung stolpert

Das Makro ‚foo.xls!macro1‘ kann nicht ausgeführt werden. Das Makro ist möglicherweise in dieser Arbietsmappe nicht verfügbar, oder alle Makros wurden deaktiviert.

dann kann man schon mal das Grübeln anfangen.

Die Ausführung der Makros war definitiv erlaubt. Trotzdem kam es zu obiger Meldung.

Die Lösung brachte dann die Auslagerung der Methode Macro1 in ein eigenes Modul in VBA!

Windows 11 Setup mit lokalem Konto einrichten

Windows 11 hat die penetrante Angewohnheit nach einem Microsoft-Konto beim Setup zu fragen. Die einfachste Form dies zu umgehen ist am Zeitpunkt der Frage nach dem Konto mit Shift+F10 die Eingabeaufforderung zu öffnen, dann mittels

ipconfig /release

die aktuelle IP-Adresse freizugeben. Dann kann man die Eingabeaufforderung wieder schließen und beim Microsoft-Konto-Fenster oben links den Pfeil nach links anklicken. Nun realisiert das Setup, dass keine gütige IP-Adresse hinterlegt ist und fragt wie früher nach dem Benutzernamen.

Nach dem Setup fehlt die IP-Adresse aber immer noch. Hier hilft entweder ein Neustart des Rechners oder nochmals mittels Eingabeaufforderung

ipconfig /renew

eine neue IP-Adresse anzufordern.

Eine weitere Variante die Netzwerkverbindung zu kappen wäre, z. B. über netsh:

netsh interface show interface
netsh interface set interface name="Ethernet" admin=DISABLED

Weitere Infos und Möglichkeiten sind hier beschrieben: https://www.askvg.com/tip-how-to-complete-windows-11-setup-without-internet-connection/

Windows 10 Offlinepartnerschaften bereinigen

Nachdem auf einem Windows 10 Rechner die Offlinepartnerschaften komplett zerhauen waren, das System allerdings nicht neu eingerichtet werden konnte, musste ein Weg gefunden werden, das Problem so in den Griff zu bekommen.

Am Ende hat dieser Weg geholfen:

• Synccenter aufrufen und Offlinedatien beenden
• Rechner neu starten
• Eingabeaufforderung mit Adminrechten öffnen
• Verzeichnis C:\Windows\CSC mittels
  takeown /r /f C:\windows\CSC
  übernehmen
• Mittels
  rd /s C:\Windows\CSC
  das Cache-Verzeichnis entfernen
• Nun mittels
  reg add HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters /v FormatDatabase /t REG_DWORD /d 1
  den Registry-Eintrag zum Löschen der Datenbank eintragen
• Rechner neu starten
• Offlinedateien wieder aktiveren
• Netzwerkverbindung wieder herstellen und Partnerschaften neu einrichten

Beim Offlinedateien aktivieren verschwindet automatisch der FormatDatabase-Eintrag aus der Registrierung.

Siehe auch: https://www.ugg.li/windows-10-offlinedateien-zuruecksetzen-reset/

Noch ein Hinweis: Schaut man per Powershell mittels Get-Service csc dann ist dies der Treiber und nicht der Dienst, der Dienstname lautet cscservice, ergo muss man Get-Service cscservice abfragen um rauszufinden, ob der Dienst beendet ist.