PI Services

Le blog des collaborateurs de PI Services

Windows Server 2012 - Active Directory Recycle Bin avec interface graphique (GUI)

Déjà présente depuis 2008R2 la corbeille AD permet de récupérer des objets accidentellement effacés.

Avec Windows Server 2012, l’utilisation de la corbeille se simplifie avec une interface graphique.

Prérequis à l’activation

Pour activer la corbeille avec GUI, il faut avoir une forêt avec un niveau fonctionnel 2008R2 ou supérieur. Vous pouvez vérifier le niveau fonctionnel de la forêt avec la commande PowerShell suivante :

Get-ADForest | Select forestmode

image

Activation de la corbeille

Attention, l’activation de la corbeille sur 2008R2 ne permet pas le retour au niveau fonctionnel 2008.

La corbeille AD étant par défaut désactivée il faut l’activer à l’aide de la commande suivante :

image

image

Utilisation de la corbeille

La corbeille est activée, il est maintenant possible de tester son fonctionnement avec l’interface GUI :

Supprimez un objet de l’AD

image

Puis lancez l’Administrative Center et sélectionnez le container “Deleted Objects

image

Il suffit de sélectionner l’objet à restaurer puis cliquez sur “Restore” (“Restore To” permet de choisir l’OU dans laquelle l’objet sera restauré)

image

L’objet est maintenant de nouveau disponible dans l’AD.

Pour aller plus loin dans l’utilisation de la corbeille AD et utiliser des fonctions tel que la restauration de tous les objets en fonction de la date et de l’heure de la suppression, je vous conseille les liens suivants :

- http://blogs.technet.com/b/askds/archive/2009/08/27/the-ad-recycle-bin-understanding-implementing-best-practices-and-troubleshooting.aspx

- http://technet.microsoft.com/en-us/library/dd379481(v=ws.10).aspx

BlogEngine.NET en Haute-Disponibilité

 

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 :

image

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

Exchange 2010 – Erreur Get-OwaVirtualDirectory

Symptômes

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

error_get-ovd

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.

Exchange 2010 SP1 - Problème de synchronisation ActiveSync sur un iPhone4S

Symptômes

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

photo

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”.

 s-mail-01p - Connexion Bureau à distance

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).