HP Savi 8200 UC-Serie Poly Headset plötzlich ohne Mikro

Die kabellose USB-DECT-Headset „Savi 8200“ von HP scheint im Laufe der Zeit so seine Zicken zu entwickeln. Nach mehreren (Support-)Anrufen deswegen bei uns, dachten wir, wir geben das Geheimnis der Wiederbelebung nun Preis.

NAch vielen Jahre praktisch ohne Fehler häufen sich grade (gefühlt) die Effekte mit dem Gerät.

Fehler

Das Mikrofon („Micro“) ist einfach weg. Im Gerätemanager ist das „Earset“ noch da, aber das „Mikro“ ist weg. Wenn man die „ausgeblendeten Geräte“ anzeigt, ist der Treiber noch sichtbar, wird aber nicht mehr geladen. In den Einstellungen gibt es kein Gerät, das als „Audioeingang“ auswählbar ist.

Das Mikro bleibt vollkommen stumm, in allen Apps.

Oft passiert das auch nicht „auf einmal“, sondern nach und nach. In Teams geht es noch, in VoIP-Software nicht mehr, dann auch kein Teams mehr, dann auch kein Browser (BBB, Zoom) mehr. Ein klassischer Fall von „heute morgen ging’s noch“).

Lösung

Der beherzte Hardware-Reset half bisher immer sofort:

  1. Headset ausschalten (mit dem Button an der Basisstation)
  2. Headset ausstecken (USB und Stromkabel)
  3. Batterie aus dem Earpiece entfernen
  4. 15 Sekunden (!) warten
  5. Alles wieder zusammenbauen, USB wieder einstecken

Und schon ist beides wieder da.

Mehrere Dateien in einem Ordner auf einem „entblocken“ (Zulassen)

Das Windows Feature „Mark of the Web“ (MotW) oder auch „Zone.Identifier“ im Dateisystem genannt, markiert aus einer unsicheren Quelle (z. B. aus dem Internet oder als E-Mail-Anhang) herunterladen Dateien.

Tecninsch: Im (NTFS- und ReFS-) Dateisystem werden Metadaten in einem Anhang namens „Zone.Identifier“ mit Dateien mitgespeichert. Das ist Applikationssache, aber praktisch alle Browser und E-Mail-Programme heute unterstützen diese Funktion.

Damit Dateien mit so einer Markierung ihre volle inhaltliche Wirkung entfalten können, müssen diese erst über das Kontextmenü > Eigenschaften „zugelassen“ werden.

Das gilt ärgerlicherweise auch für die Vorschau von PDF-Dateien. Man könnte heute vermuten, die Menschheit (einschliesslich der Erfinder des Formats) haben mittlerweile eine sichere Lösung erfunden – aber nein.

Lösung

Man kann MotW in einer Pro-Benutzer-Einstellung abschalten, aber grundsätzlich hat dieses Sicherheitsfeature einen sinnvollen Grund. Wir Admins mögen das auch.

Um nun mehrere Dateien in einem Verzeichnis zuzulassen, reicht ein PowerShell-Einzeiler:

Get-ChildItem "C:\EXAMPLE-RECHNUNGEN" -Filter *.pdf | Unblock-File

Je nach Anwendungsfall, lässt sich das Script rekursiv oder mit mehr oder weniger Filtern verwenden. Beispiel:

Get-ChildItem "$env:USERPROFILE\Downloads\Eingang" -Recurse -Filter *.pdf | Unblock-File

Somit haben sich hundert Klicks auf viele neue Dateien immerhin auf einen Doppelklick reduziert.

Windows Update GPO (WSUS) Einstellungen zurücksetzen

Wenn man die GPO-Einstellungen für Windows Updates zurücksetzen möchten, beispielsweise weil man endlich von WSUS seinem alten wegwechseln möchte, ist die Entfernung des gesamten zugehörigen Registry-Schlüssels der einfachste Weg dazu:

HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate

Dadurch wird Windows Update gezwungen, die Standardeinstellungen erneut zu laden und zu verwenden. Den Schlüssel erstellt Windows Update beim Neustart des Dienestes neu.

Lösung

