Szenario: SCCM Update durchgeführt, Client AutoUpgrade enabled, findet aber nicht statt
Fehler im ccmseutp.log:
Failed to get DP locations as the expected version from MP 'https://meinsccm.meinefirma.whatever'. Error 0x87d00215
Grund:
Das SCCM Package “Configuration Manager Client Package” wurde nicht oder nicht korrekt auf den oder die Distribution Points verteilt. Sieht man im Content Status – ist der nicht grün hats was. Im konkreten Fall hat ein “Update Distribution Points” gereicht.
Weil ich jedes mal wieder die Switches zusammensuchen muss:
signtool sign /sha1 thumbprint /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 my.exe
Weil ich auch deswegen wirklich jedes Mal wieder überrascht bin und jedes Mal wieder zu suchen beginne:
hdmi_force_hotplug=1
config_hdmi_boost=4
in /boot/config.txt auskommentieren.
Wählt man “Import…” im XenCenter aus und importiert somit eine VHD von einem Windows Rechner/Share läuft das immer fix mit 100 MBit – was je nach VHD-Größe anstrengend sein kann.
Schneller gehts wie immer wenn man zum schwarzen Fenster greift:
mount -t cifs //server/share /mntdir -o domain=…,username=…,password=…,vers=3.0xe sr-listVDI=$(xe vdi-create sr-uuid=… name-label=… virtual-size=…)xe vdi-import uuid=$VDI filename=/mntdir/my.vhd format=vhdWer eine Gen2 Hyper-V VM (=UEFI) auf Gen1 (=BIOS) konvertieren muss (in meinem Fall um die VHD auf XenServer zu importieren) muss etwas in die Trickkiste greifen – ich bin hier fündig geworden, hab aber ein paar kleine Änderungen vorgenommen:
list vol / sel vol #)active)cd /d c:\)bootrec /fixmbr, bootrec /fixboot, bootrec /rebuildbcd)Keine Ahnung worans liegt aber in dem Fall war am Host (2012R2) der Power Plan auf “Balanced” und die VM (2008R2) hat auf Vollgas nicht mal 100 MB/sek gebracht (zig physische Spindeln).
Power Plan auf “High performance” gesetzt und die Read-Rate ist instant auf erwartbare Werte (800 MB/sek) gesprungen.
Muss irgendeinen Hardwarebezug haben (hier: HP ProLiant DL380 Gen9) – andere Geräte (auch der gleichen Generation aber mit anderen Komponenten) zeigen dieses Verhalten nicht….
Hinweis hab ich hier gefunden.
Weil ich auch das immer vergesse: https://my-dxi/cgi-bin/stats
Weil ich auch das immer wieder vergesse:
use MyDB
declare @proc varchar(50)
declare procs cursor for select SPECIFIC_NAME from INFORMATION_SCHEMA.ROUTINES where ROUTINE_TYPE='PROCEDURE' and SPECIFIC_NAME like '%whatever%'
open procs
fetch next from procs into @proc
while @@FETCH_STATUS = 0
begin
print @proc
exec sp_recompile @proc
fetch next from procs into @proc
end
close procs
deallocate procs
Weil ichs dauernd vergesse:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\Open with Notepad]
[HKEY_CLASSES_ROOT\*\shell\Open with Notepad\Command]
@="notepad \"%1\""
Android Device Manager in Visual Studio 2017 legt Android Emulator VMs IMMER mit 2 Cores an – wo doch jeder weiß dass ein Android unter 4 Cores in Wahrheit unbenutzbar ist eine sehr fragwürdige Entscheidung. Die Emulatoren sind völlig überraschend schweinelangsam – und es gibt keinen Parameter wo man das easy raufstellen könnte.
Lösung: Emulator manuell starten mit Parameter -cores XX oder im Device Manager einen Custom Parameter namens hw.cpu.ncore hinzufügen und als Wert die gewünschten Cores angeben:
