Today is a sad day. RIP Prince.

I never meant to cause you any sorrow
I never meant to cause you any pain
I only wanted one time to see you laughing
I only wanted to see you laughing in the purple rain

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.

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)

Seit Wochen warte ich nun, dass der Konzert Termin für den Boss in Wien bestätigt wird, doch leider Fehlanzeige. Bruce Springsteen wird 2016 wohl doch nicht nach Österreich kommen. Sehr schade, aber ein echter Boss Fan hat sowieso mit einem einzigen Konzert nicht genug, weshalb ich mir Tickets für München und Berlin besorgt habe:

(Austrian Bossfan)

Nach dem 0:4 gegen die Admira ist ein trauriger Höhepunkt erreicht. Selten habe ich mich für einen Auftritt meines Herzensvereins so geschämt (dunkle Erinnerungen an ein 0:4 gegen den GAK kommen wieder zum Vorschein).

Zoran Barisic: "Wir sind nicht so gut, wie uns andere machen".
Meine Antwort: "Wir sind nicht so schlecht wie uns Trainer Barisic macht".

Ich hatte bereits im August 2014 nach dem Europacup-Ausscheiden gegen Helsinki genug, mit diesem Trainer kann man keine Titel gewinnen. Bin gespannt wie lange es noch dauert, bis die Rapid-Verantwortlichen das auch erkennen.

(RaiZl)

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)