PI Services

Introduction

Les vues dans SharePoint 2010 permettent la visualisation des éléments des bibliothèques et des listes; par défaut toute bibliothèque dispose d’un affichage (View) nommé Tous les documents, pour les liste cette affichage par défaut s’appelle Tous les éléments.

SharePoint nous permet aussi de créer nos propres affichage et de les personnaliser   

L’affichage par défaut permet d’afficher les éléments sous forme d’une liste comme le montre la figure suivante :

Lors de la création de nouveaux affichage nous avons la possibilité d’appliquer des filtres, de changer l’apparence des lignes et aussi de regrouper les éléments sauf que la personnalisation offerte au niveau de l’explorateur par SharePoint ne nous permet pas de regrouper les données par plus de deux colonnes

Problématique 

Le regroupement des éléments d’une liste ou une bibliothèque avec plus de deux colonnes ne nous ai pas permis via l’interface web de SharePoint, par contre nous pouvons répondre à ce besoin en utilisant SharePoint Designer, cet article et au niveau de la section suivante va détailler cette procédure.                     

Comment faire ?

• Créer un nouvel affichage basé sur l’affichage standard pour la bibliothèque de document ( dans notre exemple nous allons l’appeler Regroupement Personnalisé)

• Ouvrir le site avec SharePoint Designer et procéder à la modification de la vue Regroupement Personnalisé en double cliquant sur celle-ci depuis la liste des Vues   

• Au niveau de la page supprimer le composant WebPartPages:XsltListViewWebPart

• A la place du composant WebPart supprimé insérer une vue de données vide

• Cliquer sur Click here to select a data source

• Sélectionner la bibliothèque comme source de données 

• Sélectionner les champs à afficher depuis la fenêtre Data Source Details

• Insérer les champs sélectionner en choisissant Multiple Item View

• Depuis l’onglet Options cliquer sur Sort & Group

• Ajouter les colonnes que vous voulez utiliser pour le regroupement
 

• Pour personnaliser l’entête des groupes cliquer sur Edit Sort Expression  et tapez la formule qui permettra d’afficher l’entête souhaité, par exemple nous voulons que l’entête du regroupement par Version du produit affiche aussi le nom du produit il suffit de taper la formule concat(@Produit , " - ", @Version_x0020_Produit) 

Faire la même chose pour les autres groupements pour personnaliser les entêtes   

• Ainsi nous avons une vue de la bibliothèque avec des regroupements de plus de deux niveaux 

Autre actions de personnalisation

Changer le nom du document en lien

• Avec le bouton droit de la souris cliquer dans la case du nom du fichier et ensuite cliquer sur le menu Format item as ==> Hyperlink 

• Au niveau de la cas Adresse cliquer sur le bouton fx

•  Sélectionner Chemin d’URL depuis la liste des éléments puis cliquer sur Ok

1. Vérifier que la champ Text to display {@FileLeafRef.Name} et l’Adresse  {@FileRef}

Microsoft met à disposition un outil qui permet de vérifier la configuration du

client Outlook et de détecter un potentiel problème, Microsoft Outlook Analyzer Configuration Tool.

Cet outil est de la même famille que l’outil  Microsoft Exchange Best Practices Analyzer.

L’interface sera donc familière aux administrateurs d’Exchange 2010.

Télécharger l’outil depuis ce lien:

http://www.microsoft.com/download/en/details.aspx?id=28806

Après avoir installé l’outil, exécutez une analyse (outlook doit être démarré).

Après quelques clics vous obtiendrez un rapport:

Analysez et corrigez éventuellement les problèmes.

Symptôme

Suite à la migration d’une boîte aux lettres Exchange Server 2003 SP2 vers un DAG Exchange 2010 SP1 RU6 (en environnement intra-organisationnel),  l’utilisateur ne peut plus synchroniser ses emails via ActiveSync et l’erreur suivante se produit régulièrement dans le journal Application du serveur CAS :

Voici le détail de l’erreur rencontrée :

De plus l’utilisateur ne peut pas voir son téléphone lorsqu’il accède à l’interface ECP (Exchange Control Panel) dans le menu Phone, puis Mobile Phone.

Explication

Avec Exchange Server 2003 les partenariats ActiveSync sont stockés dans un dossier caché au sein de la boîte aux lettres de l’utilisateur.

Ce dossier se nomme Microsoft-Server-ActiveSync et est visualisable à l’aide d’un outil tel que MFCMAPI (http://mfcmapi.codeplex.com/).

Avec Exchange Server 2010 les partenariats ActiveSync sont stockés directement dans l’annuaire Active Directory sous la forme d’un objet de type msexchangeActiveSyncDevice.

Lors de la migration de la boîte aux lettres vers Exchange Server 2010 le serveur Exchange possédant le rôle CAS doit donc créer un conteneur nommé CN=ExchangeActiveSyncDevices dans le compte utilisateur. Le serveur CAS créé ensuite un objet de type msexchangeActiveSyncDevice dans ce conteneur pour chaque partenariat ActiveSync établit.

Voici un exemple d’objet msexchangeActiveSyncDevice généré dans un environnement Exchange Server 2010 :

Dans notre exemple l’héritage des autorisations étaient désactivé sur le compte utilisateur. Cela a empêché la descente des ACL nécessaires au bon fonctionnement d’Exchange et donc a provoqué le message d’erreur 1053 Access is Denied sur le serveur CAS.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Server 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 versions 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 Sony Ericsson sous Symbian avec l’application RoadSync. 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” (comprendre celle engendrant la génération des objets dans l’annuaire Active Directory) du téléphone fonctionnera ainsi que toutes les synchronisations ultérieures.

Une fois la première synchronisation effectuée l’utilisateur pourra visualiser et gérer ses partenariats ActiveSync dans l’interface ECP (la capture d’écran ci-dessous est un exemple).

Remarque : Il est intéressant de noter que le mécanisme AdminSDHolder remodifiera 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).