Alles auf einmal Copypasty:

Remove-Item "HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate" -Force -Recurse
gpupdate /force
Restart-Service -name "Windows Update"

Wichtig: Das Entfernen einer GPO-Verknüpfung mit WSUS-Einstellungen, sowie das setzene auf „nicht konfiguriert“ entfernen die Einstellungen in diesem Schlüssel nicht.

Die Registry-Schlüssel (via GPO) ändern sich nicht von selbst, nur weil eine Grupenrichtlinie nicht mehr angewendet wird. Man könnte zwar die GPO für den WSUS-Serverstandort auf „Deaktiviert“ setzen, die GPO-Verteilung abwarten und sie dann auf „Nicht konfiguriert“ umstellen; angesichts der Systeme, die zum Zeitpunkt der Änderung keine GPO-Updates erhalten (z. B. Remote-Benutzer, Offline-Systeme), ist es jedoch durchaus möglich, dass einige Systeme nur den neuesten Status („Nicht konfiguriert“) übernehmen, während die Registry-Einträge, die das System auf den WSUS verweisen, bestehen bleiben.

Daher empfehlen wir: besser auf Nummer sicher.

Dekommissionierte Server aus Microsoft Azure Arc entfernen

Manchmal sind Server „weg“, bevor sie ordentlich bei Azure Arc ge-offboarded wurden; das Offboarding ist nicht immer Teil eines Dekomissionierungsprozesses. Die „veralteten“ Maschinen bleiben dann Teil des Azure Arc und liefern einfach keine Daten mehr. Diese können natürlich weg.

Lösung

Leider hat Microsoft „vergessen“ im GUI die notwendigen Knöpfe einzubauen. Das wäre aber logisch, sinnvoll und einfach.

So wird man Maschienen aus Azure Arc an der PowerShell (als Aministrator) los:

# Az Modul installieren
Install-Module Az.ConnectedMachine

# Mit Azure Arc verbinden
Connect-AzAccount

# Maschine ansehen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>

# Maschine entfernen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>| Remove-AzConnectedMachine

Veeam B&R Upgrade auf v13 schlägt fehlt mit der Fehlermeldung „Outdated Veeam Agents“

Manchmal zeigt die B&R (noch 12) Konsole keine verwalteten Agents an, oder das Setup auf v13 beschwert sich das ein nicht aufgeführter Agent „outdated“ sei.

„Outdated Veeam Agents“ (Configuration Check)

Es gibt in der „Physical Infrastructure“ aber keine Agenten, die Liste ist leer. Oder zumindest keinen, der dem angezeigten Namen des Setups entspricht.

Lösung

In der Veeam-Datenbank spukt noch ein Agent herum, der zwar nicht angezeigt, aber trotzdem noch für „managed“ gehalten wird.

Der Agent muss manuell aus der Veeam-Datenbank entfernt werden. Am Beispiel hier wird PostgreSQL genutzt, für Microsoft SQL Datenbanken kann der Vorgang analog mit den jeweils passenden Tools ausgeführt werden.

Erstelle eine Datei .\query1.sql mit dem folgenden Inhalt:

SELECT epagents.host_id, epagents.agent_version, ephosts.display_name
FROM "public"."backup.model.epagents" AS epagents
INNER JOIN "public"."backup.model.ephosts" AS ephosts ON epagents.host_id=ephosts.id
WHERE ephosts.display_name = 'EXAMPLE-AGENTENNAME'
ORDER BY  epagents.agent_version ASC;

… und führe diese in der Veeam-Datenbank aus (Pfad zu psql entsprechend anpassen):


"C:\Program Files\PostgreSQL\15\bin\psql" -d VeeamBackup -U postgres -f .\query1.sql

Dann gibt die Konsole die entsprechenden Agenten-IDs aus.

Selbige kann man dann mit einem zweiten SQL-Script (z.B. query2.sql) entfernen:

SELECT public.deleteephost('AGENTEN-ID-HIER-EINFUEGEN');
SELECT public.deleteepagent('AGENTEN-ID-HIER-EINFUEGEN');

… und schon ist der Agent so richtig und wirklich ganz entfernt.