Die muessen ja irgendwas tun, sonst koennten die Kunden auf die Idee kommen, dass sie unnoetig jede Menge Geld zahlen.
Hi Buster,
An einem solchen Skript wären wir sehr interessiert, wäre es möglich, das hier zu veröffentlichen ?
Gruß
Sascha
Hi,
was für eine unsinnig Aussage. Denkst du die denken sich die Schadsoftware selber aus, die sie dann erkennen oder noch schlimmer, zeigen gleich Fake-Alarme an? Wenn dem so wäre, bestünde eine hhoe Gefahr der Entdeckung und dann wäre deren Reputation und damit potenzieller Kundenkreis gleich null.
VG
Buster
Hallo,
Wir nutzen derzeit sowas wie:
# Powershell als Admin öffnen und ausführen:
# ./Prepare-Image.ps1
# PowerShell mit Admin-Rechten (UAC) starten, falls noch nicht geschehen
# dies ruft genau das selbe Skript mit identischen Parametern auf
# funktioniert nicht in PowerShell ISE
if (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = "& '" +$myinvocation.mycommand.definition + "'"
Start-Process powershell.exe -Verb runAs -ArgumentList $arguments
Break
}
#----------------------------------------------------------------------
# Ordner bereinigen
Get-ChildItem "C:\Users\All Users\MySQL\MySQL Installer for Windows\Product Cache" -Filter "mysql*" -ErrorAction Ignore | Remove-Item -ErrorAction Ignore
Get-ChildItem "C:\Windows\temp" -Filter "*" -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Users\*\AppData\Local\Temp\" -Filter "*" -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Program Files (x86)\Microsoft\EdgeUpdate\Download" -Filter "*" -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Program Files (x86)\Microsoft\EdgeUpdate\Install" -Filter "*" -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Program Files\Google\Chrome\Application\*\Installer" -Filter "*" -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Windows\Logs\" -Filter "*.cab" -Recurse -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Windows\Logs\" -Filter "*.etl" -Recurse -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Windows\Logs\" -Filter "*.log" -Recurse -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
Get-ChildItem "C:\Windows\Logs\" -Filter "*.xml" -Recurse -ErrorAction Ignore | Remove-Item -Recurse -ErrorAction Ignore
#----------------------------------------------------------------------
Write-Host -ForegroundColor Cyan "Adobe Acrobat Updates deaktivieren ..."
Stop-Service AdobeARMservice
Set-Service AdobeARMservice -StartupType Disabled
#----------------------------------------------------------------------
Write-Host -ForegroundColor Cyan "Microsoft OneDrive Aufgaben deaktivieren ..."
Get-ScheduledTask "OneDrive *" | Unregister-ScheduledTask -Confirm:$false
#----------------------------------------------------------------------
### TODO Test-Path auf acrobat.exe ausführen und Segment in if-Block packen
## Campus-Lizenzierung Acrobat Pro einspielen, erfordert prov.xml mit Vorbereitung aus Adobe Provisioning Toolkit
# siehe https://helpx.adobe.com/de/enterprise/kb/provisioning-toolkit-enterprise.html
Write-Host -ForegroundColor Cyan "Adobe Acrobat vorbereiten ..."
$oldErrorActionPreference = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"
.\activate_license\adobe_prtk.exe --tool=VolumeSerialize --provfile=.\activate_license\prov.xml --stream
$ErrorActionPreference = $oldErrorActionPreference
#----------------------------------------------------------------------
Write-Host -ForegroundColor Cyan "Windows Updates deaktivieren und bereinigen ..."
Stop-Service wuauserv
Set-Service wuauserv -StartupType Disabled
# Puffer-Wartezeit, damit Dienst sich beendet und SoftwareDistribution gelöscht werden kann
start-sleep -Seconds 10
if (Test-Path "C:\Windows\SoftwareDistribution") {
Remove-Item -Path C:\Windows\SoftwareDistribution -Recurse -Force
}
if (Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" -Name "SusClientId" -ErrorAction SilentlyContinue) {
Remove-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" -Name "SusClientId" -Force
}
if (Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" -Name "AccountDomainSid" -ErrorAction SilentlyContinue) {
Remove-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" -Name "AccountDomainSid" -Force
}
#----------------------------------------------------------------------
Write-Host -ForegroundColor Cyan "Windows-Ereignisprotokolle leeren ..."
$logs = Get-EventLog -List | ForEach-Object { $_.Log }
$logs | ForEach-Object { Clear-EventLog -LogName $_ }
#----------------------------------------------------------------------
Write-Host -ForegroundColor Cyan "Skript beendet."
$confirmation = Read-Host "Press y to proceed (end script)"
if ($confirmation -eq 'y') {
# proceed
}
Den Aufruf von $env:windir\system32\cleanmgr.exe /verylowdisk haben wir nicht mit drin, da es dort 2-3 Probleme gibt:
- Das Programm scheint sich nicht korrekt zu beenden, so dass man das mit Wait-Process nicht sauber überwachen kann, ob es fertig ist.
- Es muss ebenfalls mit Admin-Rechten gestartet werden, um alle Ordner, die vom Programm unterstützt werden, auch bereinigen zu können, z. B. darf ein Nutzer ohne Admin-Rechte den Windows-Update-Cache nicht leeren.
- Microsoft hatte mehrfach die Update/Upgrade-Mechanismen geändert, so dass manchmal die Bereinigung in einem weiteren Schritt erst während des nächsten Bootvorgangs abgeschlossen wurde.
Daher haben wir uns angewöhnt die Datenträgerbereinigung immer als Admin auszuführen, dann einen Neustart durchzuführen und danach das Skript Prepare-Image.ps1 als Admin zu starten. Dann Neustart und Aufzeichnung des Images.
Im Code-Block „Ordner bereinigen“ kann man natürlich beliebige Ordner ergänzen, die einem so nach und nach auffallen, dass das Cache-Verzeichnisse von Betriebssystem oder Anwendungen sind.
Viele Grüße
Buster
1 „Gefällt mir“
Hallo Christian,
vielen Dank für den Hinweis, das war mir völlig entgangen. Wir bearbeiten mal nach und nach die PCs und beobachten. Da das Problem zwar häufig aber trotzdem unvorhersehbar auftritt, brauche ich noch eine Weile. Ich melde mich dann aber wieder.
Liebe Grüße
Lars
Hallo nochmal,
jetzt bin ich auf eine interessante Sache gestoßen. Ich bin über den c’t-Notfallstick in den MiniTool Partition Wizard rein und habe das hier vorgefunden:
Frage: Warum fehlen die Label von msr und cache?
Ich habe das an unterschiedlichen Clients in unterschiedlichen Hardware-Gruppen getestet, sowohl NVME als SSD-Platten, immer das selbe Bild.
Ist das ein Bug oder steh ich mal wieder auf dem Schlauch? Zumindest würde es ja die Probleme erklären…
LG
Lars
Edit: Hat das evtl. was mit dem Filesystem zu tun? Windows-FS (FAT32/ntfs) werden erkannt, msr (FSType in der start.conf leer) und cache (ext4) nicht.
Hallo Lars,
ich würde das erstmal mit einem livelinux überprüfen, ob da wirklich die Label fehlen.
Dort im Terminal
blkid /dev/nvme0n1pX
nacheinander, wobei X durch die Nummern 1,2,3,4,5
ersetzt werden.
Sollten die Label tatsächlich fehlen, so lösch alle Partitionen auf der nvmeSSD von diesem LiveLinux aus (nicht rebooten und linbo das machen lassen, sondern im Livelinux mit gparted oder mit gdisk im Terminal), dann wieder linbo booten und Partitionieren lassen und dann nochmal mit blkid nachschauen, ob da wirklich Label fehlen (das geht auch aus der console von linbo heraus).
Wenn sie dann da sind, dann einen weiteren Client mit linbo booten und partitionieren und auch danach schauen, ob die Label da sind.
Ich will wissen, ob:
- wirklich Label fehlen (ich traue deinem Tool nicht)
- wenn sie Fehlen, ob sie auch nach dem Partitionieren von einer sauberen SSD fehlen.
- wenn sie dann da sind, dann ob sich linbo durch vorhandene Partitionen verwirren läßt beim Partitionieren.
Wenn 3 kein Problem ist, dann würde ich vermuten, sollten Label wirklich gefehlt haben, dass sie, als der Client zuletzt partitioniert wurde, noch nicht in der start.conf.GRUPPE standen.
Das was da drin als Label steht, wird auf den Clientplatten erst „wirklichkeit“, wenn man Partitioniert.
LG
Holger
Hallo Holger, hallo alle,
dank eurer Hilfe haben wir jetzt das Problem. Anscheinend wird das Label für die msr-Partition (Part 2) nicht gesetzt. Bei den fraglichen Rechnern muss da irgendwann mal das Label „cache“ für die Partition 2 reingerutscht sein und wurde nie überschrieben. Wann immer Linbo dann auf die cache-Partition zugreifen möchte, ist es ein Glücksspiel, ob er die richtige oder die falsche erwischt.
Labels bei einem der Problemrechner:
Labels bei einem Rechner mit manuell gelöschten Partitionen und frischer Linbo-Partitionierung:
Ein manuelles Löschen der Partitionen behebt also das Problem.
Nun wäre es evtl. für die Entwickler noch zu prüfen, ob das msr-Label gesetzt werden kann.
Viele Grüße und danke nochmal!
Lars
Tja, schade… Problem doch noch nicht behoben.
Also ich boote einen PC mit einem Windows RE via USB-Stick, starte diskpart, wähle meine Disk und mache „clean“ —> Partitionstabelle wird gelöscht.
Dann boote ich den PC ins Linbo und lasse die Festplatte nach der start.conf partitionieren. Jetzt ist meine Hoffnung, dass die Labels richtig sitzen bzw. die Partition 2 kein Label mehr hat (siehe oben). Um das zu überprüfen boote ich ein Live-Linux und teste die Labels mit blkid.
Aber leider: immer noch hat die Partition 2 das Label „cache“!!
Alternativ habe ich die Partitionen mit fdisk oder parted aus dem Live-Linux gelöscht, kein Unterschied.
HELP!!
Hallo Lars,
bitte poste mal die start.conf.GRUPPE
der betroffenen Clients und die Ausgabe von fdisk -l auf dem Client unddie Ausgabe von blkid /dev/nvme0n1p2
LG
Holger
Hallo Holger,
start.conf und Ausgabe blkid siehe oben (blkid erstes Bild, hat sich nicht geändert).
fdsik -l liefere ich morgen nach.
LG
Lars
Hallo Lars,
die Partitionierung deiner beiden Rechner ist falsch. Auch die des Rechners mit frischer Linbo-Partitionierung.
Die msr-Partition muss bei blkid mindestens folgenden Eintrag aufweisen:
Bei dir sieht es aus, als sei die Partion von Linbo gar nicht angelegt worden.
Das solltest du mit gparted oder einem anderen Tool prüfen.
Welche Linbo-Version verwendest du?
Viele Grüße
Christian
Hallo Christian,
also angelegt ist die Partition schon, sie hat nur kein Label und „kein“ Dateisystem:
(Das Bild ist von einem PC aus einer anderen Hardware-Gruppe mit SSDs, ist aber genauso wie bei den NVME-PCs.)
Wir verwenden aktuell Linbo 4.2.14-0.
LG
Lars
Hallo Lars,
dass die msr-Partition kein Label und kein Dateisystem hat ist normal.
Aber die EFI-Partition sollte Daten enthalten und daher „Benutzt“ sein. Auch sollte weder bei EFI noch bei msr ein rotes ! sein. Schau mal in gparted die Information (rechte Maustaste ==> Information) an, was da los ist.
Viele Grüße
Christian
Hallo Christian,
die Efi-Partition ist aus meinem Live-Ubuntu einfach nicht lesbar, „Unable to read the contents of this file system! … The cause might be a missing software package.“ Die Partition macht ja aber auch keine Probleme.
Bei der MSR-Partition sieht es schon anders aus:
Unable to detect file system! Possible reasons are:
- The file system is damaged
- The file system is unknown to GParted
- There is no file system available (unforamtted)
- The device entry /dev/sda2 is missing
Habe hier noch zwei Anzeigen, einmal über parted, einmal über lsblk, vielleicht kann jemand was damit anfangen:
LG
Lars
Möchte den Thread doch noch mal pushen…
Wer kann uns weiterhelfen? Im Wesentlichen beschäftigen mich zwei Fragen:
- Wie kann ich die Partitionstabelle bzw. die Labels so löschen, dass sie wirklich weg sind? Im oben beschreibenen Fall hat die Partition 2 auch nach Löschen und Neupartitionierung durch Linbo am Ende wieder bzw. immer noch das Label „Cache“.
- Ist es generell so, dass der msr-Partition kein Label gesetzt werden kann? Könnte man hier von Entwicklungsseite etwas einbauen, so dass zumindest ein evtl. vorhandes Label vorher gelöscht wird bzw. das Label überschreiben?
Ich wäre wirklich dankbar für weitere Tips, die PCs machen immer wieder Probleme.
Danke und Gruß
Lars
Hi,
normalerweise sollte es ausreichen den Anfang des Speichermediums mit dd zu überschreiben, dass die Partitionstabelle enthält, z. B. mit dd if=/dev/zero of=/dev/sda bs=1M count=1. Das sollte sich auch in der Konsole der Linbo-PXE-Umgebung ausführen lassen. Ein vollständiges Löschen (alle Bits einmal mit 0 oder Zufallswerten überschreiben) dauert bei heutigen Speichergrößen zu lange und ist unnötig, wenn man das Medium nicht entsorgen will. Wenn man das dennoch machen will, haben wir gute Erfahrung mit der ISO von ABAN gemacht, die wir auf einem USB-Stick mit Ventoy laufen lassen.
Mancher Hersteller des BIOS/EFI bietet für Datenträger auch eine Option „low level format“ in den Menüs an. Das ist in der Regel ein vollständiges Löschen.
Überprüfe nochmal, ob der Rechner auch wirklich in der richtigen Gruppe ist und damit die richtige Konfiguration (Partitionslayout) angewendet wird. Hier habe ich den Effekt, dass wir zwar Labels in der WebUI für alle Partitionen eingetragen haben (Base 7.2.3-0; Linbo 4.2.14-0; WebUI 7.2.66) und diese auch in der start.conf auf Server und Client aufgeführt werden, aber im Windows kann man für die MSR-Partition das Label nicht mit Boardmitteln einsehen und blkid in der PXE-Umgebung zeigt auch kein Label für die MSR-Partition an.
Nicht verrückt machen lassen. Ab und zu hilft es auch einen Schritt rückwärts zu machen, Abstand zu nehmen und mal drüber nachdenken, ob man einem Fehlschluss erliegt oder noch andere Probleme vorliegen können und ob die mit dem aktuellen Problem zusammenhängen können.
Auf Labels › Wiki › ubuntuusers.de wird bspw. ersichtlich, dass es Labels für Partitionen (Wert für „PARTLABEL“) im Partitionstabellenformat GPT (aber nicht bei MBR) gibt und Labels für’s Dateisystem (Wert für „LABEL“). Während Linbo versucht die Labels aus der WebUI in LABEL zu schreiben, zielt Microsoft auf PARTLABELs ab.
/dev/nvme0n1p1: LABEL_FATBOOT="efi" LABEL="efi" UUID="6744-B85A" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="28ee6093-2ca8-4163-bd09-82f6907aadd2"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="c113cec8-4492-49a1-bb66-13602419575e"
/dev/nvme0n1p3: LABEL="System" BLOCK_SIZE="512" UUID="8EB85EA9B85E9017" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="22531984-f8ef-4e87-a214-88fe076668e3"
/dev/nvme0n1p4: LABEL="cache" UUID="915457ee-b0b8-4c96-99d8-469892291dbc" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="cache" PARTUUID="93efd298-a989-43d6-9622-bda69816213a"
VG
Buster
Hallo Buster,
danke für deine ausführliche Erkärung, die letztendlich zur Lösung geführt hat.
Das haben wir versucht, aaaaber: same procedure, nach dem neu Partitionieren war das falsche Label bei den „kranken“ PCs wieder da.
Ich habe schließlich den zu überschreibenden Bereich so weit erhöht, dass nicht nur die Partitionstabelle sondern die gesamte msr-Partition genullt wird, erst dann war Ruhe. Die ersten beiden Partitionen haben zusammen 328 MB, wir haben also 500 MB bzw. sicherheitshalber dann gleich 1 GB genullt und gut war.
dd if=/dev/zero of=/dev/nvme0n1 bs=1G count=1
Anscheinend trägt also die Partition ihr Label „in sich“ und dieses wird dann bei jeder Neupartitionierung wieder hergestellt.
Danke nochmal und viele Grüße
Lars