Présentation de BlogEngine.NET

BlogEngine.NET est une plateforme de blog open-source développé en C#, elle permet entre-autres la gestion des auteurs, des posts et ne requiert ni base de donnée ni installation.

Toutes les fonctionnalités ici.

Contexte

Pour la configuration de serveurs WEB en Haute-Dispo, il est possible de créer entre les serveurs une réplication des dossiers de BlogEngine à l’aide de DFS-R.

Suite à la mise en place de la réplication DFS-R entre les deux serveurs Web, une latence d’environ une heure lors de l’ajout (ou la modification) d’un post à partir d’un serveur et la visualisation sur le second est apparue.

Cette latence n’est pas due à DFS-R car au niveau du système il est visible que le post (enregistré au format XML) a correctement été répliqué.

Explication

Afin d’assurer un temps de réponse optimal, BlogEngine dispose d’un cache interne qui est mis à jour automatiquement.

Résolution

Pour de palier à ce problème il suffit de modifier la page default.aspx.cs située à la racine du répertoire de BlogEngine en ajoutant au début de la fonction Page_Load() la commande BlogEngine.Core.Post.Reload() comme ceci :

Ce qui permettra à chaque fois que l’utilisateur se connecte sur la page Accueil, de recharger le cache.

Symptômes

Lors de l’exécution de la commande Get-OwaVirtualDirectory l’erreur “800706ba” apparait :

Et ce malgré la bonne configuration des Client Access Servers et le lancement du service IIS sur ces derniers.

On remarque également que désactiver le pare-feu sur les serveurs CAS résout le problème rencontré.

Cause

Cette erreur est causée par le blocage du pare-feu Windows.

Résolution

Afin de résoudre cette erreur tout en gardant le pare-feu actifs il faut créer une nouvelle règle au niveau pare-feu :

1. Selectionner “new inbound rule”
2. Choisir comme type "custom"
3. Choisir "All Programs"
4. Protocol type: "TCP",  Local port: "Dynamic RPC",  Remote ports: "All ports"
5. Adresses IP : “Any to Any”
6. Action : “Allow connection”
7. Profil : "Domain"
8. Nom : "Dynamic TCP incoming" (le nom n’importe pas).

Cette règle doit être créée sur le pare-feu de tous les serveurs CAS.

A noter que Rollup Update 6 ne résout pas ce problème.

Symptômes

L'iPhone ne peut pas se connecter au serveur de messagerie et l’erreur suivante se produit sur le terminal mobile.

De plus dans les logs IIS sur le serveur CAS Exchange 2010 on peut voir que la requête HTTP arrive bien sur le serveur et que son code de retour est bon (code HTTP 200). Néanmoins l’erreur suivante est visible dans la colonne cs-uri-query du log IIS :

“Error:DeviceNotProvisioned”.

Cause

Dans notre exemple le problème de synchronisation n’était pas dû à une configuration Exchange 2010 mais à l’héritage des autorisations dans l’annuaire Active Directory qui était désactivée sur le compte utilisateur.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Account Operators” qui est l’un des groupes protégé par le mécanisme AdminSDHolder.

Pour mémoire ce mécanisme a pour but de contrôler les ACL appliquées sur les objets (comptes utilisateurs, comptes ordinateurs…) membres des groupes protégés.

La liste des groupes protégés par le mécanisme AdminSDHolder dans les différentes version de Windows (de Windows 2000 Server à Windows Server 2008 R2) est disponible sur le site de Microsoft à l’adresse suivante :

http://technet.microsoft.com/en-us/query/ee361593

Remarque : Dans notre cas le téléphone touché était un iPhone 4S. Cependant ce problème étant dû à une configuration au niveau du compte Active Directory tout autre téléphone pourrait en être victime.

Résolution

Pour résoudre ce problème il faut se connecter à l’ADUC (Console “Utilisateurs et ordinateurs Active Directory”), puis dans les propriétés de l’utilisateur concerné choisir “Security”, “Advanced” puis cocher la case “Include inheritable permissions from this object’s parent”.

Suite à cette manipulation la synchronisation initiale de l’iPhone fonctionnera ainsi que toutes les synchronisations ultérieures.

Il est intéressant de noter que le mécanisme AdminSDHolder re-modifiera automatiquement les ACL (et donc re-désactivera l’héritage des autorisations) dans un délai d’une heure maximum (en effet le processus s’exécute toutes les 60 minutes par défaut).