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.
Archiv des Autors: chris
Windows Update Fehler 0xc190028
Möglicherweise verhindern inkompatible Programme ein Update. Ein Liste mit diesen Programmen findet man unter C:\$ WINDOWS ~BT\Sources\Panther\CompatData [date-time].xml
Quelle: https://www.borncity.com/blog/2017/07/18/windows-10-update-fehler-0xc1900208/ (unten in den Kommentaren)
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 Server Versionen
Windows Server 2016 (OS build 14393) – Serviceende
Windows Server 2019 Version 1809 (OS build 17763)
Windows Server 1909 (OS build 18363) – Serviceende
Windows Server 20H2 (OS build 19042)
Windows Server 2022 (OS build 20348)
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-
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