SCCM: Rerun if failed previous attempt

Wer Computer in großem Stil mit Software versorgen muss, bedient sich einer Software ala Microsoft System Center Configuration Manager (SCCM). Genau um diesen geht es in diesem Beitrag.

Seit geraumer Zeit habe ich mich gefragt was im SCCM bei einem Deployment das Setting "Rerun if failed previous Attempt" für einen Sinn hat. Ich habe das immer gesetzt, eine fehlgeschlagene Installation wurde jedoch nie erneut versucht. Da die Leidensgrenze bei den fehlgeschlagenen Installationen nie hoch genug war, hat mich das nicht weiter beschäftigt. Da ich jetzt aber einen Fall habe, wo von 2500 Installationen mehr als 200 schief gegangen sind, ist mir dieses Setting wieder eingefallen und ich habe mich daher auf die Suche gemacht um heraus zu finden, was es damit auf sich hat. Dank Google war sehr schnell ein Blog gefunden, wo das in kurzen Worten hervorragend erklärt wird.

20160420-SCCM-Deploy.jpg

Rerun if failed previous attempt/Rerun if succeeded on previous attempt

These two are also essentially opposites and behave as expected according to our two conclusions from above:

  • Clients have no memory of advertisements or their schedules once the advertisement is no longer applicable to that client
  • Clients do maintain past program execution status even if the advertisement that caused them to run is no longer part of the client’s policy

This second conclusion is important for these last two settings and is what differentiates them. In all scenarios, if a new execution time is dictated – by a new schedule, new advertisement with a new schedule, or an advertisement removed and then re-added to a client – the status of the previous execution attempt is evaluated first and according to which setting is chosen – succeed or fail) the client either runs or does not run the program again.

Ergo: man muss entweder dem Deployment ein neues Schedule hinzufügen oder ein neues Deployment erstellen. Dann geht der Client her und prüft das letzte Ergebnis und führt dementsprechend der gewählten Einstellung das Deployment aus bzw. neuerlich aus oder eben nicht.

(RaiZl)

Active Directory und Legacy Logon Scripts

Ich hatte das Problem, dass in einer unserer Active Directory Domains bei der Anmeldung eines Users keine Logon Scripts mehr ausgeführt wurden. Da über diese jedoch Netzlaufwerke verbunden und diverse andere Einstellungen vorgenommen werden, ist das relativ unangenehm.

Es gab keine Hinweise im Eventlog am Client, auch keine Hinweise im Eventlog am Domain Controller. Mittels Procmon und Boot Logging (da wird das Logon auch mitgeloggt) konnte ich auch nicht wirklich etwas finden, außer dem seltsamen Versuch, das Logon Script am Client auf "C:\Windows\system32\repl\import\scripts" zu finden. Ich fühlte mich in NT4 Zeiten zurück versetzt.

Microsoft selbst ist ja kein Freund von Legacy Logon Scripts, wenn man mit Google umgehen kann, findet man recht schnell heraus, dass man statt dessen Group Policy Scripts verwenden soll. Somit war es relativ schwierig hier etwas hilfreiches via Suchmaschine zu finden. Nach langem Suchen stellte sich heraus dass das Problem aufgrund einer ganz speziellen Konfiguration auftritt.

Hat man mehrere Active Directory Domains, wie z.B. x.mydomain.at und y.mydomain.at, dann hat man für diese auch ein DNS zu betreiben. Wenn jedoch am Client in der DNS-Suchreihenfolge nur die Domain x.mydomain.at eingetragen ist, wird ein Versuche einen Computer in der Domain y.mydomain.at aufzulösen scheitern (außer der Computer hat auch in der DNS-Zone x.mydomain.at ein A-Rechord oder einen CNAME). Und genau das war das Problem. Legacy Logon Scripts werden aus historischen Gründen anscheinend via \\Servername\NETLOGON\... oder \\%LOGONSERVER%\NETLOGON\... aufgerufen. Hallo NT4 ;-)

Meldet sich ein User aus der Domain y.mydomain.at auf einem Rechner an, der in der DNS-Suchreihenfolge die DNS-Zone y.mydomain.at nicht eingetragen hat, dann kann der Pfad zum Logon Script nicht aufgelöst werden (das erklärt dann auch den seltsam erscheinenden Versuch das Logonscript lokal zu finden) und somit wird es nicht ausgeführt.

Also schnell CNAMEs für die Domain Controller der Domain y.mydomain.at in der DNS-Zone x.mydomain.at angelegt und alles war gut :-)

(RaiZl)

Windows Firewall Regeln

Wer komplexe Firewall-Regeln mit vielen IP Adressen oder ähnlichem erstellen muss, wird mit dem GUI schnell narrisch. Daher habe ich mich auf die Suche gemacht und festgestellt, dass die Firewall-Regeln in der Registry gespeichert werden und sich dort ausgezeichnet manipulieren lassen.

Die Regeln finden sich hier:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Die Regel für den Internet Information Server (IIS) auf Port 80 sieht z.B. so aus:

