Archiv des Autors: chris

Proxmox File-Restore

Leider lassen sich (derzeit) keine einzelne Dateien von Windows Servern wiederherstellen, auf denen die Windows Deduplizierung aktiviert ist.

Über folgenden Weg gelingt es doch:

Ausgangssituation:
PVE 7.1-12
PBS 2.1-5
VM Windows Server 2022 mit aktivierter Deduplikation (VMID 117 (in diesem Beispiel))
– vorhande Festplatten:
sata0 mit dem Betriebssystem
virtio1 als Datenfestplatte


Wir benötigen eine „Restore-VM“ mit der gleichen Windows Version, wie der produktive Server auf dem die Daten fehlen sowie installiertem Deduplikation-Feature.

Anschließend suchen wir uns einen Snapshot des produktiven Servers, in dem die fehlenden Daten möglicherweise noch vorhanden sind:

proxmox-backup-client snapshot list –repository root@pam@pbs.lan.home:zfs01

├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ vm/117/2022-04-15T16:54:04Z │ 102.004 GiB │ client.log drive-efidisk0.img drive-sata0.img drive-tpmstate0-backup.img drive-virtio1.img index.json qemu-server.conf │
├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ vm/117/2022-04-18T09:14:16Z │ 102.004 GiB │ client.log drive-efidisk0.img drive-sata0.img drive-tpmstate0-backup.img drive-virtio1.img index.json qemu-server.conf │
├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

Da wir wissen, dass die Datenfestplatte virtio1 ist, mounten wir den letzten Snapshot mit folgendem Befehl:

proxmox-backup-client map vm/117/2022-04-18T09:14:16Z drive-virtio1.img –repository root@pam@pbs.lan.home:zfs01

Ausgabe: Image ‚root@pam@pbs.lan.home:8007:zfs01:vm/117/2022-04-18T09:14:16Z/drive-virtio1.img‘ mapped on /dev/loop0

Disclaimer: Natürlich legt Ihr Euch auf dem PBS einen Benutzer an, der auf die Snapshots zugreifen darf. Ich habe „root“ nur der Einfachheit halber genommen.

Von Device /dev/loop0 müssen wir (in diesem Fall) die erste und einzige Partition als zusätzliche Festplatte in der Konfiguration der Restore-VM hinterlegen:

Konfiguration Restore-VM (VMID 999) unter /etc/pve/qemu-server/999.conf

agent: 1
bios: ovmf
boot: order=virtio0;ide2;net0;ide0
cores: 2
efidisk0: zfs01:vm-999-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: local:iso/virtio-win-0.1.217.iso,media=cdrom,size=519096K
ide2: local:iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.1_64Bit_German_DC_STD_MLF_X22-82989.ISO,media=cdrom,size=4914750K
machine: pc-q35-6.2
memory: 6144
meta: creation-qemu=6.2.0,ctime=1650452727
name: restore-vm
net0: virtio=E2:7C:A7:C5:53:BF,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsihw: virtio-scsi-pci
smbios1: uuid=fe458dd8-4fd5-4c3e-b20d-fab892470d95
sockets: 2
tpmstate0: zfs01:vm-999-disk-1,size=4M,version=v2.0
virtio0: local-lvm:vm-999-disk-0,size=32G
virtio1: /dev/loop0p1,ro=1
vmgenid: a580f33b-f9ea-4548-b430-031c8f8f4bed

Leider erkennt der Windows Server die Festplatte erst nachdem man den Server aus- und wieder eingeschaltet hat. Danach kann die Festplatte über den Server Manager online geschaltet werden. Die fehlenden Daten können nun z. B. über eine Freigabe auf den produktiven Server kopiert werden.

ZENworks Agent startet nicht

Falls der ZENworks Agent auf einem Rechner, auf dem auch der Citrix Desktop installiert ist, nicht starten, bitte den Wert von Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Configuration\MasterImage von „1“ auf „0“ stellen. Ggf. muss der Schlüssel „MasterImage“ erstellt werden (DWORD).

Quelle: Hinweis in der Datei „C:\Program Files (x86)\Novell\ZENworks\logs\ZenworksWindowsService.log“

Windows 10 Versionen

21H2 (OS build 19044)
21H1 (OS build 19043)
20H2 (OS build 19042)
2004 (OS build 19041) – Serviceende
1909 (OS build 18363)
1903 (OS build 18362) – Serviceende
1809 (OS build 17763)
1803 (OS build 17134) – Serviceende
1709 (OS build 16299) – Serviceende
1703 (OS build 15063) – Serviceende
1607 (OS build 14393)
1511 (OS build 10586) – Serviceende
1507 (RTM) (OS build 10240)

Quelle: https://docs.microsoft.com/de-de/windows/release-health/release-information
Stand: 2022-02-03

Windows 10 Update-Probleme

Windows 10 hatte das Problem, dass Updates nicht vom internen WSUS-Server heruntergeladen wurden. Der Fehlercode war 0x8024500c.

Lösung:
Per GPO Dual-Scan ausschalten. Die Richtlinie lautet „Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird.“ Die Richtlinie muss auf „Aktiviert“ gesetzt werden.

