PI Services

Microsoft est en train d’analyser l’existence d’une vulnérabilité dans SharePoint Services et SharePoint Server qui permet l’exécution de scripts arbitraires permettant d’effectuer une élévation des privilèges au niveau des sites SharePoint.

Les versions affectées par cette vulnérabilité sont :

• Microsoft Office SharePoint Server 2007 SP1 et SP2
• Microsoft Windows SharePoint Services 3.0 SP1 et SP2

Les deux architectures x86 et x64 sont affectées.

Pour plus de détail cliquer ici

L’emplacement par défaut des bases de données SQL Server est généralement <Dossier d'installation>\MSSQL.1\MSSQL\Data

SQL Server nous permet de modifier cet emplacement par défaut sauf qu’il faut faire attention que la procédure n’est pas la même pour les bases de données utilisateurs et les bases de données système.

Changement de l’emplacement par défaut des bases utilisateur

Pour modifier l’emplacement par défaut des base de donnés utilisateurs juste après l’installation de SQL Server :

- Ouvrir SQL Server Management Studio

- Avec le bouton droit de la souri cliquer sur Serveur | Propriétés

- Sélectionner la page Paramètres de base de données

- Au niveau de la section Emplacement de la base de données par défaut saisir les nouveau emplacements des fichiers de données et des fichiers Log

Pour réaliser cette opération on peut aussi exécuter le code T-SQL suivant :

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData', REG_SZ, N'E:\UserDB'
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'E:\UserLOG'
GO

Déplacement des bases de données systèmes

La base de données MASTER

1. Changer les paramètres de démarrage de SQL Server en utilisant SQL Server Configuration Manager (Gestionnaire de configuration SQL Server)

1. Changer le chemin du fichier master.mdf en précisant le nouveau chemin devant la commutateur –d
2. Changer  le chemin du fichier mastlog.ldf en précisant le nouveau chemin devant le commutateur –l
3. Arrêter  le service SQL Server en exécutant NET STOP MSSQLSERVER (pour une instance nommée utiliser  NET STOP MSSQL$<Nom de l’instance>)
4. Déplacer les fichier vers le nouvel emplacement
5. Démarrer le service SQL Server en exécutant NET START MSSQLSERVER

Les bases de données MSDB et MODEL

Cette procédure s’applique à la base de données MSDB et MODEL :

Les scripts mentionnés concernent la base de données MSDB et il suffit de les adapter pour MODEL.

• Démarrer un invite de commande (cmd)
• Exécuter NET STOP MSSQLSERVER
• Exécuter NET START MSSQLSERVER /c /m /T3608
• Exécuter l’utilitaire SQLCMD (il faut s’assurer que tous les autres services SQL sont arrêtés et qu’aucune application ne tente de se connecter au serveur )
• Au niveau de l’invite SQLCMD exécuter le script T-SQL Suivant :
  USE master
  Go
  sp_detach_db ‘msdb’
  Go

• Déplacer  les fichiers msdbdata.mdf et msdglog.ldf dans le nouvel emplacement
• Exécuter NET STOP MSSQLSERVER
• Exécuter  NET START MSSQLSERVER
• Lancer le script T-SQL suivant
  USE master
  Go
  sp_attach _db ‘msdb’ , ‘<nouvel emplacement>\msdbdata.mdf’, ‘<nouvel emplacement>\msdblog.ldf’
  Go

  La base de données TEMPDB

• Exécuter le script T-SQL suivant :

USE master

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = 'tempdev',FILENAME = '<new location>\tempdb.mdf')

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = 'templog',FILENAME = '<new location>\templog.ldf')

GO

• Exécuter NET STOP MSSQLSERVER
• Déplacer les fichiers tempdb.mdf et templog.ldf au nouvel emplacement
• Exécuter NET START MSSQLSERVER

Suite à la restauration de la base de données MSDB il se peut que le Service Broker ne s’active pas et ainsi on ne pourra plus utiliser certaines fonctionnalités comme la messagerie de base de données qui permet la notification des opérateurs en cas d’échec ou de réussite des travaux.

Pour résoudre ce problème il suffit de créer un nouveau Service Broker au niveau de la base de données MSDB et de l’activer pour cela il faut exécuter les trois lot T-SQL suivants :

