Frage an den Trainer, ob er Deni Alars Wechsel aufhalten will: „Wenn möglich schon. Er ist ein sehr guter Spieler, der auf allen offensiven Positionen eine sehr gute Leistung bringen kann“.

Ein Thema das mich seit Wochen beschäftigt, und ich verstehs einfach nicht... Deni hat schon bewiesen was er kann, hat alles gegeben für Rapid, bis ihn zwei schwere Verletzungen zurück geworfen haben. Letzte Saison musste er sich dann hinter Robert Beric, diese Saison nach dem Beric-Wechsel hinter Prosenik, Jelic und jetzt auch Tomi anstellen. Wenn er sproadisch eingesetzt wird, dann praktisch nur im Mittelfeld. Es gab schon letzten Sommer und im Winter Gerüchte über einen Wechsel, da hörte man aber "Deni will sich bei Rapid durchsetzten", der Beweis für eine Top Einstellung. Schwer umsetzbar wenn man keine Chancen bekommt.

Wie lange soll er noch auf der Bank versauern? Deni ist jetzt 26 Jahre, langsam wird es Zeit dass er wieder konstant Spiele bestreiten darf. Wenn das bei Rapid nicht möglich ist, dann verstehe ich, dass er wechseln will. Mir persönlich würde das sehr leid tun, ich mag den Deni irrsinnig gern und halte ihn für einen ausgezeichneten Spieler.

Wie auch immer die Entscheidung im Endeffekt ausfallen wird, für mich gilt "In Deni I trust". Was ich vom Trainer nicht behaupten kann.

UPDATE: inzwischen wurde der Wechsel von Deni Alar zu Sturm Graz bekannt gegeben. Danke Herr Barisic! Deni wünsche ich alles Gute für die Zukunft!

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)