v2.22|Action=Allow|Active=TRUE|Dir=In|Protocol=6|LPort=80|App=System|Name=@%windir%\system32\inetsrv\iisres.dll,-30500|
Desc=@%windir%\system32\inetsrv\iisres.dll,-30510|EmbedCtxt=@%windir%\system32\inetsrv\iisres.dll,-30501|

Eine Regel zum Blocken bestimmter IP Adressen und ganzer Subnetze sieht z.B. so aus:

v2.20|Action=Block|Active=TRUE|Dir=In|RA4=192.168.125.0/255.255.255.0|RA4=192.168.124.34|RA4=192.168.126.223|Name=Block stupid people|

Es empfiehlt sich, die Regel via GUI anzulegen, und dann zusätzliche Adressen in der Registry hinzuzufügen.

(RaiZl)

CAPI2 Fehler während VSS Backup

Seit geraumer Zeit sichere ich unsere wichtigsten Daten - nebst doppelter Datenhaltung Vorort - mittels Livedrive  in die Cloud. Die zugehörige Software besteht aus einem Desktop-Programm und dem "Livedrive VSS Service". Seit einiger Zeit tauchten bei jedem Backup im Eventlog Einträge folgender Art auf:

20151128_capi2.jpg

 

Die darauf folgende Google-Recherche brachte folgendes als Ursache zum Vorschein:

During backup a VSS process running under NETWORK_SERVICE account calls cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), which enumerates all the drivers records in Service Control Manager database and tries opening each one of them. , The function fails on MSLLDP record with "Access Denied" error.

Turned out it fails because MSLLDP driver's security permissions do not allow NETWORK_SERVICE to access the driver record.

In meinem Fall ging es zwar nicht um den Account "NETWORK_SERVICE", aber das Problem war ansonsten identisch. Wer sich den Security Descriptor ansehen will, kann dies mit dem Sysinternals-Tool AccessChk bewerkstelligen und somit leicht feststellen, welcher Eintrag im Security Descriptor fehlt oder falsch ist (sprich der jeweilige Service Account unter dem das Service läuft).

accesschk.exe -c mslldp

Mittels System-Tool "sc" kann der Security Descriptor vom MSLLDP Treiber neu geschrieben werden (Achtung: der unten angegebene String muss nicht für jeden Fall ident sein, also vorsicht damit, eventuell den original Security Descriptor vorher sichern mittels "SC sdshow MSLLDP"):

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)

Schaut wild aus, ist es auch ;-).

Wenn es geklappt hat sollte "sc" wie im Screenshot ersichtlich mit "[SC] SetServiceObjectSecurity SUCCESS" reagieren:

20151128_mslldp-sc.jpg

AccessChk liefert nun folgendes:

C:\WINDOWS\system32>accesschk.exe -c mslldp

Accesschk v6.0 - Reports effective permissions for securable objects
Copyright (C) 2006-2015 Mark Russinovich
Sysinternals - www.sysinternals.com

mslldp
RW NT AUTHORITY\SYSTEM
RW BUILTIN\Administrators
RW S-1-5-32-549
R NT SERVICE\NlaSvc
R NT AUTHORITY\SERVICE

Inzwischen ist bereits ein weiteres Backup gelaufen und es wurde kein neues CAPI2 Event erzeugt.

(RaiZl)

Curl testet Microsoft Exchange

Wer Microsoft Exchange betreiben muss, sieht sich schnell mit der Frage konfrontiert, wie man selbiges überwachen kann, ohne Unsummen von Geld in die Hand nehmen zu müssen. Im Windows-Umfeld gibt es unzählige Möglichkeiten, will man das von Linux aus bewerkstelligen, muss man mittels curl nur die entsprechenden Requests absetzen.

ActiveSync

curl -v -k -u domain\\username:password -H "Host:your.fully.qualified.hostname" --request OPTIONS https://ipaddress/Microsoft-Server-ActiveSync
20151021_curl_activesync.JPG Der retournierte Antwort-String auf den OPTIONS-Befehl muss wie im Screenshot  aussehen (siehe Markierung). Kommt eine davon abweichende Antwort ist davon auszugehen dass ein Problem vorliegt.

Outlook Anywhere (RPC over HTTP)

curl -v -k --request RPC_IN_DATA -A MSRPC -u domain\\username:password -H "Host:your.fully.qualified.hostname" http://ipaddress/rpc/rpcproxy.dll?your.fully.qualified.hostname:6001
20151021_curl_outlookanywhere.JPG In diesem Fall kann auf die Antwort "200 Success" geprüft werden, liefert der Server ein andere Code/Return-String Kombination, dann liegt vermutlich ein Fehler vor.

Outlook Web App

curl -v -k -u domain\\username:password -H "Host:your.fully.qualified.hostname" http://ipaddress/owa/auth/logon.aspx?url=https://your.fully.qualified.hostname/owa/&reason=0
20151021_curl_outlookanywhere.JPG In diesem Fall kann auf die Antwort SetCookie "OutlookSession=" geprüft werden. Kommt vom Exchange Server eine andere Meldung retour, sprich es kann keine Outlook Session gestartet werden, dann liegt ein Fehler vor.

Die oben angeführten Curl-Statements können relativ einfach in Scripts eingebaut werden, die im Fehlerfall entsprechend Alarm schlagen (e-Mail, etc.).

(RaiZl)