Quellen:
https://www.escde.net/blog/windows-update-richtlinien-und-dual-scan
https://social.technet.microsoft.com/Forums/windows/en-US/bcfa00b1-63aa-497d-b5dc-cde62db72469/client-failing-to-update-from-wsus-server-failed-8024500c-method-failed?forum=winserverwsus
Stand: 27.01.2022

Windows 10 – Optionale Features nachinstallieren

Ausgangssituation:
Virtueller Desktop und keine Möglichkeit sich als lokale Administrator anzumelden. Es sollen die RSAT-Tools nachinstalliert werden (hier: ActiveDirectory.DS-LDS.Tools)

Eingabeaufforderung als Administrator ausführen

Folgenden Befehl ausführen (eine Zeile):

DISM.exe /Online /add-capability /CapabilityName:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Falls DISM abbrechen sollte: ggf. ist bei Euch ein WSUS-Server eingerichtet, aber die optionalen Features sind von dort nicht installierbar. Hierzu in der Registry die Werte für den WSUS-Server entfernen und den Windows-Update-Dienst neu starten (als Administrator).

Powershell hinter Proxy

Ausgangssituation:
In der Powershell sollen zusätzliche Module nachinstalliert werden. Der Rechner ist über einen Proxy mit dem Internet verbunden.

Als Benutzer mit Admin-Rechten die Powershell starten und folgendes ausführen

notepad $profile

Es wird Notepad mit der Profildatei des Benutzers geöffnet. Falls die Datei nicht vorhanden ist, wird nachgefragt, ob die Datei erstellt werden soll. In die Datei schreibt man folgendes:

[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy('http://<Name-des-Proxy>:<Port-des-Proxy>')
[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Quelle: https://spaghettidba.com/2017/12/19/recovering-the-psgallery-repository-

behind-a-corporate-proxy/

Falls der Benutzer mit Admin-Rechten keinen Zugriff über den Proxy auf das Internet hat, kann man die zweite Zeile durch folgendes ersetzen:

[system.net.webrequest]::defaultwebproxy.credentials = get-credential

Es erscheint dann ein Anmeldefenster in das man alternative Zugangsdaten eintragen kann. Jetzt kann man die entsprechenden Module nachinstallieren.

VAMT 3.1 – Windows Server 2022

Es erscheint die Fehlermeldung, dass die Datenbank keine gültige VAMT Datenbank ist. Das Problem ist, dass eine Spalte in der Tabelle „base.GenuineStatusText“ nicht NULL sein darf. Damit VAMT 3.1 funktioniert, muss die Tabelle mit folgendem Befehl angepasst werden:

alter table base.GenuineStatusText alter column GenuineStatusText nvarchar(255) NULL

Quelle: https://www.reddit.com/r/sysadmin/comments/oypsd8/vamt_database_not_a_valid_vamt_database/

Docker: Ändern des Subnetz der Default-Bridge

Die Default-Bridge hat das Subnetz 172.17.0.0/16. Das kollidiert unter Umständen mit bestehenden Netzen. Um das Subnetz für die Bridge zu ändern muss man in der Datei

/usr/lib/systemd/system/docker.service

Den Eintrag

ExecStart=/usr/bin/dockerd -H fd:// –containerd=/run/containerd/containerd.sock

um –bip 192.168.166.1/24 erweitern. Der Wert ist natürlich an das gewünschte Netz anzupassen.

ExecStart=/usr/bin/dockerd -H fd:// –containerd=/run/containerd/containerd.sock –bip 192.168.166.1/24

Danach

systemctl daemon-reload
systemctl restart docker.service

Achtung!
Hier darf man nicht am Ende .0 angeben!

Kontrolle:

#> docker network inspect bridge

[
{
„Name“: „bridge“,
„Id“: „970a529a1c0e77d13e27fe097dced4d1f8c9b81c0da6a3afe0f0e1cf4a3dd7cc“,
„Created“: „2021-09-09T07:01:50.862101974Z“,
„Scope“: „local“,
„Driver“: „bridge“,
„EnableIPv6“: false,
„IPAM“: {
„Driver“: „default“,
„Options“: null,
„Config“: [
{
„Subnet“: „192.168.166.0/24„,
„Gateway“: „192.168.166.1“
}
]

},
„Internal“: false,
„Attachable“: false,
„Ingress“: false,
„ConfigFrom“: {
„Network“: „“
},
„ConfigOnly“: false,
„Containers“: {},
„Options“: {
„com.docker.network.bridge.default_bridge“: „true“,
„com.docker.network.bridge.enable_icc“: „true“,
„com.docker.network.bridge.enable_ip_masquerade“: „true“,
„com.docker.network.bridge.host_binding_ipv4“: „0.0.0.0“,
„com.docker.network.bridge.name“: „docker0“,
„com.docker.network.driver.mtu“: „1500“
},
„Labels“: {}
}
]

Quelle: https://forums.docker.com/t/how-can-i-pass-the-bip-argument-change-bridge-network-ip/15346