Le passage du SP2 apporte une correction à certains problèmes mais apporte

également son lot de disfonctionnement tel que celui-ci.

Pour certains besoins il est parfois nécessaire de reconnecter une boîte aux

lettres à un compte. Avant le passage du SP2 la boite est fonctionnelle dès

sa reconnexion à un compte utilisateur.

Après le passage du SP2 vous pourrez obtenir cette erreur détectable

lorsqu’on envoie un message à la boite présente dans la GAL:

Échec de la remise pour ces destinataires ou groupes :
Dupont Jean (jean.dupont@bug.fr) <mailto:jean.dupont@bug.fr>
La boîte aux lettres du destinataire pose un problème. Essayez de renvoyer ce message. Si le problème persiste, contactez le support technique de votre organisation.
Informations de diagnostic pour les administrateurs :
Serveur de génération : SERV01.bug.fr
jean.dupont@bug.fr
#554-5.2.1 mailbox disabled 554 5.2.1 STOREDRV.Deliver.Exception:AccountDisabledException.MapiExceptionMailboxDisabled; Failed to process message due to a permanent exception with message Cannot open mailbox /o=MSG/ou=Exchange Administrative Group

On ne peut pas également déplacer la boîte de banque !

On constate également que la boite a toujours le statut “disabled”

PS C:\Windows\system32> Get-MailboxStatistics JDUP | fl

AssociatedItemCount     : 67

DeletedItemCount        : 2010

DisconnectDate          : 16/02/2012 08:54:26

DisconnectReason        : Disabled

Réalisez les mêmes tests le lendemain matin et vous observerez que tout est

rentré dans l’ordre. La nuit porte conseille…..

Par défaut Exchange effectue une maintenance nocturne planifiée.

Les processus réalisés diffèrent de la maintenance de type “background”.

Durant cette maintenance nocturne une vérification des banques d’informations et

particulièrement des objets supprimés est réalisée.

C’est cette mécanique qui rend de nouveau la boîte opérationnelle.

Microsoft apportera cette correction dans le RU3 pour Exchange 2010 SP2, il faut

donc patienter quelques mois, incident mineure pour Microsoft….

Dans l’attente de ce correctif il faut donc réaliser un nettoyage de la banque

après avoir reconnecté la boite (clean-mailboxdatabase).

Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:

l’execution d’une GPO a échoué pour ce compte.

Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.

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.

J’ai récemment été confronté à une situation complexe sur une architecture Symantec Messaging Gateway composée de trois nœuds :

• Deux boitiers scanners
• Un boitier control center

Le boitier control center était hors service (interface Web inaccessible); or, au même moment l’un de deux boitiers scanner était victime d’un problème de remise de messages (files d’attente Inbound et Outbound avec plusieurs milliers de messages en attente de traitement).

Dans ce cas de figure la seule méthode disponible pour administrer le boitier scanner (en l’absence de l’interface Web habituellement disponible sur le control center) consiste à prendre en la main en mode console (soit physiquement sur le serveur, soit à distance avec un client SSH comme putty).

Dans ce cas de figure, les trois commandes les plus importantes pour gérer les files d’attente sont les suivantes :

• mta-control qui permet de gérer les files d’attente et de reconfigurer la pile MTA
• monitor qui permet d’afficher le statut des files d’attente ainsi que le nombre de mail dans chaque file
• service qui est une commande Linux standard permettant de redémarrer les services (dont le service MTA)

Voici quelques exemples de commandes :

mta-control pause-mode status (permet d’afficher le statut de la pile MTA)

mta-control pause-mode pause-accept (reconfigure la pile MTA pour ne plus accepter les nouveaux messages; les messages toujours en file sont scannés, puis envoyés)

mta-control pause-mode resume-accept (permet de revenir en arrière)

monitor mta (permet d’afficher l’état des différentes files; i_qmsgs correspond au nombre de message dans la file Inbound, o_qmsgs correspond au nombre de message dans la file Outbound et enfin d_qmsgs correspond au nombre de messages dans la file Delivery)

mta-control delivery flush (permet de forcer la réémission des messages bloqués dans la file d’attente Delivery)

service mta restart (permet de redémarrer le service MTA)

La problématique

J’ai récemment rencontré la problématique suivante sur un serveur TMG 2010 SP2 : suite à des problèmes matériels (plantages répétés du serveur) le service pare-feu refuse de démarrer.

La base de données AD LDS étant toujours accessible, il est toujours possible de se connecter à la console TMG et donc je réalise un export de la configuration de la ferme de serveurs.

Le dépannage du problème de démarrage sur le service TMG semblant complexe à résoudre décision est prise de désinstaller TMG, puis de le réinstaller et enfin d’importer la configuration précédemment sauvegardée au format XML.

Lors de l’import de la configuration sur le serveur fraichement réinstallé, l’erreur suivante s’est produite dans l’assistant d’importation de TMG :

Import Failed

The value specified for the parameter Scope is not valid for standalone mode.

Résolution apportée

La solution apportée n’est pas une solution très académique est plutôt à classer dans la catégorie des contournements :

Pour résoudre l’ensemble des balises Scope ont été supprimées manuellement dans le fichier de configuration à l’aide d’un éditeur de fichier XML (ici Notepad++).

La balise complète a été supprimée à chaque fois.

Suite à cette modification l’importation s’est terminée correctement et l’ensemble des services et des règles ont pu repartir en production.

Ce problème étant très spécifique je suppose que l’erreur rencontrée était due à la présence d’un reliquat de configuration ISA Server 2006 dans le fichier XML précédemment exporté.