SCCM Client Update failed mit 0x8004402F beim MOFCOMP

Szenario: Update SCCM Server auf 1806, Client-Auto-Update enabled, einige Clients weigern sich standhaft auf die neue Version zu aktualisieren. Im CLIENT.MSI.LOG gibts zig Einträge mit Fehler 8004402F beim MOFCOMP, Beispiel:

[19:30:57] Failed to compile 'C:\Windows\CCM\ccmclasses.mof' (Phase: 2, Object: 0, Lines: 0 - 0, Error: 8004402F)

Grund (in meinem Fall zu mindestens): In %TEMP% vom System Account (C:\WINDOWS\TEMP bei mir) waren über 65.000 temporäre Dateien mit dem Muster TMPabcd.TMP, offenbar sind dem System die möglichen Kombinationen für abcd ausgegangen und MOFCOMP braucht aber eine (oder mehrere) temporäre Dateien. TMP*.TMP gelöscht und das SCCM Client Setup flutscht wieder.

DPM Agent in untrusted domain

Nachdem ich jetzt schon mehrfach eingefahren bin, SetDpmServer.exe -dpmServerName xxxx -isNonDomainServer -userName yyyy macht folgendes (abseits von dem was es auf dem Bildschirm ausgibt):

* der lokale User (Agent UND DPM Server!!!) wird mit den notwendigen Gruppen neu versorgt
* „Password does not expire“ wird vom lokalen Account entfernt
* „User must change password at next logon“ wird NICHT entfernt

Setzt man also nach dem Kommando nicht die entsprechenden Flags auf den lokalen Usern neu und läuft das Kennwort ab bekommt man die coolsten Fehlermeldungen ala „A DPM agent failed to communicate with the DPM service“ und ähnliches aber KEINERLEI Hinweise auf das Problem mit dem Konto….

Gesamte SQL Server DB als CSVs exportieren

SSIS kann nur einzelne Tabellen, SQLCMD mit -o erzeugt speziell bei NTEXT Columns nur Blödsinn und Copy/Paste aus dem SSMS ist ab einer bestimmten Anzahl von Tabellen eher witzlos, hab daher das Powershell-Scriptl von hier geklaut und etwas angepasst:

$Server="mysqlserver"
 $DB="mydb"
 $FilePath="C:\Temp"
 $FilePrefix="mydb_"
 
 $Tables = Invoke-Sqlcmd -query "SELECT name FROM sys.tables" -Database $DB -ServerInstance $Server
 foreach ($Table in $Tables)
 {
     $TableName = $Table["name"]
     write-host -ForegroundColor White "Creating File $FilePrefix$TableName.csv"
     Invoke-Sqlcmd -query "SELECT * FROM $TableName" -Database $DB -ServerInstance $Server |Export-Csv -Path $FilePath\$FilePrefix$TableName.csv -Encoding Default
 }

DPM verliert Verbindung zu Agent auf Rechner in untrusted domain

Hatten wir jetzt zweimal, Grund war dass das Kennwort des lokalen Benutzer der für die Kommunikation am Agent-Rechner angelegt wird abgelaufen ist.

Behebung:

  1. Agent: Passwort ändern.
  2. Agent: SetDpmServer.exe -dpmServerName ... -isNonDomainServer -userName ...
    (Vorsicht: entfernt ein etwaig gesetztes „Password never expires“!)
  3. Agent: Passwort auf never expires setzen.
  4. Server: Update-NonDomainServerInfo.ps1 -DPMServerName ... -PSName ...

Azure S2S VPN mit Libreswan auf Raspberry Pi Zero

Es gibt ja jede Menge Anleitungen für Site2Site VPN mit Azure, Beispiele:

Connect your on-premises network to an Azure virtual network

Microsoft Azure : How-to setup a site-to-site VPN using OpenSwan (on a Telenet SOHO subscription)

 
Raspi muss natürlich sinnvollerweise eine statische Adresse haben und Routing muss enabled sein (wie im zweiten Beispiel gut beschrieben):

#/etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1

Das war der einfache Teil – mit Raspbian (auch in der aktuellsten Version März 2018) funktioniert die Verbindung aber wie oben beschrieben nicht weil OpenSWAN im Raspian bei 2.6.38 aufhört (2012 – der Zeitpunkt an dem der Gründer das Projekt verlassen und Libreswan gegründet hat) und das schlicht und ergreifend zu alt ist wie es sich darstellt.

Libreswan gibts aber für Raspbian in einer aktuellen Version nicht als Binary, d.h. man muss selbst zur Tat schreiten: Auf der Github Seite zu Libreswan ist eh alles beschrieben:

apt-get install libnss3-dev libnspr4-dev pkg-config libpam-dev \
                libcap-ng-dev libcap-ng-utils libselinux-dev \
                libcurl3-nss-dev flex bison gcc make libldns-dev \
                libunbound-dev libnss3-tools libevent-dev xmlto \
                libsystemd-dev

TAR saugen, auspacken und dann make all USE_DNSSEC=false USE_FIPSCHECK=false sowie sudo make install.

Das zentrale Configfile (/etc/ipsec.conf) ist im Endeffekt auch relativ knackig:

version 2.0

config setup
   nat_traversal=yes
   virtual_private=%v4:192.168.1.0/24     # Range @home
   plutostderrlog=/var/log/libreswan.log
