Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Erreur d’exécution du rapport “EV FSAReporting Daily Job”

Introduction

Vous êtes dans la configuration suivante ?

  • Enterprise Vault 10.0.3 Anglais sur Windows 2008 R2 FR
  • Serveur SQL Server 2012 Français sur Windows 2008 R2 FR

Vous rencontrez des problèmes d’exécution de job SQL, notamment l’erreur 3621 sur le job « EV FSAReporting Daily Job » ? Voici un extrait de l’historique des jobs SQL :

Date                        24/05/2013 15:18:07

Journal                    Historique des travaux (EV FSAReporting Daily Job VSGFSAReport)

ID de l’étape           1

Serveur                   SRV-SQL

Nom du travail       EV FSAReporting Daily Job VSGFSAReport

Nom de l’étape      Start

Durée                      00:00:00

Gravité SQL            16

ID de message SQL 3621

Message

Exécuté en tant qu »utilisateur : Domain\EVSQLService. La conversion d’un type de données varchar en type de données datetime a créé une valeur hors limites. [SQLSTATE 22007] (erreur 242)  L’instruction a été arrêtée. [SQLSTATE 01000] (erreur 3621).  L’étape a échoué.

 

Solution

L’erreur SQL de conversion de type de données est dû à la langue de l’environnement. Enterprise Vault étant installé en anglais sur un serveur SQL en français, celui ci ne comprend pas les formats (date notamment) et retourne donc cette erreur de conversion.

Dans SQL Management Studio, Sécurité, Connexions, éditez les propriétés de l’utilisateur qui exécute le rapport (EVSQLService dans notre cas), changez la langue par défaut de French en English.

Vérification

Relancez le job « EV FSAReporting Daily Job » et observez le résultat dans l’historique des travaux SQL :

Date                        24/05/2013 15:52:10

Journal                    Historique des travaux (EV FSAReporting Daily Job VSGFSAReport)

ID de l’étape           1

Serveur                   SRV-SQL

Nom du travail       EV FSAReporting Daily Job VSGFSAReport

Nom de l’étape      Start

Durée                      00:00:00

Gravité SQL            0

ID de message SQL 0

Message

Exécuté en tant qu »utilisateur : Domain\EVSQLService. L’étape a réussi.

Les rapports vont pouvoir fonctionner correctement maintenant.

Archivage FSA avec Enterprise Vault

Introduction

Lors de l’archivage d’un serveur de fichier avec Enterprise Vault (v10.0.3), on peut rencontrer certains problèmes : Impossible de joindre le serveur, problème de package de sécurité, etc…

Les symptômes :

Sur le serveur EV (Win2008R2), lorsque vous essayez d’afficher les propriétés du serveur de fichiers (ex : Win2003), dans l’onglet version, impossible de récupérer la version de l’agent FSA :

clip_image002

Ou alors, impossible d’exécuter le FSA Reporting Scan manuellement :

clip_image003

Vérifications

Après avoir vérifié les fondamentaux :

  • les noms de serveurs peuvent être résolu des deux côtés et les adresses IP correspondent  à la configuration des serveurs
  • vérification du parefeu
  • le compte de service Enterprise Vault est bien administrateur local du serveur de fichiers

     

    Résolution

    La commande suivante peut vous aider, (à saisir dans une console avec les droits administrateur) sur le serveur EV:

    SETSPN –A RPC/<nom_du_serveur_de_fichiers> <domaine>\<compte_de_service_EV>

    Exemple : SETSPN –A RPC/fileserver mydomain\ev_svc

    Une fois la commande saisi, on récupère bien les informations de l’agent FSA et la communication avec le serveur se fait sans problème. L’incident est résolu.

    clip_image004

  • Contrôle à distance de Sharepoint via Powershell

    Introduction

    L’une des forces de Powershell est de pouvoir administrer des produits directement depuis un poste client sans avoir à installer des outils d’administration. Hormis dans certains cas particuliers comme Exchange Online, il n’est pas non plus nécessaire d’ajouter des modules ou snapin Powershell sur notre ordinateur. Ceux-ci sont déjà présents sur le serveur distant, il est donc possible de les réutiliser. Dans cet article nous verrons le cas de Sharepoint pour lequel j’ai rencontré une petite subtilité.

    Connexion à distance

    Tout d’abord nous allons initier une nouvelle PSSession. Pour rappel, ce sont elles qui nous permettent d’interagir avec un serveur à distance. Elles ont été introduites à partir de Powershell v2.0.

    On commence par stocker les paramètres d’authentification dans une variable.

    $Credential = Get-Credential

    On crée une variable avec le serveur sur lequel on souhaite se connecter

    $Server =  "XXXXXXXXXX"

    On génère une nouvelle PSSession en spécifiant les deux paramètres précédents. Celle-ci est stocké dans une variable car nous allons la réutiliser.

    $Session = New-PSSession –ComputerName $Server -Credential $Credential

    Ensuite, nous allons utiliser, la Cmdlet Invoke-Command afin d’exécuter une commande dans la session distante que nous venons de créer.

    Invoke-Command -ScriptBlock {$ver = $host | select version; if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}; Add-PSSnapin Microsoft.SharePoint.PowerShell;} -Session $Session

    Il est nécessaire de préciser la session sur lequel va être réalisé le bloc de commandes. Un scriptblock est exécuté. Si la version de Powershell est supérieur à 1 alors on positionne l’interpréteur pour réutilisé constamment le même thread. Ceci est une configuration obligatoire si l’on souhaite ajouter le snapin Sharepoint. Nous pouvons le retrouver dans le fichier “sharepoint.ps1” qui est lancé par le Sharepoint Management Shell.

    Enfin nous pouvons importer la session. Avec cette méthode l’intégralité des commandes sera utilisable directement depuis le poste client.

    Import-PSSession $Session -AllowClobber

    Erreur rencontrée

    Lorsque l’on effectue une connexion a distance il se peut que l’on obtienne l’erreur suivante :

    Import-PSSession : L’exécution de la commande Get-Command dans la session à distance a signalé l’erreur suivante: Le traitement de données pour une commande distante
    a échoué avec le message d’erreur suivant: <f:WSManFault xmlns:f="
    http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="3762507597"
    Machine="XXXXXXXXXXXXXXXXXXX"><f:Message><f:ProviderFault provider="microsoft.powershell"
    path="C:\Windows\system32\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> Pour plus d’informations, voir la rubrique d’aide
    about_Remote_Troubleshooting…

    Cette dernière signifie qu’il n’y a pas assez de mémoire disponible pour charger les commandes. En effet, les commandes Sharepoint sont très consommatrice en mémoire. Bien entendu, il existe un paramétrage pour pallier à ce problème.

    Paramétrage serveur

    Afin de corriger cette erreur, il faut augmenter la quantité de mémoire maximum allouée pour un shell distant. Il est recommandé pour Sharepoint de définir cette valeur à 1000 MB.

    Pour réaliser cette étape il suffit de modifier la valeur MaxMemoryPerShellMB via le provider WSMan permetant d’accéder à la configuration des connexions distantes. Par défaut la valeur est à 100 MB.

    Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000