Blogengine.net, Standard-Theme und Kommentare

Blogengine.net hat seit dem letzten Release ein wirklich tolles Standard-Theme (dieses hier nämlich). Leider musste ich feststellen, dass man damit keine Kommentare zu den geposteten Beiträgen abgegeben kann. Da mich das irrsinnig genervt hat, bin ein wenig stöbern gegangen und wurde tatsächlich fündig. Mit nur minimalem Aufwand kann man im Standard-Theme die Kommentarfunktion aktivieren.

Dazu muss die Datei "\Custom\Themes\Standard\PostView.ascx" geändert werden.

Auszug Original-Datei:

<%@ Control Language="C#" AutoEventWireup="true" EnableViewState="false" Inherits="BlogEngine.Core.Web.Controls.PostViewBase" %>
<%@ Import Namespace="BlogEngine.Core" %>

<article class="post" id="post<%=Index %>">
    <header class="post-header">
        <h2 class="post-title">
            <a href="<%=Post.RelativeOrAbsoluteLink %>"><%=Server.HtmlEncode(Post.Title) %></a>
        </h2>
        <div class="post-info clearfix">
            <span class="post-date"><%=Post.DateCreated.ToString("dd MMMM yyyy") %></span>
            <span class="post-author"><a href="<%=Utils.AbsoluteWebRoot + "author/" + Utils.RemoveIllegalCharacters(Post.Author + BlogConfig.FileExtension) %>"><%=Post.AuthorProfile != null ? Utils.RemoveIllegalCharacters(Post.AuthorProfile.DisplayName) : Utils.RemoveIllegalCharacters(Post.Author) %></a></span>
            <span class="post-category"><%=CategoryLinks(", ") %></span>
        </div>
    </header>

Vor "</div>" müssen 2 Zeilen hinzugefügt werden:

<a class="post-comment" rel="nofollow" href="<%=Post.RelativeOrAbsoluteLink %>#comment"><%=Resources.labels.comments %> (<%=Post.ApprovedComments.Count %>)</a>
<script type="text/javascript">$('#post<%=Index %> .post-category:has(a)').append('<span class="separator"></span>');</script>

Das geänderte PostView.ascx sollte nun so aussehen:

<%@ Control Language="C#" AutoEventWireup="true" EnableViewState="false" Inherits="BlogEngine.Core.Web.Controls.PostViewBase" %>
<%@ Import Namespace="BlogEngine.Core" %>

<article class="post" id="post<%=Index %>">
    <header class="post-header">
        <h2 class="post-title">
            <a href="<%=Post.RelativeOrAbsoluteLink %>"><%=Server.HtmlEncode(Post.Title) %></a>
        </h2>
        <div class="post-info clearfix">
            <span class="post-date"><%=Post.DateCreated.ToString("dd MMMM yyyy") %></span>
            <span class="post-author"><a href="<%=Utils.AbsoluteWebRoot + "author/" + Utils.RemoveIllegalCharacters(Post.Author + BlogConfig.FileExtension) %>"><%=Post.AuthorProfile != null ? Utils.RemoveIllegalCharacters(Post.AuthorProfile.DisplayName) : Utils.RemoveIllegalCharacters(Post.Author) %></a></span>
            <span class="post-category"><%=CategoryLinks(", ") %></span>
            <a class="post-comment" rel="nofollow" href="<%=Post.RelativeOrAbsoluteLink %>#comment"><%=Resources.labels.comments %> (<%=Post.ApprovedComments.Count %>)</a>
            <script type="text/javascript">$('#post<%=Index %> .post-category:has(a)').append('<span class="separator"></span>');</script>
        </div>
    </header>

Speichern, im Browser F5 drücken und freuen. ;-)

 

Outlook Drag and Drop

Ich war schon öfter in der Situation, dass im Outlook Drag and Drop plötzlich nicht mehr funktioniert hat. Ohne jeden ersichtlichen Grund. Bis dato war der Leidensdruck nicht groß genug und ich habe es ignoriert, wenig später hat es genauso plötzlich wieder getan. Heute hats mir gereicht und ich hab mich auf die Suche gemacht. Mit einer einfachen Lösung habe ich eigentlich nicht gerechnet, im Gegenteil, ich bin davon ausgegangen dass das Problem nur schwer einzugrenzen sein wird.

Ich habe einen Artikel gefunden wo es um dieses Thema geht (hier). Ich habe ihn gelesen, und dachte mir: "Nein, einfach ESC drücken kann nicht die Lösung sein". Da man aber nichts unversucht lassen soll hab ich es dann doch probiert und siehe da, Drag and Drop funktioniert auf einmal wieder. Ich hab mir kräftig die Augen gerieben und selbst in den Arm gezwickt, um sicher zu gehen, dass ich eh munter bin. ;-)

Bitlocker AD Backup

Das ist eine Notiz für mich selbst, damit ich nicht später danach suchen muss, falls ich es wieder benötigen sollte. Bitlocker kann seine Recovery Information im Active Directory speichern. Wenn die Infos jedoch aus irgendeinem Grund fehlen, heisst das nicht, dass man das bzw. die verschlüsselten Laufwerke wieder entschlüsseln muss. Mit 2 kurzen Befehlen können die Recovery Informationen im AD aktualisiert werden.

manage-bde -protectors -get c:

20160818-Bitlocker-01.png

manage-bde -protectors -adbackup c: -id  '{<numerical password ID>}'

20160818-Bitlocker-02.png

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)