ALTER DATABASE [MSDB] SET NEW_BROKER WITH ROLLBACK IMMEDIATE

Go

ALTER DATABASE [MSDB] SET NEW_BROKER

Go

ALTER DATABASE [MSDB] SET ENABLE_BROKER

Go

Lorsqu’un serveur Windows 2008 ou 2008 R2 est membre d’un domaine, il arrive parfois que l’on ai besoin d’ouvrir une session avec un compte local.

Dans ce cas, il est nécessaire de spécifier le nom du serveur devant le login :

<SERVEUR>\<login>

Voici une astuce permettant d’éviter la saisie du nom du serveur : utiliser le point à la place :

.\<login>

De cette manière, Windows va considérer qu’il s’agit d’une ouverture de session locale. Le nom du serveur sera même affiché (pratique lorsque l’on connait que l’IP du serveur !)

Voilà, j’espère que cette astuce vous sera utile.

Un type d’alerte dont la répétition est particulièrement indésirable est celui des erreur liés a des requêtes WMI en échec du a des problèmes de ressources système:

HRESULT: 0x800700a4
Details: No more threads can be created in the system.

HRESULT: 0x80041001
Details: Generic failure

HRESULT: 0x80041006
Details: Out of memory

En effet, la gestion de la mémoire dans WMI est assez spécifique et ces erreurs sont susceptibles d’intervenir même sur des systèmes bien dimensionnés

Cette alerte qui peut être récurrente a donc une source externe a SCOM.

Ces alertes et erreurs associées peuvent être évitées en modifiant un des paramètres WMI correspondant a la mémoire.

Pour cela, sur la machine concernée par l’erreur:

• Executez la commande wbemtest (en mode administrateur)

• Connectez vous a l’espace de nom "root" (pas "root\default", juste "root")

• Selectionnez Ouvrir une instance (ou Open an instance)

• Tapez __ProviderHostQuotaConfiguration=@ et cliquez OK

• Cochez la case “Locales seulement" (Local Only), selectionnez la propriété MemoryPerHost ou ThreadsPerHost selon la source de l’erreur (voir plus haut)

Modifiez ces valeurs de manière raisonnable (valeur double pour commencer)

• Cliquez sur Enregistrer la propriété (Save Property) puis sur Enregistrer l’objet (Save Object)

1. Redémarrer le service Windows Management Instrumentation

La version R2 de Xian Network Manager IO viens de sortir !

Au menu de la plus facile a intégrer et a configurer des solutions de supervision complémentaire de SCOM:

• La possibilité d’ajouter vos propres règles de supervision SNMP si elles ne sont pas fournis nativement dans les smart management pack de Jalasoft.

• Une interaction avec Savision liveMaps (solution de cartographie proposé en bundle avec Xian) permet désormais de découvrir automatiquement la topologie réseau et de la cartographier a partir des informations fournis par Xian.

• Calcul de seuil de performance automatique dans le même esprit que les self-tunning threshold ce SCOM

• Gestion plus intelligente des informations envoyés a SCOM afin de limiter les alertes

• Système de filtrage des composants issus des équipements réseaux afin de n’afficher dans SCOM que les objets réellement supervisés

Pré-requis et architecture

Parmis les pré-requis à la mise en place de DirectAccess, un serveur Web répondant en HTTPS est nécessaire. Ce serveur, nommé NLS pour Network Location Server, ne doit pas être joignable depuis l'extérieur. En effet, sa seule et unique fonction est de permettre aux postes clients sous Windows Seven de détecter correctement leur emplacement réseau :