conn azure
   authby=secret
   auto=start
   type=tunnel
   left=192.168.1.99               # Adresse vom Raspi
   leftsubnet=192.168.1.0/24       # Range @home
   leftnexthop=192.168.1.1         # Router @home
   right=1.2.3.4                   # Adresse Azure virtual network gateway (public IP)
   rightsubnet=10.0.0.0/16         # Range Azure virtual network
   ikev2=insist
   ike=aes256-sha256-modp1024      # ohne spezielle Policy nur MODP1024 möglich!
   esp=aes256-sha256

Dann noch PSK in /etc/ipsec.secrets hinterlegen:

%any %any: PSK "dasgeheimniskommthierhin"

(alternativ auch statt dem ersten %any die lokale Adresse und dem zweiten %any die public IP des virtual network gateways)

Start/Stop wie gehabt mit sudo service ipsec start bzw. sudo service ipsec stop. Logfile wie in der Configdatei angeführt.

Am Router muss Port Forwarding für UDP 500 und 4500 auf den Raspi eingerichtet werden.

Auf den Clients im Heimnetz muss eine entsprechende Route eingetragen werden, z.B. route add 10.0.1.0 mask 255.255.255.0 192.168.1.99 für einen Windows-Client wenn es in Azure ein Subnet 10.0.1.0/24 für irgendwelche Resourcen (VMs, oder ähnliches) gibt (natürlich müssen in Azure die entsprechendesn Network Security Groups auf den Resourcen sitzen damit man hin kommt, da unterscheidet sich der Zugriff via VPN nicht wirklich von dem Zugriff aus dem Internet).

Doku zu den IKEv2 Parametern:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices

Doku zu den IPSec Policies (noch nicht probiert):
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell

Hyper-V Gen2 VM „No Boot entries are configured“

Disclaimer: Das Folgende ist natürlich alles ohne Schusswaffe und dient eigentlich nur für mich als Erinnerungsstütze falls es wieder mal auftritt. Nachmachen auf eigene Gefahr 🙂

Im VMM (2016) beim Versuch Gen2 VM zu erzeugen: Error 23352 VMM cannot find the device or this device is not valid for a boot device.

Alle Berichte verweisen irgendwann zu diesem Foreneintrag – welcher aber ein Reinstall von Hyper-V will was bei einem produktive S2D Cluster nicht so witzig ist (glaub ich halt :-)).

Hatte eben einen Call mit Microsoft dazu und das hier hat das Problem gelöst:

  1. VMs eines Hosts via LiveMigration wegmigrieren
  2. adm. CMD/Powershell in C:\Windows\System32:
    a) mofcomp WindowsVirtualizationUninstall.mof
    b) mofcomp WindowsVirtualization.V2.mof
  3. Service „Hyper-V Virtual Machine Management“ (vmms) restarten
  4. adm. CMD/Powershell in
    C:\Program Files\Microsoft System Center 2016\Virtual Machine Manager\setup:
    mofcomp scvmmswitchportsettings.mof
  5. Service „System Center Virtual Machine Manager Agent“ restarten

Ein Host war dann remote nicht mehr verwaltbar (zumindestens Hyper-V), da war Reboot angesagt.

 

 

PS Oneliner: Output von Sysinternals‘ RU lesbar machen

RU.EXE (Registry Usage) hat irgendwie eine sehr seltsame Consolenausgabe, nur im CSV-Outputformat steht die wirklich interessante Information (die KB pro Subkey), hiermit bekommt man die in KB umgerechnet angezeigt:

$r=@();(ru64.exe hku\.default -l 1 -nobanner -c)|select-object -skip 1|% { $o=New-Object psobject; $o|Add-Member -Type NoteProperty -name "Key" -value $_.Split(',')[0]; $o|Add-Member -Type NoteProperty -Name "Size" -Value ([int](([int]($_.Split(',')[5]))/1024)); $r=$r+$o };$r

Win 10 + Office 365 Azure AD + AAD Join = Something went wrong

Microsoft hat offenbar irgendwann in Office 365 ein Mini-MDM (gratis) eingebaut – wenn man das nicht aktiviert hat läuft man in den allseits gleichermaßen beliebten und aussagekräftigen „Something went wrong“ Fehler wenn man beim Windows 10 Setup im OOBE versucht den Rechner dem Azure AD zu joinen (wobei das Azure AD das vom „nackten“ Office 365 Tenant ist).

Auf die Spur gebracht hat mich dieser Post. (der MS Supportler dort meint aber das kanns nicht sein :-D)

Wie man das Office 365 MDM „korrekt“ aufdrehen kann weiß ich nicht, ich bin folgendermaßen vorgegangen:

  • Office 365 Portal als Admin
  • „Security & Compliance“ Badge
  • Tile „Search for users“ nach einem beliebigen Testuser gesucht und geöffnet
  • Im Reiter „Summary“ den Link „Mobile management“ geklickt
  • Defaults akzeptiert
  • einige Stunden gewartet

 

Namen aller aktiven Agents eines DPM Servers ermitteln

Stand vor der Aufgabe festzustellen welche DPM Agents in mindestens einer Protection Group vorkommen und dann brauchte ich den Namen des Agents (und nicht der Data Source die sich ja teilweise arg unterscheiden je nach Backuptyp), meine Lösung als Einzeiler inklusive Connect/Disconnect:

$x=@(); $d=Connect-DPMServer $dpm; Get-DPMProtectionGroup|% { $x=$x+(get-DPMDataSource $_|% {$n=$_.GetType().Name; if ($n -match "FsDataSource|SystemProtectionDatasource|HyperVRctDatasource") { if ($_.VmName -eq $null) {$_.Computer } else {$_.VmName} } else { $_.Name}}) }; $d=Disconnect-DPMServer; $x|sort-object –Unique