• Si le serveur NLS est accessible, alors le poste client sait qu'il est connecté à l'intérieur du réseau de l'entreprise (dans ce cas, le poste ne tente pas de se connecter à l'aide des technologies DirectAccess)
• Si le serveur NLS est inaccessible, alors le poste client sait qu'il est connecté à l'extérieur (dans ce cas, le poste tente de se connecter à l'aide des technologies DirectAccess)

Le but du serveur NLS n’est pas d’afficher un site Web complexe mais juste de répondre à une simple requête HTTP encapsulé dans du SSL. En ce qui concerne le contenu de cette page, il n'y a pas de pré-requis particulier (une page HTML vide, ou bien la page par défaut de IIS 7.5 peut tout à fait être utilisée!). Pour héberger le "rôle" NLS, Microsoft conseille de respecter les préconisations suivantes :

• Utiliser un serveur dédié (même si il est tout à fait envisageable de réutiliser un serveur Web existant)
• Mettre en place un site Web hautement disponible

La mise en place de la haute disponibilité sur le rôle NLS est extrêmement importante ! En effet, si le serveur NLS tombe, tous les postes de travail situés en LAN pour lesquels DirectAccess est configuré, penseront qu'ils sont à l'extérieur de l'entreprise (car le NLS ne sera pas joignable) et tenteront alors de se connecter en IPv6 à la passerelle DirectAccess ce qui perturbera leur connexion au réseau de l'entreprise !

Si l'on respecte à la lettre les préconisations de Microsoft, la mise en oeuvre du rôle NLS implique donc l'utilisation de deux serveurs Web avec équilibrage de charge réseau (load balancer matériel ou NLB). Afin de minimiser les coûts en matériel, il est tout à fait possible de virtualiser les serveurs Web sous Microsoft Hyper-V R2 et d'activer le NLB entre les deux machines virtuelles pour fournir la haute disponibilité.

Dans la suite de ce billet, vous trouverez la procédure complète mettre en place cette configuration (ferme de machines virtuelles NLS en NLB). La petite subtilité étant l'usage d'une version Core de Windows Server 2008 R2 ce qui permet de réduire encore plus l'utilisation en ressources matérielles sur les serveurs Hyper-V tout en minimisant la maintenance.

Déploiement de 2008 R2 en version core

Une fois l'installation du système en version Core réalisée dans les deux machines virtuelles, et une fois le mot de passe du compte Administrator défini, une invite de commande telle que celle-ci s'affiche :

Une série de commande va permettre de mettre en place le serveur Web IIS 7.5.

Pour commencer la commande sconfig (nouveauté de 2008 R2), permet d'effectuer une configuration rapide (nom de la machine, jointure au domaine, configuration TCP/IP).

Je ne détaille pas cette partie qui ne devrait pas poser trop de soucis. En cas de doute vous pouvez vous référer à la documentation sur Technet ( http://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx). Pour les amateurs de l'invite de commande, il est également possible d'exécuter ces différentes opérations à l'aide de netsh (cf. : http://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx).

Une fois ces différentes opérations effectuées on peut envisager d’activer le bureau à distance pour avoir une administration plus souple.

Mise en place du rôle IIS 7.5 sur 2008 R2 en version core

Une fois le système correctement configuré, le rôle serveur Web doit être installé.

Remarque : Dans un premier temps, seuls les composants basiques de IIS sont déployés afin de pouvoir disposer d'un site (enfin une page ;-) ) complètement statique.

Une nouvelle commande est apparue dans 2008 R2 pour installer les rôles et fonctionnalités offerte par la version core :

dism /online /enable-feature /featurename:IIS-WebServerRole

Pour faciliter l’administration du site, il faut activer la prise de contrôle à distance au travers de la console d’administration Internet Information Service (IIS) Management et le WAS :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Attention cela ne suffit pas, il faut aussi autoriser l’administration à distance par MMC en ajoutant la clé de registre suivante :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

La dernière étape consiste à démarrer le service de management et à modifier son type de démarrage en automatique pour qu'il se lance à chaque démarrage de la machine :

sc config wmsvc start= auto

net start wmsvc

Une fois ces étapes réalisées, le site Web par défaut de IIS doit être visible en saisissant http://<IP-SERVEUR> et le rôle IIS du serveur Core peut être configuré à distance à la console MMC graphique !

Installation du certificat et passage en HTTPS

Pour avoir accès au site en HTTPS il reste deux choses à faire. La première consiste à installer le certificat contenant la clé privée en ligne de commande :

certutil –importPFX  “C:\certificat.pfx”

Lors de son exécution la commande certutil nécessite la saisie du mot de passe pour valider l’import du PFX.

Une fois le certificat importé dans le magasin de certificat de l'ordinateur, il faut configurer IIS de manière à ce qu'il le prenne en compte. Pour cela, vous pouvez utiliser la console IIS Management depuis un poste distant. Il faut cliquer sur le site Web par défaut, puis sur Bindings, et enfin sélectionner le certificat voulu dans la liste déroulante (dans cet exemple le certificat se nomme "PI Services Secure Access").

A l'issue de cette étape, le site Web par défaut doit être accessible en saisissant l'URL https://<IP-SERVEUR>.

Mise en place du NLB entre les deux machines virtuelles

Remarque : Avant d'entamer la configuration du NLB sur les deux machines virtuelles, vérifiez que l'option enable spoofing of MAC address est bien activée dans les propriétés de la carte réseau sur les deux machines virtuelles (cette option se configure avec la console MMC Hyper-V Manager). Cette option est apparue avec Hyper-V R2 et permet le bon fonctionnement du NLB au sein des machines virtuelles.

Pour mettre en place le Network Load balancing, il faut commencer par installer la fonctionnalité sur chacun des serveurs de la ferme. Pour cela, saisissez la commande suivante :

Dism /online /Enable-Feature /FeatureName:NetworkLoadBalancingHeadlessServer

Une fois la fonctionnalité installée, le plus simple est d'utiliser la console Network Load Balancing Manager depuis un poste client pour configurer le cluster (la console doit être exécutée avec les "crédentials" d'un compte possédant les droits administrateur sur les serveurs Web).

Pour créer un nouveau cluster, il faut effectuer un clic droit sur Network Load Balancing Clusters, sélectionner New, puis se laisser guider par l’assistant :

Il est possible d'affiner la configuration de la ferme NLB en précisant les ports TCP et UDP sur lesquels l'équilibrage de charge sera actif. Dans l'exemple ci-dessous, deux règles activent l'équilibrage de charge sur les ports 80 TCP et 443 TCP (seul l'équilibrage de charge sur le 443 est nécessaire à DirectAccess).

Pour ajouter un nouveau membre à la ferme NLB, il faut effectuer un clic-droit sur le cluster existant, sélectionner Add Host to Cluster, puis préciser l'adresse IP du deuxième serveur Web.

Une fois le second noeud ajouté et le cluster correctement convergé, il faut vérifier que le site Web est accessible en HTTPs via l'adresse IP virtuelle du cluster (saisir https://<adresse-IP-virtuelle> dans un navigateur).

La dernière étape consiste à créer une entrée dans le DNS pour pointer vers l'adresse IP virtuelle. Cette entrée DNS doit correspondre au FQDN du certificat précédemment importé (par exemple NLS.PISERVICES.FR).

Une fois l'entrée DNS créée, vérifiez que le site Web est accessible via l'URL https://nls.piservices.fr. Aucune erreur de certifiat ne doit s'afficher dans le navigateur !

Remarque : Il est possible de tester le cluster en mettant en pause l'une des deux machines virtuelles (via la console MMC Hyper-V Manager) !

A partir de cet instant la ferme de serveurs NLS est pleinement opérationnelle !

Mise en place d'une page Web dynamique sur la ferme NLS

Pour faciliter le dépannage lors de la mise en place de DirectAccess, il est souvent nécessaire de connaitre l'adresse IP utilisée par le poste de travail pour accéder au serveur NLS. Cela permet de déterminer quelle technologie de transition a été utilisée (6to4, Teredo, ISATAP, NAT64...).

Pour cela il suffit de modifier la configuration de la page par défaut des serveurs NLS afin d'afficher l’IP du client. Dans cet exemple, le langage ASP.net est utilisé.

Pour pouvoir héberger une page en ASP.net des composants supplémentaires doivent être installé sur les serveurs. Tout d’abord, il faut installer les Framework .NET 2 et 3 :

dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:NetFx3-ServerCore

Les fonctionnalités ISAPI et ASP.NET doivent également être installées sur le rôle IIS :

dism /online /enable-feature /featurename:IIS-WebServerRole

dism /online /enable-feature /featurename:IIS-ISAPIFilter

dism /online /enable-feature /featurename:IIS-ISAPIExtensions

dism /online /enable-feature /featurename:IIS-NetFxExtensibility

dism /online /enable-feature /featurename:IIS-ASPNET

Enfin il faut installer le WAS et le service de gestion :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService

dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Pour démarrer le service de management, le rendre automatique et autoriser la gestion à distance, il faut exécuter les commandes suivantes :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

sc config wmsvc start= auto

net start wmsvc

A présent le serveur est capable d’interpréter du code ASP.net, il est donc possible de créer une page ASPX. Dans l'exemple ci-dessous, une page default.aspx a été créée et le site a été reconfiguré pour l'utiliser en document par défaut :

Voici le résultat obtenu avec les méthodes permettant de récupérer les adresses IP (seul le "body" de la page est affiché) :

<body>
    <form id="form1" runat="server">
    <div>
        Nom du serveur :    <%= Request.ServerVariables["SERVER_NAME"]%><br />
        Adresse IP du serveur :     <%= Request.ServerVariables["SERVER_ADDR"]%><br />
        Adresse IP du visiteur :     <%= Request.ServerVariables["REMOTE_ADDR"]%>
    </div>
    </form>
</body>

N'hésitez pas à laisser un commentaire sur cette procédure si vous avez des éléments à ajouter ou des précisions à demander.

Problématique rencontrée

Lorsqu'une nouvelle imprimante est ajoutée sur un serveur d'impression Windows Server 2008 R2, le pilote injecté par l'assistant d'installation est celui correspondant au système d'exploitation (pilote pour architecture x64).

Les postes de travail 2000/XP/Vista et Seven étant généralement déployés en 32 bits (architecture x86), il faut impérativement rajouter le pilote x86 dans les propriétés de l'imprimante partagée.

Lorsque l'on réalise cette opération un fichier système nommé ntprint.inf est requis. Par défaut le media d'installation Windows est demandé (répertoire D:\i386).

Les images ISO de Windows 2000, Windows XP et Windows Server 2003 32 bits contiennent effectivement un fichier ntprint.inf sous le répertoire i386. Or lorsque l'on sélectionne ce fichier, l'assistant ne le prend pas en compte et réaffiche indéfiniment la fenêtre permettant de sélectionner l'emplacement du fichier.

Explication

Le fichier ntprint.inf contenu dans les sources de Windows 2000/XP/2003 n'est pas celui attendu par l'assistant d'ajout de pilote.

Ce dernier s'attend à recevoir un fichier ntprint.inf plus récent (Windows Vista 32 bits ou supérieur) situé dans le répertoire C:\Windows\winsxs.

Solution

La solution consiste à utiliser le fichier ntprint.inf situé dans C:\Windows\winsxs de l'une des versions suivantes de Windows :

• Windows Vista 32 bits
• Windows Seven 32 bits
• Windows 2008 32 bits

Le nom précis du répertoire est le suivant :

C:\Windows\winsxs\x86_ntprint.inf_<id>_<version>.<id>_none_<id>

Remarque : <id> et <version> correspondent à des ID et à la version du système (par exemple 6.0.6002 pour Windows Server 2008 SP2) - cela signifie que le nom du répertoire varie d'une version de Windows à l'autre et également en fonction du service pack

Voici le nom exact du répertoire pour Windows 7 32 bits :

• x86_ntprint.inf_31bf3856ad364e35_6.1.7600.16385_none_3ad6f3251c0676a9

Pour Windows Server 2008 SP2 32 bits le nom exact est :

• x86_ntprint.inf_31bf3856ad364e35_6.0.6002.18005_none_3cec160db7d4ac84

Exemple pas-à-pas avec une imprimante Laser Dell 5200

Voici un exemple pas-à-pas pour ajouter une imprimante partagée sous Windows Server 2008 R2 avec les pilotes x64 et x86.

Dans un premier temps il est conseillé d'installer le rôle Print and Document Services avec le sous-composant Print Server (cf. captures d'écran ci-dessous).

Une fois l'installation du rôle effectuée, lancez la console MMC Print Management. Dans l'arborescence de la console, développez Print Servers / <Nom du serveur>, puis faites un clic droit sur Printers et lancez l'assistant Add Printers...

Dans la page Printer Installation, choisissez Add a TCP/IP or Web Services Printer by IP address or hostname, puis cliquez sur le bouton Next.

Dans la page Printer Address, sélectionnez TCP/IP Device dans la liste déroulante, entrez l'adresse IP de l'imprimante, puis cliquez sur le bouton Next.

Si le pilote n'est pas déjà installé sur le serveur, sélectionnez Install a new driver puis cliquez sur Next.

Si le pilote de votre imprimante n'est pas présent dans la liste prédéfinie de Windows Server 2008 R2, cliquez sur le bouton Have Disk... pour insérer le pilote (le pilote demandé ici est celui correspondant au système serveur à savoir le pilote x64).

Une fois le fichier INI chargé, sélectionnez le pilote correspondant à votre périphérique d'impression (dans cet exemple il s'agit d'une imprimante Dell M5200N).

Dans la page Printer Name and Sharing Settings, entrez le nom de l'imprimante, le nom du partage de fichiers et l'emplacement (dans cet exemple le nom du partage est "Imprimante Technique" et l'emplacement est PIS/FRANCE/NOISY/OPEN-SPACE-TECHNIQUE).

Patientez durant l'installation du pilote d'impression...

Une fois le pilote installé, afficher les propriétés de l'imprimante dans la console MMC Print Management, allez dans l'onglet Sharing, puis cliquez sur le bouton Additionnal Drivers...

Remarque : Vous pouvez également côcher la case List in directory pour créer l'objet imprimante correspondant dans l'annuaire Active Directory (par défaut l'objet imprimante sera créé à l'intérieur du compte ordinateur correspondant au serveur d'impression).

Côchez la case x86, puis cliquez sur le bouton OK.

Une fenêtre doit alors s'ouvrir et demander le pilote d'impression x86 (à télécharger sur le site du constructeur).

Une fois le pilote x86 correctement installé, une nouvelle fenêtre demande un fichier nommé ntprint.inf présent dans le répertoire i386.

Spécifiez ici l'emplacement du fichier ntprint.inf (emplacement situé dans le répertoire C:\ Windows \ winsxs \ x86_ntprint.inf_<id>_<version>_none_<id> d'une machine Vista / Seven / 2008 en version 32 bits).

Après quelques secondes le pilote est correctement installé !

Problème rencontré :

Dans le cadre d’une implémentation de SEP dans une entreprise, beaucoup de services informatiques ont la volonté d’intégrer le client SEP dans le “Master”. Pour intégrer le produit, l’idée première serait de créer un package d’installation avec la console SEPM et de lier le client SEP directement a la console. Ce package serait déployé sur le poste de référence et donc présent au sein du "master".

Cette idée d’optimisation serait idéale si le client SEP ne possédait pas un “SID” unique créé lors de l’intégration du client à l’architecture SEP. L’effet créé est que un seul poste remonte dans la console (même si le master contenant l'installation de SEP est déployé sur des centraines de postes), et change de nom, d’IP, … à chaque démarrage d’une machine issue de la même intégration.

Exemple, dans l’ajout d’un poste (PosteB) avec le même client SEP d’installé, la communication avec le serveur SEPM ne fait pas s’ajouter un client supplémentaire dans la console, mais change les “informations” d’un autre poste (PosteA)

Solution apportée :

Pour optimiser le déploiement, il est possible de pré-installer le client SEP dans un “Master”. Le client doit être impérativement installé en mode “Non-géré”. A la fin d’un déploiement, il suffit de “lier” le client SEP a la console de gestion grâce a l’outil “Sylinkdrop.exe” et d’un fichier de liaison “Sylink.xml”.

Symantec recommande d’installer l’antivirus après la “masterisation” du poste. Cela évite d’avoir à refaire les “Masters” à chaque évolution (MRx) du produit.

Si des masters ont déjà été créé, voici un lien de Symantec qui explique les modifications à apporter au client SEP installé:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/d84071c5137d6d318825738a00663b8d?OpenDocument

NOTE: La clé de registre HKLM \ SOFTWARE \ Symantec \ Symantec Endpoint Protection \ SMC \ SYLINK \ SyLink \ SySoftk peut également être supprimée si elle est présente.
Une fois l'image “Ghost” appliquée sur un nouveau système, le client va générer une valeur d'identification unique, se connecter avec son SEPM et s’enregistrer.  Lors de l'inscription sur le le serveur de gestion,  SEPM va enregistrer toutes les informations clientes nécessaires dans la base de données.

Une des nouveautés annoncées par Symantec dans le SP3 de la version 8 d’Enterprise Vault s’appelle le “Virtual Vault”… mais QU’ES ACÒ ???…

Est-ce une réelle avancée technologique ? Est-ce que cela répond à des besoins précis ? Est-ce compliqué à mettre en place ? Et surtout, pourquoi Virtuel ?

Après l’Offline Vault … après le Vault Cache … voici le Virtual Vault !

A l’identique du “mode Exchange mis en Cache” pour les clients Outlook, Enterprise Vault propose depuis quelques temps déjà une fonctionnalité permettant d’avoir accès à ses éléments archivés en mode déconnecté, à savoir l’Offline Vault (avant la version 8) ou le Vault Cache (depuis la version 8). Le principe consiste à répliquer localement sur le poste de travail les mails archivés ainsi que l’arborescence dans un fichier de type OST, et à concurrence d’un % d’espace disque disponible défini depuis la console d’administration de la solution.

Donc, cela n’est pas nouveau mais n’était pas visible…

Désormais, il est possible de visualiser le contenu de ce Vault Cache depuis Outlook, et de le faire apparaître comme un dossier personnel type PST.Le Virtual Vault n’est en quelques sortes qu’une extension de son Vault Cache. Mieux, il devient un vrai dossier intégré à Outlook et interagir avec lui depuis son client de messagerie est maintenant possible.

Mais à quoi cela ressemble t-il…

Dans la boite aux lettre de l’utilisateur, un nouveau dossier apparaît sous la forme “Vault – Nom de la boite” et affiche le contenu complet de l’archive Enterprise Vault, avec la structure dossier, sous-dossier impactés par l’archivage. De plus, les mails archivés apparaissent avec les icônes originaux, donc des enveloppes…

Comment est-ce géré ?…

…Directement depuis la console d’administration avec les différentes Policies :

… Mais aussi depuis son client Outlook :

Et quel sont les mécanismes permettant d’appliquer les modifications apportées à son Vault Cache ?…

… En premier lieu, la synchronisation des Policies vers les cibles permet d’appliquer les modifications…

… Puis, tout simplement les mécanismes de Synchronisation de Vault Cache entre le client et le serveur Symantec Enterprise Vault :

Au final, quels pourraient bien être les avantages à activer le Virtual Vault ?…

• Il devient possible d’y créer des dossiers, des sous dossier, une structure,
• Effectuer des déplacements de dossiers ou de message se réalise facilement,
• Glisser des mails depuis sa boite aux lettres vers son archive se fait allègrement
• Générer des “règles” dans Outlook pour aller déverser directement des mails dans son archive devient possible
• Toutes les opérations comme “répondre”, “répondre à tous”, “transférer” sont réellement fonctionnelles
• La recherche intégrée à Outlook est désormais capable de montrer des résultats depuis la boite aux lettres comme depuis le Vault Cache, le tout avec le même outil
• Il est possible de gérer à l’identique toutes les archives auxquelles on a accès et de toutes les faire apparaître (sa propre boite aux lettres, boites aux lettres partagées, …)
• Et plus encore…

Du coup, la gestion de ses archives devient intuitive et perturbe beaucoup moins l’utilisateur final. Et il devient légitime de se poser d’autres questions:

• Est-il encore nécessaire de remplacer les mails archivés par les fameux “raccourcis” ?
• Doit-on encore fournir les outils de recherche Symantec Enterprise Vault à l’utilisateur final dans Outlook (recherche simple ou avancée, recherche Web, Archive Explorer) ?
• Et doit-on encore déployer Windows Desktop Search ?
• Quid du fonctionnement en Outlook Web Access ou Outlook Web Application ?
• Quelle stratégie adopter pour les nomades ayant accès en 3G ?

Plutôt intéressant comme nouveauté !…

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…

Vous trouverez ci-dessous certains document relatifs à cet article :

ftp://exftpp.symantec.com/pub/support/products/Exchange_Mailbox_Archiving_Unit/347092.pdf

http://seer.entsupport.symantec.com/docs/346892.htm